AI Agent Authentication vs Authorization: Reference Architecture
Separate AI agent authentication, service access, delegated authority and exact-action authorization with clear trust boundaries and control ownership.
AI agent authentication verifies an identity or credential. AI agent authorization decides whether that identity may perform a requested action. Enterprise agents need two further distinctions: access to a service and delegated business authority. Collapsing all four into a bearer token gives one compromised credential too much meaning.
The AI agent authorization implementation guide covers the complete decision path. This reference architecture makes the component boundaries explicit so an identity token is not mistaken for approval of a business action.
Draw four trust boundaries
[Agent runtime]
| signed request and access token
v
[Identity verifier] ---- who presented this credential?
v
[Resource server] ------ may it access this service?
v
[Authority service] ---- was this task delegated, under which limits?
v
[Policy enforcement] --- may this exact request run now?
v
[Domain system] -------- execute idempotently and report outcome
The boxes can share infrastructure, but their decisions should remain visible. The resource server validates issuer, signature, audience, expiry and scopes. The authority service resolves the represented organization, human or service and its grant. Policy compares the canonical request with that authority and current domain state.
Assign each control one job
| Control | It can establish | It cannot establish alone |
|---|---|---|
| workload identity | which runtime controls a key | who approved a purchase |
| access token | access to an intended API and scopes | exact amount or destination authority |
| agent registry | owner, version and lifecycle status | permission for this transaction |
| delegated grant | assigned actions and limits | whether live business state still permits them |
| policy decision | allow, deny or approval required | whether execution later succeeded |
| action receipt | what a signer recorded | that every source fact was true |
RFC 8707 defines resource indicators that help prevent a token intended for one resource being used at another. Sender-constrained mechanisms such as DPoP can reduce replay of a stolen bearer token. Neither substitutes for a business decision over the exact action.
Bind identity to the request
Do not trust caller-written identity headers. The gateway should remove them and regenerate verified context after authentication.
type VerifiedExecutionContext = {
tenantId: string;
principalId: string;
agentId: string;
credentialThumbprint?: string;
tokenAudience: string;
authorityDigest: string;
requestDigest: string;
};
The requestDigest should cover the action, resource, arguments, destination, transaction ID, nonce and expiry. The authorization result must return that digest. The execution adapter compares it immediately before dispatch.
For interactive authorization, keep the human and agent identities distinct. Record which person delegated authority, which agent acted and which organization is accountable. Avoid representing the agent as the human user in downstream logs.
Test boundary confusion
A useful architecture review includes negative paths:
- present a valid token to the wrong audience;
- inject
x-tenant-idand confirm the gateway replaces it; - disable an agent in the registry while its token remains valid;
- approve one request and submit a changed destination;
- call the domain service through a direct internal address;
- rotate the workload key and test old-key policy at event time.
The OAuth scopes and business authority comparison goes deeper on access tokens. Runtime authorization provides the enforcement contract. NIST's Digital Identity Guidelines are useful for identity assurance, while the AI Risk Management Framework covers broader AI governance and risk treatment.
Intelliger describes its current public product layers at Agent Trust. OATI is a developer preview, so deployment assurance must be evaluated in the customer's environment and independently reviewed before production use.
Architecture review questions
Is an agent a user, an application or a workload?
It can participate in all three relationships, but one identifier should not blur them. The organization or human is accountable, the logical agent has an owner and lifecycle, and each running instance uses a workload credential. Record the represented principal and acting agent separately. This lets a downstream service distinguish "the finance team through AP Agent" from a human interactive session and lets operators rotate one runtime key without changing the business identity.
Where should token exchange happen?
Place exchange in a trusted gateway or credential broker that knows the intended upstream resource. It should validate the inbound context, obtain a narrow upstream token and prevent the original credential from transiting to another server. Downstream services still validate issuer and audience. Record the actor, subject, source and target resources so an investigator can reconstruct which identity relationship was used without logging token values.
Does mutual TLS solve agent authorization?
Mutual TLS can authenticate workloads and protect a connection. It does not express the business task, amount, destination or approving person. Use it to secure the path between gateway and protected service, then pass verified, integrity-protected authorization context or require the service to resolve the decision. Do not accept caller-created authorization headers merely because the connection came from an internal network.
How does revocation cross the layers?
Disabling a workload key, agent record, delegated grant or user account answers different incident needs. Define which event should stop which requests and how quickly every enforcement point learns it. A compromised runtime may require key and grant revocation. An owner departure may suspend the agent pending reassignment. Test active sessions and queued work, since revocation that affects only newly issued tokens leaves a gap.
What evidence should each layer emit?
The identity verifier records the credential result and verified identifiers. The resource server records audience and scope enforcement. The authority service records grant status and constraints. Policy records the exact request digest and reasons. The domain adapter records dispatch and observed outcome. Correlate these records, but keep their claims separate. One gateway "success" event should not be presented as provider settlement or completed business work.
During architecture review, draw a bypass line around every box. Ask what happens if a caller reaches the resource server without the gateway, if a workload token survives agent suspension, or if an internal service trusts identity headers from any network peer. The answers should name an enforced service identity, network restriction or local decision check. "All normal traffic uses the gateway" is an operating assumption, not a control.