Posted on June 23, 2026 by Lin Sun, CNCF Ambassador

I’ve always thought about AI agents as microservices+.

They need everything a traditional microservice needs, and:

• More authentication requirements because an agent may act on behalf of many different users.
• More policy requirements because an agent’s behavior can be less predictable, requiring guardrails and policy enforcement.
• More observability requirements, especially around context, prompts, tool calls, and the contents of requests and responses.

When thinking about agent auth, I found myself reflecting on a traffic lawyer I hired years ago after receiving a traffic ticket for failing to stop for a school bus. It was my first, and so far only, traffic ticket.😅

The experience turned out to be a useful mental model for understanding agent auth.

Imagine a lawyer walking into court to represent Alice.

This is similar to an AI agent receiving a request from Alice and performing actions on her behalf.

The judge first asks the lawyer to prove who he is.

This is agent identity. Before the system can trust an agent, it needs to know exactly which agent is making the request.

Next, the judge asks, “Who are you representing today?”

This is principal identity. The system needs to know not only who the agent is, but also which user the agent is acting for.

The lawyer then presents documentation showing that he is authorized to represent Alice in this specific case.

In agent systems, this is often represented by an On-Behalf-Of (OBO) token or another delegation artifact. The token carries information about:

• The identity of the principal (Alice)
• The identity of the agent
• The delegated permissions
• The scope of the delegation

At this point, the judge knows three things:

1. Who the lawyer is
2. Who the lawyer represents
3. What authority has been delegated to the lawyer

But that still isn’t enough.

The judge must also verify that the lawyer is allowed to represent Alice in this particular traffic case. This is where policy enforcement comes in.

Having a valid delegation does not automatically grant unlimited access. The requested action must still comply with the applicable policies and scopes.

In a real courtroom, the lawyer and the judge handle most of this complexity. They carry identities, verify credentials, validate representation rights, and enforce the rules of the court.

In an agentic system, we need similar infrastructure.

An agent platform must be able to:

• Establish strong agent identities
• Carry principal identities across requests
• Issue and validate delegation tokens
• Enforce authorization policies and scopes
• Provide observability and audit trails for agent actions

This is where an AI native gateway can play an important role.

Rather than requiring every agent to independently implement identity propagation, delegation verification, policy enforcement, and auditing, the agent gateway and mesh can centralize these capabilities. The agent gateway and mesh become the equivalent of the court clerk, bailiff, and records office combined: ensuring identities are verified, delegations are valid, policies are enforced, and actions are auditable.

Combined with existing identity and service-mesh technologies such as SPIFFE, cert-manager, Istio, and agentgateway, we can build an agent platform where agents focus on business logic while the platform handles identity, delegation, policy enforcement, and observability.

The core idea is simple:

A lawyer is not the client.

An agent is not the user.

Both operate with their own identities while acting on behalf of someone else, under a specific delegation and within a defined scope. Agent auth is fundamentally about making that relationship explicit, verifiable, and enforceable.