Security

The Microservice Identity Crisis: Are Agents Users Or Services?

0
Author: Brad McCarty, Senior Product Marketing Manager, FusionAuth
Bio: Brad is a writer at heart with 13 years of experience crafting everything from technical deep-dives to strategic messaging. He spends his days helping developers navigate the world of identity and authentication, and his evenings mountain biking around Colorado.

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.

OWASP Updated Their Top 10 Again—Here’s What Security Leaders Need to Know | Steve Winterfeld, Akamai | TFiR

Previous article

Why AI’s Real Bottleneck Isn’t Your Model—It’s Your Data Infrastructure | Adi Gelvan, Speedata | TFiR

Next article