Identity Is Not Authority: Why Agent Passports Are Only Layer One

The Agent Identity Problem

You're building an AI agent that manages email on behalf of users. The agent needs to authenticate to Gmail. You reach for OAuth—the user grants permission, you get an access token, the agent can now act as the user.

Problem solved?

Not quite.

The OAuth token says "this agent can access Alice's email." It doesn't say:

• Can the agent send emails, or only read them?
• Can it email anyone, or only people Alice has emailed before?
• Can it delete emails, or only archive them?
• Can it forward emails externally?

The token is a passport. It proves identity—"this is Alice's authorized agent." But passports don't encode authority. They don't specify what actions are permitted in this particular context, at this particular moment, for this particular task.

You've solved layer one. Layer two is where things get interesting.

Identity vs. Authority

These concepts are often conflated. They shouldn't be.

OAuth, API keys, JWTs from your IdP—these are identity artifacts. They prove the agent is who it claims to be. They don't prove the agent should be allowed to take a specific action.

When you conflate identity with authority, you get coarse-grained access control. The email agent either has "full email access" or no access. The marketplace agent either can "manage listings" or can't. There's no middle ground, no scoping, no attenuation.

This is fine for simple applications. It breaks down for agents.

Why OAuth Doesn't Scale to Delegation

Consider a more complex scenario. Alice has an executive assistant agent. The assistant delegates to specialized sub-agents:

• Email agent: handles correspondence
• Calendar agent: manages scheduling
• Expense agent: processes reimbursements

The assistant holds Alice's OAuth tokens. How do the sub-agents authenticate?

Option 1: Share the tokens

Each sub-agent gets a copy of Alice's OAuth token. This works, but now:

• Every sub-agent has full access to Alice's identity
• If the email agent is compromised, it can access calendar and expenses
• There's no audit trail of which sub-agent took which action
• You can't revoke one sub-agent without revoking all of them

Option 2: Each sub-agent gets its own OAuth flow

Alice grants permissions to each sub-agent separately. This works, but:

• Alice has to approve every sub-agent (scaling nightmare)
• Sub-agents have persistent access (not task-scoped)
• The relationship between assistant and sub-agents isn't captured
• Revoking the assistant doesn't automatically revoke sub-agents

Option 3: The assistant proxies all requests

Sub-agents send requests to the assistant, which uses its tokens. This works, but:

• The assistant becomes a bottleneck
• You lose parallelism
• The assistant is now a confused deputy—it can't distinguish legitimate sub-agent requests from malicious ones

Mandates: Authority Artifacts

The missing primitive is a mandate—a short-lived, cryptographically signed assertion of delegated authority.

A mandate contains:

Signer: Who issued this mandate? The signer vouches that the authority was legitimately delegated. This creates a trust chain back to the original identity.

Scope: What specific actions are authorized? Not "email access" but "send email to bob@company.com with subject matching /^Re: Q3 Planning/". Scopes are narrow by design.

Expiry: When does this authority expire? Mandates are short-lived—seconds to minutes. If an agent is compromised, the blast radius is temporally bounded.

Lineage: What's the delegation chain? If Alice delegated to assistant, and assistant delegated to email agent, the mandate captures this provenance. You can trace any action back through the chain.

Here's what a mandate might encode:

1{
2"mandate_id": "m_7f3a...",
3"signer": "assistant-agent-001",
4"principal": "email-agent-003",
5"scope": {
6  "action": "email.send",
7  "resource": "alice@company.com",
8  "constraints": {
9    "recipient_domain": "company.com",
10    "max_attachments": 0
11  }
12},
13"issued_at": "2024-01-15T10:30:00Z",
14"expires_at": "2024-01-15T10:35:00Z",
15"parent_mandate_id": "m_2b8c...",
16"delegation_depth": 2
17}

This mandate says: the email agent can send one email from Alice's account, but only to company.com addresses, with no attachments, and only for the next 5 minutes. The authority was delegated through the assistant agent.

Trust Mandate Semantics, Not Agent Claims

Here's the critical insight: receiving systems should validate mandates, not trust agent assertions.

When the email agent calls Gmail's API, it shouldn't just present Alice's OAuth token. It should present:

