OAuth can prove that a request may reach a resource. It does not, by itself, tell an operator the full story of the actor holding the token.
That distinction matters once software can plan, call tools, retry, and act across several systems. The question is no longer only, "Is this request authenticated?" It is also:
- Which agent is acting?
- Under whose authority?
- For what purpose?
- Against which target?
- What evidence will remain after the action?
If your system cannot answer those questions without reading the agent's prompt, it does not yet have an operational identity model. It has a credential.
A token is permission, not the whole identity
OAuth remains essential infrastructure for agents. The current Model Context Protocol authorization specification builds on OAuth 2.1, Protected Resource Metadata, Client ID Metadata Documents, audience binding, and least-privilege scopes. It also hardens issuer validation, defines step-up authorization, and forbids token passthrough.
Those controls answer important questions:
- Is this token intended for this resource?
- Which permissions did the user approve?
- Has the credential expired?
- Does the resource server accept its audience?
But a token is still one artifact inside a larger system. It can carry identity claims, but it does not automatically give that identity a lifecycle, an owner, a purpose, or a useful audit trail.
An operational identity is the continuity around the token. It says this is the same agent before, during, and after a credential is issued, and that its authority can be understood and withdrawn.
Borrowing a human identity breaks the record
The fastest way to get an agent moving is often to lend it a human credential. Copy an API key into the environment. Reuse a browser session. Give it an access token created for an employee.
Now the log says a person acted when an agent did. The credential may carry every permission the person has, even though the task needed two. Revoking the agent means revoking the human. A later reviewer cannot tell whether an action was approved, inferred, retried, or inherited from a long-lived session.
This is the identity version of shared passwords. OWASP's Agentic Top 10 for 2026 treats identity and privilege abuse as a distinct agentic risk.
Keep the authorization record small and resolvable
The exact implementation will differ, but the system should preserve a stable agent identifier, a visible authority chain, a bounded purpose and target, short-lived credentials, revocation, and evidence after the action.
A conceptual record can stay compact:
{
"agent_id": "qa-runner",
"authority": {
"type": "workspace",
"id": "acme-staging"
},
"purpose": "verify owned checkout flow",
"targets": ["staging.acme.test"],
"scopes": ["challenge:open", "verdict:read"],
"expires_at": "2026-09-07T18:30:00Z"
}
The goal is not to force every policy decision into the token. The goal is to make sure the token resolves back to a governed record that is small enough to inspect and specific enough to enforce.
The current IETF Internet-Draft on AI agent authentication and authorization is useful as a direction of travel, not a finished standard. It treats agents as workloads that need identifiers, credentials, provisioning, authentication, authorization, observability, policy, and compliance.
Where AgentSIM starts
AgentSIM starts when an agent reaches an authentication challenge in an app or environment your organization owns or is authorized to automate.
Today, SMS OTP is connector zero and the live connector. Email OTP and magic links are mock or inject flows. Passkeys and CAPTCHA are detected stopping conditions, not challenges AgentSIM silently completes.
The broader North Star is authorization continuity. The identity belongs to the agent. Authority stays with the organization. Every boundary should be explicit, scoped, revocable, and able to return evidence.
That is narrower than "universal agent identity," and deliberately so. Each boundary needs to work in production before it is described as covered.
The five-question test
Before giving an agent another credential, ask whether the system can answer these questions from its records:
- Which agent used it?
- Who or what delegated the authority?
- What task and target were approved?
- When does that authority end, and how is it revoked?
- What evidence connects the grant to the final action?
If the answers are clear, the token belongs to an identity system. If they are not, the token is only access with a hopeful story attached.
Read the canonical AgentSIM article and see the authority model
Top comments (0)