An agent's identity is not its permission

The idea in brief

Authentication establishes who is calling. Authorization decides what that caller may do. With AI agents the two are easy to blur, because the agent has its own identity but often acts on behalf of a person. Three public sources describe how to keep them apart: NIST's zero trust architecture, OWASP's guidance on LLM applications, and Microsoft's documentation for Entra Agent ID.

The zero trust starting point

NIST SP 800-207 (2020) describes zero trust as moving protection away from network perimeters and towards users, assets and resources. Being on the right network or holding a device grants no implicit trust, and authentication and authorization are treated as separate steps performed before a session with a resource begins. An agent with a valid identity fits the same model: the identity is an input, not a grant.

What OWASP recommends for agents

The OWASP Top 10 for LLM Applications (2025) lists Excessive Agency as LLM06. It traces the risk to three causes: excessive functionality, excessive permissions and excessive autonomy. Several of its recommended mitigations map directly onto the identity question:

• Execute in the user's context. Act on downstream systems as the specific user, with the minimum privileges needed, for example OAuth with narrow scopes.
• Complete mediation. Enforce authorization in the downstream systems, rather than relying on the model to decide.
• Require user approval for high-impact actions.
• Minimise permissions and functionality, for example read-only access where that is enough.
• Log and monitor downstream activity and apply rate limits, to limit damage.

An illustrative example

Consider a hypothetical expense agent that can approve payments in a finance system. Applying the points above, an approval might depend on several conditions at once, only some of which a token can carry:

# illustrative only
allow approve_payment if
    agent is registered for the finance tool
and user holds the approver role
and delegated scope includes payments.approve
and amount is within the user's approval limit
and amount is within the agent's limit, else ask a human

The limits and the amount belong to the finance system. That is the reasoning behind OWASP's complete mediation point: the downstream system is the place that can see both the caller's identity and the business context.

How Microsoft Entra Agent ID models it

Microsoft's Entra Agent ID documentation shows one vendor's implementation of these ideas:

• Agents get dedicated identities, created from an agent identity blueprint, separate from ordinary application registrations.
• For delegated access, the docs describe an on-behalf-of (OBO) flow: the agent exchanges the user's token for a token to call a downstream API, and Entra validates both before issuing it. The user consents to the delegated permissions.
• Conditional Access policies can be applied to agent identities, based on the agent and other context.
• Access can be granted through access packages with an end date. The governance docs describe a human sponsor who can renew access; if no one acts, the assignment expires and the agent loses access.

The expiring, sponsor-owned access is one concrete answer to the "for how long" part of the authorization question.

@article{adam2026agentidentityisnotauthorization,
  title   = {An agent's identity is not its permission},
  author  = {Adam, Ammar},
  journal = {www.ammaradam.dev},
  year    = {2026},
  month   = {Oct},
  url     = {https://www.ammaradam.dev/posts/agent-identity-is-not-authorization/}
}