Most identity setups distinguish interactive user sessions from machine clients, often based on whether the callers use authorization code flows or client credentials. This distinction between user accounts and service accounts works when every caller fits one category or the other.
AI agents don’t fit either. An agent using a human’s token inherits their full permissions and looks like the human in your logs. An agent using client credentials is, as far as your identity system knows, a service account for a machine client, because nothing in the token marks it as acting on a human’s behalf. Either way, a third-party actor with delegated authority is being misidentified.
This misidentification of AI agents opens the door to over-provisioned access, confused deputy attacks, and audit trails that can’t tell you what actually happened.
Why Agents Don’t Fit The Identity Model
A service acts on its own behalf. A human acts on their own behalf. But an agent is an intermediary: it acts on a human’s behalf, but it isn’t that human. Today’s identity systems don’t have a way to represent that relationship. The agent either borrows the human’s session or gets its own service account, and both misidentify what’s actually happening.
What Goes Wrong When You Can’t Tell Them Apart
The consequences of identity blindness show up in three places.
- The Confused Deputy Problem: A confused deputy attack tricks a trusted program into misusing its own authority. An agent with access to an email API can be manipulated through prompt injection to forward a password reset code to an attacker. With a distinct agent identity, you could scope agent permissions independently of human permissions, enabling you to revoke an agent’s access without disabling the corresponding human’s user account. A separate identity doesn’t prevent prompt injection on its own, but narrower, agent-specific scopes reduce what a confused deputy can actually do.
- Over-Provisioned Access: When an agent uses a human’s token, it inherits every permission that the human has, even if its task only needs a narrow slice. If the agent is compromised, the blast radius is the human’s entire permission set rather than the one API the agent actually needed.
- Unreadable Audit Trails: If an agent operates under a human’s token, your logs attribute its actions to that human. When something goes wrong, you’re investigating the wrong entity. You can’t revoke the agent’s access without revoking the human’s, and you can’t tell which actions were autonomous and which were intentional.
Closing The Identity Model Gap
Teams are deploying agents faster than they’re updating their identity systems to handle them. A Gravitee survey found that 80.9% of technical teams are actively testing or running agents, but only 14.4% have deployed them with full security and IT approval.
Here are a few approaches you can use to give agents their own place in your identity model:
Use Token Exchange To Make Delegation Explicit
RFC 8693 (OAuth 2.0 Token Exchange) lets an agent present both the human’s token and its own. The resulting token records who delegated to whom (“Agent X acting on behalf of Human Y”), and the authorization server can issue it with narrower scopes than the human’s original token.
Issue Agents Their Own Credentials
Give each agent its own OAuth client ID with scopes limited to what it actually needs. Short-lived tokens limit the blast radius if an agent is compromised, and you can revoke the agent’s access without affecting the human who deployed it.
Watch The Emerging Standards
New specifications are starting to treat agents as a distinct identity type:
- A SCIM draft proposes “Agents” and “Agentic Applications” as first-class resource types for user provisioning.
- The Web Bot Auth IETF draft lets agents cryptographically sign HTTP requests so servers can verify agent identity without relying on User-Agent strings. Hosting providers like Vercel are already building around
The space is moving fast. FusionAuth’s overview of agent authentication covers the common protocols (A2A and MCP), authorization models, and security considerations in more detail.
Start With An Audit
Before adopting new standards, map what you have today:
- Which of your services can distinguish between human, agent, and service-to-service requests?
- Where are agents operating under human tokens instead of their own identities?
- Can your logs distinguish whether a request came from a human session, an agent acting on their behalf, or a service-to-service call?
The answers will tell you where to start.