1. The OAuth token (proving Alice's identity chain)
2. The mandate (proving scoped authority for this specific action)

The receiving system validates both:

• Is the OAuth token valid? (identity check)
• Is the mandate validly signed? (cryptographic check)
• Does the mandate's scope cover this action? (authority check)
• Is the mandate still within its validity window? (expiry check)
• Is the mandate revoked? (revocation check)

If any check fails, the request is denied. The email agent can claim whatever it wants—the receiving system doesn't trust claims, it validates proofs.

This is the same pattern as bearer tokens, but with richer semantics. The mandate isn't just "this entity is authenticated." It's "this entity has been authorized to do this specific thing, by this chain of delegators, until this time."

Examples in Practice

Email Agent

Without mandates:

1Email Agent → Gmail API
2"I have Alice's OAuth token, trust me to send this email"

Gmail can't distinguish between "Alice explicitly asked for this email" and "some sub-sub-agent decided to send this email." The access control is binary: allowed or denied.

With mandates:

1Email Agent → Gmail API
2"Here's Alice's OAuth token (identity) and a mandate from Alice's assistant
3authorizing me to send to bob@company.com, expiring in 5 minutes (authority)"

Gmail validates the mandate chain. The access control is contextual: this specific action, authorized through this specific delegation path, valid for this specific window.

Marketplace Agent

An agent manages a user's product listings on an e-commerce platform. The user delegates "manage my store" to a primary agent, which delegates to specialized agents:

• Pricing agent: adjusts prices based on competition
• Inventory agent: updates stock levels
• Listing agent: creates new product listings

Without mandates, each agent has "full store access." The pricing agent could create listings. The inventory agent could change prices. There's no enforcement of specialization.

With mandates, each agent receives authority only for its domain:

1// Pricing agent
2{"action": "listing.update", "fields": ["price"], "constraints": {"max_delta_percent": 10}}
3
4// Inventory agent
5{"action": "listing.update", "fields": ["stock_count"]}
6
7// Listing agent
8{"action": "listing.create", "constraints": {"category": "electronics"}}

The marketplace validates mandates. A pricing agent trying to create a listing fails—not because the agent is "well-behaved," but because its mandate doesn't authorize that action.

LinkedIn Agent

A networking agent operates on behalf of a professional. The user authorizes "help me network," but with constraints:

• Connect with relevant professionals
• Never message recruiters
• Don't accept connection requests from competitors

Without mandates, you're trusting the agent's prompt to enforce these constraints. The agent could be injected, drift, or simply hallucinate a different policy.

With mandates, each action requires specific authorization:

1// Connection send mandate
2{"action": "connection.send", "constraints": {"industry": ["software", "ai"], "exclude_titles": ["recruiter"]}}
3
4// Connection accept mandate
5{"action": "connection.accept", "constraints": {"exclude_companies": ["competitor-a", "competitor-b"]}}

The receiving system (whether LinkedIn's API or a proxy) validates constraints before allowing the action. The agent's beliefs about what it should do are irrelevant—only the mandate matters.

Why Identity Collapses Under Delegation

The fundamental problem: identity is about entities, but authority is about relationships and context.

Alice's identity doesn't change when she delegates to an assistant. The assistant's identity doesn't change when it delegates to sub-agents. But the authority changes at every step:

1. Alice has full authority over her accounts (by definition)
2. Alice delegates "manage professional communications" to assistant
3. Assistant delegates "send follow-up emails" to email agent
4. Email agent should only have authority for the specific follow-up emails, not "full email access"

If you only track identity, you lose this attenuation. The email agent either has "Alice's email access" or doesn't. There's no way to express "subset of Alice's email access, for this specific purpose, delegated through this specific chain, expiring at this specific time."

The Two-Layer Model

Production agent systems need both layers:

The identity layer establishes who. The authority layer establishes what, where, when, and through whom.

Receiving systems validate both. A valid identity with no valid mandate = denied. A valid mandate from an invalid identity = denied. Both must check out.

Implementation Implications

If you're building agent infrastructure:

Separate identity from authority. Don't overload OAuth scopes with fine-grained permissions. Use OAuth for identity; use mandates for authority.

Make mandates short-lived by default. 5 minutes, not 5 hours. If an agent needs longer, it can request renewal. Short-lived mandates bound the damage from compromise.

Enforce scope attenuation. When agent A delegates to agent B, B's scope must be a subset of A's. Never allow scope expansion through delegation.

Track lineage. Every mandate should point to its parent. This enables "revoke all authority derived from mandate X" without tracking every downstream delegation.

Validate at the edge. Receiving systems (APIs, browsers, databases) should validate mandates, not trust assertions. The agent's claim of authority means nothing without cryptographic proof.

Design for revocation. You need to invalidate mandates mid-stream. Parent revocation should cascade to children. This requires mandate IDs and a revocation check in the validation path.

Conclusion

Identity is necessary but not sufficient for agent authorization. Knowing that an agent represents Alice doesn't tell you what the agent should be allowed to do, in what context, for how long, or through what delegation chain.

The missing primitive is the mandate: a short-lived, cryptographically signed assertion of delegated authority with explicit scope, expiry, and lineage.

Agent systems that conflate identity with authority will struggle with delegation. Every sub-agent either gets full access (insecure) or no access (impractical). There's no graceful degradation, no contextual scoping, no traceable provenance.

Layer one—identity—is solved. We have OAuth, OIDC, SAML, API keys. These work.

Layer two—authority—is the frontier. Mandates, scope attenuation, delegation chains, receiving-system validation. This is where agent infrastructure needs to go.

Your agent passport gets you in the door. The mandate determines which rooms you can enter.

Related Documentation

• Python Predicate-Runtime SDK →
• TypeScript Predicate-Runtime SDK →
• Predicate-Runtime SDK Examples →