Two-legged OAuth: the agent acts as itself
No user is present. The agent or service uses its own workload identity and application permissions, commonly through the OAuth client credentials flow.
AI agent identity proves which user, agent or system is requesting access. Inbound controls who can call your agent. Outbound controls how your agent reaches other systems.
five checkpoints, one question each: who is this, really?Direction tells you which side of the agent boundary needs protection. It's one flow through your agent, checked twice — once coming in, once going out.
Your agent checks the caller's token, issuer, intended audience, tenant and permissions before accepting the request.
Your agent obtains a token for that destination, requests only the permissions it needs and identifies itself or the user it represents.
Each relationship checks who is acting, what they can access and whether the next system should accept the request.
Under A2A, an agent can publish a card like this one before anyone talks to it. The card describes the agent's inbound boundary: what it does, which authentication methods it accepts and how another agent should call it.
Outbound access is separate. The calling agent still needs a 2LO workload token or 3LO delegated token that the destination system will accept.
The protocol standardises the handshake — it doesn't force anyone to check the signature. That's the one gap worth knowing about.
Insist on the signed version for anything outside your own tenant.
Start with five controls: unique identities, delegated access, named owners, signed agent cards and complete activity logs.