When a lawyer files a motion in court, two identities sit on the paperwork. The lawyer’s bar number identifies who actually filed. The client’s name identifies whose interests are being represented. The court system tracks both because they answer different questions. The lawyer is liable for the procedural integrity of the filing. The client is bound by its substantive claims. Fuse the two identities into one, and the legal system loses its ability to do either job well.

Agent infrastructure has been making the opposite mistake.

Most agent identity systems collapse two distinct questions into a single token. Who is making this call? Who authorized the call? These are different questions with different answers, different liabilities, and different lifecycles. An agent’s identity persists across thousands of users and millions of interactions. A user’s authorization expires in an hour. Treating them as a single identifier forces a choice: either the agent has no stable identity of its own because it inherits whatever user token currently exists, or the user has no scoped delegation because it inherits whatever the agent is allowed to do.

The right architecture has two axes. The Agent Transfer Protocol (AGTP) was designed around that recognition.

Two questions, two layers

Consider what is actually happening when an agent acts on someone’s behalf.

A retail buyer’s agent runs continuously, is deployed and operated by an organization, and hosts many users over its lifetime. The agent has a permanent identity tied to its Agent Genesis, an owner accountable for its behavior, and a track record visible in transparency logs. None of that changes from one user session to the next.

At the same time, the agent acts on behalf of a specific user, with specific delegated authority, for a specific window of time. The user’s consent has scope. The user can revoke it. A different user with different consent might use the same agent five minutes later.

The agent is one identity. The user is a different identity. Both are real, and both have to be carried on every request the agent makes. A system that issues only one of them is incomplete. A system that fuses them is wrong.

This is the orthogonality that AGTP makes structural. Agent-ID lives on the wire, in the header of every AGTP request. The OAuth bearer token resides in the application layer, in the standard Authorization: Bearer header, and is validated by the receiving server’s application logic. Both ride on the same request. Neither displaces the other. The agent identity tells the wire who is calling. The OAuth token tells the application who authorized the call.

The two layers stay separate because they have to. Agent-ID is verified by the Genesis trust path. OAuth tokens are validated by the application’s chosen identity provider. Agent-ID is stable across deployments. OAuth tokens expire. Agent-ID flows to every intermediary that needs to enforce scope at the protocol layer. OAuth tokens flow only to endpoints that know how to interpret them. The wire layer and the application layer have always had different jobs. AGTP keeps them that way.

Three composition patterns

The orthogonality is more than a design principle. It produces three concrete patterns that AGTP supports as first-class deployments.

Pattern 1: AGTP-only. The agent identifies itself using a Canonical Agent-ID and an Agent Certificate. Authority-Scope on the request declares what the agent is permitted to do. Trust is anchored in the registrar that issued the Genesis. No external identity provider is involved. This is the greenfield deployment, suited to research environments, autonomous agent networks, and standalone agent-to-agent commerce.

Pattern 2: AGTP carrying OAuth. The agent still identifies itself via Agent-ID at the wire layer. Layered on top, an OAuth bearer token in the Authorization header identifies the principal the agent is acting on behalf of. The two pieces of identity ride on the same request and answer their respective questions. Authority-Scope describes the agent’s capacity to act. OAuth scope describes the delegation from the principal. They are independent fields with independent semantics, validated by independent authorities. This is the enterprise integration deployment, suited to organizations that already have an OIDC provider, an OAuth gateway, or a federated IdP in place.

Pattern 3: OIDC-federated Genesis-issuer trust. The registrar’s signing key is attested by an enterprise IdP via OIDC federation. The Genesis-issuer fingerprint resolves to an OIDC-discoverable issuer instead of a hardcoded list of trusted registrars. This bottoms out the Tier 1 trust path in the existing enterprise identity infrastructure, meaning the same identity provider that vouches for the company’s employees can also vouch for the company’s agents. This is the deep integration deployment, suited to organizations whose security postures require every trust root to terminate in infrastructure they already operate.

Each pattern is additive. A deployment can start in Pattern 1 and migrate to Pattern 2 by adding an OAuth configuration block. It can migrate to Pattern 3 by replacing a static trust anchor with an OIDC-federated one. The wire format stays stable across all three. Existing deployments keep working as new ones come online.

The Attribution-Record carries both

