Authentication vs Authorization for Agents

Most agent failures that look like "security problems" are actually "modeling problems." The system cannot cleanly answer two questions:

• Who is the actor?
• What is the actor allowed to do right now?

In conventional apps, these map cleanly to authentication and authorization. In agent systems, they often collapse into one over-privileged token.

The core pain: OAuth tokens rarely represent the real actor

OAuth and modern IAM were built around a stable client model:

• a user authenticates
• an application is authorized
• the application uses tokens to access resources

Agent systems complicate this because there are multiple principals:

• a human principal (the person whose intent is being represented)
• an agent runtime (the executor)
• an orchestrator/workload (the compute environment)
• external tools (SaaS APIs, telephony, payments)

In many implementations, the only "identity" that survives the hop is:

• the client ID
• a service account
• a shared API key

This breaks attribution immediately:

• the token identifies the app, not the agent instance
• the agent action is indistinguishable from any other automation using the same credentials
• "on behalf of" semantics disappear in downstream logs and audits

The second pain: authorization becomes coarse and sticky

Agent authorization often ends up as:

• broad scopes because narrow scopes are tedious to manage
• long-lived refresh tokens because agents must run continuously
• shared credentials because it is operationally convenient

This creates hard-to-control blast radius:

• one compromised key affects many agents
• one misconfigured permission affects all tool calls
• one prompt injection can access everything the token can access

It also creates revocation ambiguity:

• revoking a token may break unrelated workflows
• keeping the token alive preserves unintended authority
• "least privilege" becomes theoretical because practical systems drift toward convenience

The third pain: the boundary between auth and policy is unclear

Even when "authorization" exists, it is typically static:

• role-based access, tied to a user or service account
• permissions defined at provisioning time
• checks performed at the API boundary, not across sequences of actions

Agents do not behave like single API requests. They behave like action sequences:

• read context
• call tool A
• transform data
• call tool B
• retry on failure
• escalate to alternate path

Static authorization does not express the conditions that actually matter in production:

• rate and burst behavior
• action frequency over time
• novelty (new recipient, new payee, new domain)
• parameter sensitivity (amount thresholds, destination changes)
• execution context changes (new device, new network, new environment)

When these are not modeled, failures show up as either:

• excessive blocking (legitimate actions denied)
• insufficient blocking (dangerous actions permitted)

The fourth pain: non-repudiation and disputes become inevitable

Once agents act, people dispute outcomes:

• "I did not authorize this."
• "The system acted without consent."
• "That was a test, not production."
• "The agent was compromised."

Traditional IAM artifacts often do not resolve disputes because:

• the identity in logs is the service account or app client
• the link to a human principal is missing or informal
• token issuance does not capture intent for a specific action
• action context is not preserved in a verifiable way

In practice, teams end up arguing from incomplete telemetry.

Conclusion

The main pain in agent IAM is not lack of authentication. It is mismatched representation:

• tokens identify applications, not autonomous actors
• authority becomes broad, long-lived, and shared
• runtime conditions that determine risk are not captured
• audits cannot cleanly tie actions back to accountable principals

This is why "just use OAuth" often produces systems that are simultaneously insecure and unreliable.