When an agent invokes a method, AGTP produces an Attribution-Record. The record binds the responding agent’s identity, the request hash, and the response status into a single signed envelope. Under Patterns 2 and 3, the Attribution-Record also includes an acting_principal_id field: the validated identifier of the user the agent was acting on behalf of, derived from the OAuth token claim configured by the server.

This is the audit trail that regulators, accountants, and dispute resolvers actually need. Agent-ID answers what acted. Owner-ID answers who is responsible for what was acted upon. acting_principal_id answers who authorized the action at the moment it happened. All three flow into the same signed receipt, written to the same transparency log, replayable months or years later when someone needs to reconstruct what happened.

The token itself never appears in the Attribution-Record. Only the validated, lifted claim. The bearer secret stays where it belongs, in the moment of the transaction. The accountability claim is what persists.

This is what separates AGTP’s audit trail from the ad hoc logging most agent platforms produce today. Most platforms log whatever their framework captures, in whatever format it uses. AGTP logs the three identities that enable accountability in a structured format that any downstream system can read.

Composition over replacement

The strategic decision underneath all of this is worth naming directly. AGTP refuses to compete with the identity infrastructure organizations have already built.

OAuth is a decade and a half of accumulated investment. OIDC providers run inside almost every enterprise of consequence. Token-based authorization patterns are written into compliance frameworks, vendor contracts, and security audits. An agent protocol that demanded organizations rip all of that out and replace it with something agent-specific would lose the adoption fight before it started. The infrastructure is too entrenched, the migration cost too high, and the political capital required too scarce.

AGTP makes a different bet. Agent identity is a different layer from user authorization. The two layers can coexist on the same request because they answer different questions. Organizations keep their OIDC provider, OAuth flows, enterprise IdP, and existing token validation pipelines. They add an agent identity layer underneath, anchored by Agent Genesis and verified at the wire. The two layers compose. Nothing in the existing stack has to move.

This is the inversion that the existing agent-identity platforms keep failing to achieve. Most of them want to be the identity. AGTP wants to be the layer where identities live. OAuth fits cleanly on top of AGTP. SPIFFE fits cleanly alongside it. Enterprise IdPs federate into the Genesis trust path through OIDC. The architecture composes outwardly rather than demanding replacement.

What this opens up

Once Agent-ID and OAuth principal are independent axes, what was difficult becomes easy.

Delegation chains become legible. An agent that hires another agent on a user’s behalf carries the user’s OAuth principal forward as the acting principal, while the chain of Agent-IDs is recorded as a separate authority trail. A regulator auditing the transaction can answer both “who ultimately authorized this” and “what chain of agents executed it.” The two questions stop being conflated.

Cross-organization commerce becomes tractable. An agent at Organization A can call an agent at Organization B, with each agent verified by its own organization’s Genesis trust, and a shared OAuth grant flowing between them as the principal-level authorization. Neither organization has to share its agent identity infrastructure. Neither has to abandon its existing IdP. The two trust roots remain separate, and the cross-organization transaction provides sufficient structure to be auditable on both sides.

Incident response becomes precise. When an agent does something outside its sanctioned behavior, the Attribution-Record points to three distinct possible failure modes. The agent itself misbehaved (Agent-ID issue). The owner failed to govern the agent (Owner-ID issue). The acting principal exceeded their delegation (OAuth scope issue). Each failure mode has a different remediation, a different liability, and a different policy response. Collapse them into one identifier, and incident response becomes guesswork. Keep them separate, and incident response becomes triage.

The choice that the architecture makes for you

Most agent identity platforms have made one of two choices, both of them costly. The first choice conflates agent identity with user authorization, meaning the agent lacks a stable identity of its own. The second choice ignores user authorization entirely, which means the agent operates with no principal-level accountability.

Neither choice works at the scale the agent economy is heading toward. Agents will run continuously, serve many users, cross organizational boundaries, and act under delegated authority that varies request by request. The identity stack has to hold all of that without losing information. The only way it holds is with two axes that stay orthogonal.

AGTP handles that work, so the application logic above it doesn’t have to. Agent-ID at the wire. OAuth at the application layer. Both carried on every request. Both are written into every signed receipt. Composable with the identity infrastructure organizations already operate.

What is calling, and who authorized it? Two questions, two answers, two layers. The protocol keeps them separate, so the rest of the system can keep working the way it always has.

---

If you find this content valuable, please share it with your network.

Follow me for daily insights.

Book me to speak at your next event.

Start managing your agents for free.

Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, is available now!