Agent Authentication
Protocol

Motivation & Problem Statement

AI agents are acting on behalf of users at services they've never visited. Existing authentication protocols assume a human is present. They aren't.

The agentic era introduces a category of principal the web was not designed for: an automated system acting with delegated human authority, making decisions at machine speed, across services that have no prior relationship with the agent or its operator.

Three questions must be answered for every agentic interaction:

Existing approaches — hardcoded API keys, standard OAuth, session cookies — fail at least one of these questions when applied to agents. Section 8 (Alternatives) documents each approach and why it was not chosen.

Trust Model

Trust is not binary. AAP defines four trust tiers that services can accept based on their risk tolerance.

2.1 The Three Trust Anchors

2.2 Tier Definitions

Services declare in their discovery manifest which tier they require. Agents that cannot meet the required tier must not proceed and should inform the user that manual authorization is needed.

Service Discovery

Every service participating in AAP MUST host a machine-readable manifest at a predictable path. An optional human-readable companion document MAY be co-located.

Required path

GET /.well-known/agent-auth.json

Manifest schema

JSON{
  "spec": "aap/1.0",
  "service": "https://api.example.com",
  "display_name": "Example API",

  "minimum_tier": 2,           // T1–T4, service decides

  "scopes": [
    { "id": "data.read", "description": "Read user data" },
    { "id": "data.write", "description": "Modify user data" }
  ],

  "intent_required": true,       // agent must declare X-Agent-Intent
  "credential_ttl": 3600,       // max seconds before re-assertion
  "scope_expansion": "notify",  // "reject" | "notify" | "silent"

  "endpoints": {
    "register":  "/agent/register",
    "delegate":  "/agent/delegate",
    "revoke":    "/agent/revoke",
    "audit":     "/agent/audit"      // MANDATORY — see §7
  }
}

The agent discovers this document on first encountering a 401 response that includes the header WWW-Authenticate: Bearer agent_auth_required="/.well-known/agent-auth.json". Agents SHOULD proactively fetch this document before making any API call if they have reason to believe a service participates in AAP.

3.1 Multi-Tenant Discovery

The base spec assumes a single-tenant deployment: one domain, one discovery manifest, one set of scopes and policies. In practice, many AAP-implementing services are multi-tenant platforms — a single deployment serves many isolated projects or tenants, each with its own scopes, minimum trust tier, and auto-revoke policies. Firebase, Auth0, WorkOS, and Clerk all follow this model. This section defines how AAP discovery works in that context.

The problem

A multi-tenant auth service cannot serve a single global agent-auth.json that accurately describes every tenant. Project A may require T3 with DPoP; Project B may accept T1 without it. The endpoint URLs, available scopes, and safety configuration are all project-specific. Without guidance, implementers will invent incompatible solutions — custom headers, non-standard paths, or out-of-band configuration.

Two approaches

Multi-tenant services SHOULD support one of the following patterns for project-scoped discovery. Both keep the /.well-known/agent-auth.json path intact (preserving spec compliance and agent expectations) while allowing per-project configuration.

Pattern A: Query parameter scoping (RECOMMENDED)

The discovery endpoint accepts an optional projectId query parameter. When absent, it returns the service-level defaults — the platform's baseline capabilities, supported algorithms, and endpoint URL templates. When present, it returns the project-specific configuration with resolved endpoint URLs.

Service-level (no project)GET /.well-known/agent-auth.json

{
  "spec": "aap/2.0-draft",
  "service": "https://auth.example.com",
  "display_name": "Example Auth Platform",
  "minimum_tier": 1,
  "endpoints": {
    "register":  "/internal/projects/{projectId}/agent/register",
    "delegate":  "/internal/projects/{projectId}/agent/delegate",
    "revoke":    "/internal/projects/{projectId}/agent/revoke",
    "audit":     "/internal/projects/{projectId}/agent/audit"
  }
}

Project-scopedGET /.well-known/agent-auth.json?projectId=acme-prod

{
  "spec": "aap/2.0-draft",
  "service": "https://auth.example.com",
  "display_name": "Example Auth Platform",
  "project_id": "acme-prod",
  "minimum_tier": 3,
  "endpoints": {
    "register":  "/internal/projects/acme-prod/agent/register",
    "delegate":  "/internal/projects/acme-prod/agent/delegate",
    "revoke":    "/internal/projects/acme-prod/agent/revoke",
    "audit":     "/internal/projects/acme-prod/agent/audit"
  },
  "dpop_required": true
}

The service-level response uses URI templates (RFC 6570) with {projectId} placeholders in endpoint URLs. This tells the agent "you need a project ID to proceed" without requiring out-of-band documentation. Agents that already know their target project ID can skip the service-level call entirely and go straight to ?projectId=X.

This pattern is the simplest to implement — no infrastructure changes, no subdomain routing, no wildcard DNS. It mirrors how platforms like Firebase resolve project context via an API key in the query string.

Pattern B: Subdomain routing

Each project is assigned a subdomain. The agent queries /.well-known/agent-auth.json on the project's subdomain, and the response is inherently project-scoped because the domain itself identifies the tenant.

Subdomain-scopedGET https://acme-prod.auth.example.com/.well-known/agent-auth.json

{
  "spec": "aap/2.0-draft",
  "service": "https://acme-prod.auth.example.com",
  "project_id": "acme-prod",
  "minimum_tier": 3,
  "endpoints": {
    "register":  "/agent/register",
    "delegate":  "/agent/delegate",
    "revoke":    "/agent/revoke",
    "audit":     "/agent/audit"
  },
  "dpop_required": true
}

This is the cleanest from the agent's perspective — each project looks like a standalone AAP-compliant service with unmodified endpoint paths. However, it requires wildcard DNS (*.auth.example.com), wildcard TLS certificates, and subdomain-to-project routing middleware. This overhead is justified for platforms that already use subdomain isolation (e.g., Shopify, Heroku) but is excessive for most deployments.

What stays service-level

Regardless of the multi-tenant pattern chosen, the following endpoints MUST remain service-level (not project-scoped), because they describe the operator's platform identity and signing keys which are shared across all projects:

• /.well-known/agent-identity.json — operator identity manifest (DNS-anchored to the platform domain)
• /.well-known/agent-jwks.json — operator signing keys (used to verify all operator JWTs regardless of project)

Signing keys are infrastructure — they belong to the platform, not to any individual tenant. Per-project signing keys would multiply key management complexity without meaningful security benefit, since the trust anchor is DNS control of the platform domain, not the project identifier.

Implementation requirements

Multi-tenant services implementing AAP MUST:

• Ensure complete data isolation between projects. A delegation created in Project A MUST NOT be usable in Project B. Access tokens, audit events, and usage counters are all project-scoped.
• Include project_id in the project-scoped discovery response so agents can confirm they received the configuration for the intended project.
• Return 404 (not 200 with defaults) when ?projectId=X references a project that does not exist, to prevent agents from silently operating against a nonexistent tenant.
• Validate the project context on every operational endpoint — registration, delegation, revocation, and audit — not just at discovery time.

Operator Identity via DNS

The operator identity problem is the same problem TLS solved for websites: how do you know you're talking to who you think you're talking to? The answer is the same — DNS and public-key cryptography.

Any entity deploying an AAP-compliant agent MUST host an identity manifest on their own domain. This file is the operator's identity card. It can be fetched and verified by any service without calling any third party.

Required path (on operator domain)

GET https://acme.com/.well-known/agent-identity.json

Identity manifest schema

JSON{
  "operator":       "Acme Corp",
  "domain":         "acme.com",
  "contact":        "security@acme.com",
  "since":          "2025-01-01",

  "signing_keys":   "https://acme.com/.well-known/agent-jwks.json",

  "model_providers": [
    "anthropic.com",
    "openai.com"
  ],

  // Optional: link to provider-published operator registries
  "provider_registry_urls": [
    "https://anthropic.com/.well-known/agent-operators.json"
  ]
}

4.1 How Verification Works

When an agent presents a JWT claiming to be from acme.com, the receiving service:

4.2 Model Provider Registries (Optional, T4)

Model providers MAY publish a list of verified operators at a well-known path. This is purely additive — services that want T4 guarantees can cross-reference this list. Providers are not required to participate for the base protocol to function.

GET https://anthropic.com/.well-known/agent-operators.json

JSON{
  "published": "2026-06-01T00:00:00Z",
  "operators": [
    {
      "domain":    "acme.com",
      "verified":  "2025-03-15",
      "standing":  "good"     // "good" | "suspended" | "revoked"
    }
  ]
}

This mirrors certificate transparency logs — Anthropic doesn't sign individual tokens, they simply maintain a public, inspectable list. Far lower operational burden than per-request signing.

User Delegation

Operator identity answers "who built this agent." User delegation answers "did a real user at this service authorize it." These are separate claims requiring separate mechanisms.

5.1 Bootstrap Flow

When an agent discovers it lacks a delegation token for a given service, it MUST surface this to the user rather than proceeding anonymously or fabricating credentials.

5.2 Delegation Token Structure

The delegation token is a JWT signed by the service's own keys. It proves the service recognized this user and approved this specific operator's agent to act for them.

JWT PAYLOAD{
  "iss":          "api.example.com",      // service-signed
  "sub":          "john@example.com",
  "delegated_to": "acme.com",          // operator domain
  "delegation_id":"del_k9x2mq",
  "scopes":       ["data.read", "data.write"],
  "iat":          1748822400,
  "exp":          1780358400,           // long-lived; revocable via /agent/revoke
  "max_agent_ttl":3600                  // max TTL for derived access tokens
}

This token is never sufficient on its own to make API calls — it must be combined with a valid operator JWT. Possession of the delegation token without the matching operator private key is useless.

Per-Task Consent & Scope

Having authorization to access a service is not the same as having authorization for a specific action. The consent receipt closes this gap.

6.1 Consent Receipt

Before an agent begins a task that requires acting on a service, the operator's platform MUST present the user with a clear description of what the agent intends to do, and record their approval as a signed consent receipt.

JWT PAYLOAD{
  "iss":           "acme.com",           // operator-signed
  "delegation_id": "del_k9x2mq",
  "user":          "john@example.com",
  "consented_at":  1748822400,
  "intent":        "Schedule a meeting with Sarah next week",
  "scopes":        ["calendar.read", "calendar.write"],
  "consent_method":"explicit_ui",
  "session_id":    "sess_p7q3wr",
  "exp":           1749427200            // short-lived: hours to days
}

6.2 Per-Request Intent Headers

Every API call made by an agent under an AAP credential MUST include an intent header. Services log this. They do not verify truthfulness — but the header creates an auditable trail the user can review.

HTTP REQUESTPOST /calendar/events HTTP/1.1
Authorization:    Bearer <access_token>
X-Agent-Delegation: del_k9x2mq
X-Agent-Consent:    <consent_receipt_jwt>
X-Agent-Intent:     "Booking team standup for Monday 9am"
X-Agent-Session:    sess_p7q3wr

6.3 Scope Expansion

If an agent determines mid-task that it needs a scope beyond what the consent receipt granted, the behavior is governed by the service's declared scope_expansion policy:

Complete Request Flow

Combining all three layers, a fully verified AAP request works as follows. This example shows a T3 (Consented) interaction after bootstrap has already occurred.

7.1 Mandatory Audit Endpoint

AAP requires all participating services to expose /agent/audit. This is non-negotiable. Agents are only trustworthy if users can inspect what they did.

HTTPGET /agent/audit?delegation_id=del_k9x2mq

[
  {
    "timestamp":  "2026-06-02T10:14:22Z",
    "method":     "POST",
    "path":       "/calendar/events",
    "intent":     "Booking standup Monday 9am",
    "session_id": "sess_p7q3wr",
    "outcome":    "201 Created"
  }
]

Revocation

Revocation is a first-class concern, not an afterthought. The protocol is designed so revocation propagates quickly with minimal infrastructure. AAP defines three revocation modes: short TTLs as a structural default, explicit manual revocation, and declarative auto-revoke policies that fire without human intervention.

8.1 Short TTLs as Primary Mechanism

Access tokens MUST expire within the credential_ttl declared by the service (default 3600 seconds). Refresh requires re-presenting the operator JWT, delegation token, and a valid consent receipt. If any of these have been revoked, refresh silently fails and the agent loses access — no push infrastructure required.

8.2 Explicit Revocation

8.3 Auto-Revoke Policies

Manual revocation assumes someone remembers to act. In practice, consents accumulate, tasks complete without cleanup, users leave organisations, and nobody audits the connected-agents screen unless something breaks. Auto-revoke policies close the gap between what the user intended — temporary, purposeful access — and what actually happens without them.

Auto-revoke policies are declarative and forward-looking. They are defined at grant time and enforced automatically by the service without requiring any subsequent human action.

Policy Triggers

8.4 Layered Policy Minimums

Three parties may declare auto-revoke policies: the service, the operator, and the user. Policies are not negotiated — the most restrictive value across all three always wins. This is computed at grant time into an effective_policy stored in the delegation token.

Auto-Revoke Policy — Layered Resolution{
  "auto_revoke_policy": {

    // Service declares minimums — operator and user cannot override upward
    "service_minimum": {
      "max_duration":       "90d",
      "after_inactivity":   "30d",
      "on_events":         ["user.offboarded", "org.subscription_cancelled"]
    },

    // Operator declares defaults for their agents
    "operator_default": {
      "after_inactivity":    "14d",
      "on_task_completion":  true
    },

    // User may tighten further — never loosen
    "user_override": {
      "after_duration":      "7d"
    },

    // Computed at grant time. Stored in token. Authoritative.
    "effective_policy": {
      "expires_at":          "2026-06-09T10:00:00Z",  // min(90d, 7d) = 7d from grant
      "after_inactivity":    "14d",                    // min(30d, 14d)
      "on_task_completion":  true,
      "on_events":          ["user.offboarded", "org.subscription_cancelled"]
    }
  }
}

8.5 Revocation Notifications

Auto-revoke without notification creates silent failures — the agent stops working and nobody knows why. The spec requires a notification chain on every auto-revoke event:

Services MUST include an X-Agent-Revoke-Reason header on 401 responses caused by revocation, distinguishing them from ordinary auth failures. Valid values: policy_expired, inactivity, task_complete, event_triggered, manual_revoke, key_rotation.

Security Considerations

Good token design is necessary but not sufficient. Several structural vulnerabilities exist in any bearer-token protocol that AAP must explicitly address.

13.1 Token Binding — The Stolen Token Problem

Every token in AAP is currently a bearer token: whoever holds it can use it. If a delegation token or consent receipt is intercepted — via logging pipeline leakage, compromised cloud storage, or a man-in-the-middle — it can be replayed by the attacker with no way for the service to distinguish the attacker from the legitimate agent.

This matters more for agents than browsers because agents run in cloud infrastructure with shared environments, multiple processes, and verbose logging — all surfaces where tokens can leak in ways a browser session wouldn't.

AAP RECOMMENDS implementing DPoP (Demonstrating Proof of Possession, RFC 9449) for access tokens. The agent generates an ephemeral keypair per session. The public key is bound into the access token at issuance. On every request, the agent includes a signed DPoP proof header. A stolen token without the matching private key is useless.

DPoP Flow1. Agent  →  generates ephemeral keypair (per session)
2. Agent  →  Service  includes public key in registration request
3. Service →  issues access_token bound to that public key
4. Agent  →  Service  every request carries DPoP proof header (signed by private key)
5. Service ⟳  verifies proof signature — stolen token without key = rejected

Services that require T3 or T4 trust SHOULD require DPoP. Services at T1 or T2 MAY accept plain bearer tokens where DPoP implementation is impractical.

13.2 Agent Impersonation

The spec verifies operator identity to the service — but the user never independently sees this verification. A malicious operator could build an agent that mimics the UI and name of a trusted operator. The service correctly identifies the request as coming from the malicious operator's domain, but the user believes they are using the trusted one. This is phishing at the agent layer.

Mitigations AAP requires:

Operator identity surfaced to users. The operator's verified domain MUST be displayed in the agent's UI at bootstrap and accessible at any time thereafter. Users must be able to see which domain's agent they are using, not just the display name the operator chose for themselves.

Display name ≠ identity. Services MUST NOT accept display names as identity claims. Only the cryptographically verified operator domain is identity. The discovery manifest may include a display name, but relying parties must treat it as decorative.

Phishing-resistant bootstrap. The bootstrap OAuth flow (§5.1) MUST open in the service's own browser context, not an in-app webview controlled by the operator. An operator controlling the webview could intercept credentials. This is the same requirement as OAuth 2.0 best practices (RFC 8252).

13.3 Multi-Tenancy and Session Isolation

Most agent platforms are multi-tenant: one deployment serves thousands of users. The same operator JWT covers all of them. A bug in the platform could cause user A's delegation token to appear in user B's session. For how multi-tenant services handle AAP discovery and endpoint scoping, see §3.1.

AAP requires the following isolation properties:

Session IDs must be cryptographically unguessable and generated fresh per task, not derived from user identifiers or timestamps. UUID v4 minimum; CSPRNG-derived preferred.

Delegation tokens are non-transferable. A token issued for acting_for: john@example.com MUST be rejected if presented in a request where the session context indicates a different user. Services MUST validate that the acting_for claim matches the authenticated session context on every request, not just at registration.

Concurrent session detection. Services SHOULD flag when the same delegation_id is used simultaneously from two different IP addresses or geographic regions. This is a signal of either token theft or a platform isolation failure. The appropriate response is to suspend the delegation pending operator notification rather than silently accept both sessions.

13.4 Protocol Version Negotiation

The spec will evolve. Without version negotiation, a service built on AAP/1.0 cannot safely interact with an agent implementing AAP/2.0 — neither knows what the other expects, and silent incompatibility produces unpredictable behaviour.

The discovery manifest MUST declare supported spec versions from day one:

Discovery Manifest — Version Field{
  "spec_versions_supported": ["aap/1.2", "aap/1.1"],
  "spec_version_preferred":   "aap/1.2"
}

Every agent registration request MUST declare its implemented spec version. If the service does not support the agent's version, it returns a 400 with X-AAP-Version-Required listing its supported versions. Agents MUST NOT proceed with an unsupported version — silent degradation is not permitted.

Safety & Trust

Identity verification tells you who is acting. It does not tell you whether what they are about to do is safe, reversible, or within what the user actually meant. This section addresses the gap.

14.1 Irreversible Action Safeguards

A correctly authenticated agent with valid scopes can still take actions the user never intended — because intent declarations are not verified, and some actions cannot be undone. Deleting data, sending communications, making payments, and publishing content are categorically different from read operations: they have real-world consequences that persist beyond any revocation.

AAP defines three safeguards for irreversible operations:

Dry-run mode. Services exposing mutating operations MUST implement a dry-run endpoint that returns what an action would do without committing it. Agents SHOULD call dry-run before any destructive operation and surface the result to the user when the task involves ambiguity.

HTTPPOST /calendar/events?dry_run=true
→ returns { "would_create": {...}, "conflicts": [...] } without committing

Undo window. For destructive operations (delete, send, publish, pay), services SHOULD implement a short reversibility window — a grace period during which the action can be cancelled. The window duration is declared in the scope schema. Agents MUST expose an abort mechanism to the user during this window.

Scope Schema — Undo Window{
  "id":             "mail.send",
  "irreversible":  true,
  "undo_window_s": 30,           // 0 means no undo supported
  "undo_endpoint": "/mail/cancel-send"
}

Pre-action confirmation for high-risk scopes. Certain scope actions MUST require an explicit confirmation signal from the agent before execution, regardless of what the consent receipt granted. Services declare these in the scope schema as "requires_confirmation": true. The agent sends a confirmation token in the request header; without it the service returns 428 Precondition Required.

14.2 Usage Limits

A consent receipt grants what an agent can do. It says nothing about how much. An agent with calendar.write could create one event or ten thousand. A compromised or buggy agent can cause significant damage within its authorized scope with no rate signal in the current protocol.

The consent receipt and service account delegation token SHOULD include a usage_limits block. Services enforce these as hard limits; exceeding them triggers a 429 with X-Agent-Limit-Reason and requires re-consent to continue rather than a silent failure or abuse flag.

Consent Receipt — Usage Limits{
  "intent":        "Schedule team standups for this week",
  "scopes":        ["calendar.write"],
  "usage_limits": {
    "requests_per_hour":  60,
    "writes_per_session": 10,
    "max_data_egress_kb": 500
  }
}

14.3 Cumulative Consent Visibility

A user approves an agent for calendar.read in January, calendar.write in February, contacts.read in March. By April the agent has extensive access, but no single consent review made this visible. The user never saw "this agent has access to your calendar and your contacts" — only three isolated prompts.

The spec requires services to expose a cumulative consent view — a dedicated endpoint showing the agent's total current access, not a log of historical approvals:

HTTPGET /agent/access-summary?delegation_id=del_k9x2mq

{
  "agent":           "acme.com",
  "acting_for":     "john@example.com",
  "active_since":   "2026-01-15",
  "current_scopes": ["calendar.read", "calendar.write", "contacts.read"],
  "effective_policy": { "expires_at": "2026-07-15", "after_inactivity": "14d" },
  "last_active":    "2026-06-02T09:14:00Z",
  "revoke_url":     "/agent/revoke?delegation_id=del_k9x2mq"
}

Operators MUST surface this view in their product UI. The unit of display is total current access — not historical approvals. A one-click revoke from this view MUST be supported.

14.4 Liability Acknowledgement

When an agent causes harm — deletes data, sends an unintended communication, makes an unauthorized purchase — the protocol creates a clear audit trail but does not resolve who bears liability. This gap will not stop developers from building, but it will stop enterprises and regulated industries from deploying at scale.

AAP cannot resolve liability — it is a legal and commercial question beyond the scope of a technical protocol. However, the spec requires that operators surface a liability disclosure to users at bootstrap time, before first agent action:

Bootstrap — Liability Disclosure (required)// Displayed to user before they approve delegation
"If this agent takes an action that causes unintended harm or data loss,
 [Operator Name] is responsible for investigating and remediating the issue.
 You can revoke this agent's access at any time from your connected agents
 dashboard. Actions taken before revocation may not be reversible."

The disclosure content is the operator's responsibility. The requirement that it be displayed — in plain language, before first action, not buried in terms of service — is the protocol's. Making the liability gap visible and attributable is better than ignoring it.

Approaches Considered & Rejected

Every design decision is a rejection of alternatives. What follows is an honest accounting of what was evaluated and why each path was not taken.

Comparative Analysis

✓ fully satisfies · ~ partially satisfies · ✗ does not satisfy

Identity Modes

Inspired by Harrison Chase's framing at LangChain Interrupt: agents either act as a specific user or as themselves on behalf of an organisation. Both are legitimate. Both require different trust chains. Both must be declared and disclosed.

AAP defines two first-class identity modes. The mode governs which bootstrap flow is used, what the delegation token looks like, what audit granularity is required, and — critically — what the end user must be told before the agent acts.

11.1 Mode Declaration

Every AAP registration request MUST declare its mode explicitly. There is no default. Omitting mode is a protocol error.

Mode A — User-Delegated{
  "mode":           "user_delegated",
  "acting_for":    "john@example.com",
  "delegation_id": "del_k9x2mq",
  "operator_jwt":  "<signed by acme.com>",
  "consent_receipt":"<task-scoped consent JWT>"
}

Mode B — Service Account{
  "mode":             "service_account",
  "operator":         "acme.com",
  "account_id":       "svc_acme_prod",
  "authorized_by":    "admin@acme.com",
  "org_id":           "org_acme_7x2",
  "granted_scope":    "engineering-team",  // declared at setup — could be narrow or wide
  "operator_jwt":     "<signed by acme.com>",
  "svc_delegation":   "<service-account delegation JWT>"
}

11.2 Service Account Bootstrap

Mode B has no user to bootstrap with. The bootstrap actor is an admin who explicitly reviews and approves the scope being granted — which may be narrow (a single shared inbox) or wide (all documents in an org). The defining requirement is not breadth but explicitness: the admin must see exactly what they are granting before confirming, and that grant is recorded precisely in the delegation token.

11.3 Service Account Delegation Token

JWT PAYLOAD — Service Account Delegation{
  "iss":             "api.example.com",     // service-signed
  "sub":             "svc_acme_prod",       // service account id, not a user
  "delegated_to":    "acme.com",
  "authorized_by":   "admin@acme.com",
  "org_id":          "org_acme_7x2",

  // Exact scope granted at bootstrap. Encodes what the admin approved.
  // May be narrow ("engineering-team inbox") or wide ("all-org documents").
  // No default. No implicit expansion. This field is authoritative.
  "granted_scope": {
    "description":  "Engineering team shared inbox",
    "resources":    ["inbox:eng-team@acme.com"],
    "scopes":       ["mail.read", "mail.label"],
    "crosses_users": true        // true if any resource spans >1 user; false otherwise
  },

  "iat":             1748822400,
  "exp":             1780358400
}

11.4 Elevated Audit Requirements for Mode B

The audit requirement for Mode B tracks what the agent actually touched within its declared scope — regardless of how narrow or wide that scope is. When crosses_users: true in the delegation token, services MUST additionally log data_subjects on every operation, so it is always possible to determine whose data was accessed even when the agent isn't acting for a named user.

Mode B Audit Entry (crosses_users: true){
  "timestamp":      "2026-06-02T10:14:22Z",
  "mode":           "service_account",
  "account_id":     "svc_acme_prod",
  "method":         "POST",
  "path":           "/messages/label",
  "intent_type":    "LABEL_MESSAGE",
  "data_subjects":  ["user_a", "user_b"],  // required when crosses_users: true
  "outcome":        "200 OK"
}

Mode B Audit Entry (crosses_users: false — single resource){
  "timestamp":      "2026-06-02T10:14:22Z",
  "mode":           "service_account",
  "account_id":     "svc_acme_bot",
  "method":         "GET",
  "path":           "/documents/shared-roadmap",
  "intent_type":    "READ_DOCUMENT",
  // data_subjects omitted — single shared resource, no per-user data touched
  "outcome":        "200 OK"
}

11.5 Mandatory User Disclosure

Harrison Chase's key practical point: users must know which mode they're dealing with, because their expectations around privacy and data access are completely different. AAP makes this mandatory.

The service discovery manifest MUST declare which modes it supports and MUST include a human-readable disclosure string for each. Operators MUST surface the relevant disclosure to end users before first interaction — not in terms of service, not on a settings page, but in the agent's UI at the point of first use.

Discovery Manifest — Mode Disclosures{
  "identity_modes_supported": ["user_delegated", "service_account"],
  "disclosures": {
    "user_delegated":
      "This agent uses your personal credentials. It can only see data you have access to. Different users will receive different responses.",
    "service_account":
      "This agent uses fixed credentials authorised by your admin. It does not act as you personally. Its access is limited to: {granted_scope.description}."
      // {granted_scope.description} is populated from the delegation token at disclosure time.
      // e.g. "Engineering team shared inbox" or "All documents in your organisation"
      // Operators must not substitute a generic string — it must reflect actual granted scope.
  }
}

11.6 Mixed-Mode Sessions

A single agent task may legitimately invoke both modes — for example, reading shared org documents via service account and sending an email via user-delegated credentials. This is expected and supported, but each action must carry its mode explicitly.

The per-request headers are extended to carry mode context:

HTTP REQUEST — Mixed Mode// Service account call
GET /org/documents/q3-report
Authorization:       Bearer <svc_access_token>
X-Agent-Mode:        service_account
X-Agent-Account:     svc_acme_prod
X-Agent-Intent-Type: READ_DOCUMENT
X-Agent-Session:     sess_p7q3wr

// User-delegated call in same session
POST /mail/send
Authorization:       Bearer <user_access_token>
X-Agent-Mode:        user_delegated
X-Agent-Delegation:  del_k9x2mq
X-Agent-Intent-Type: SEND_MESSAGE
X-Agent-Session:     sess_p7q3wr

The session ID ties both calls to the same task, while the mode header ensures each is audited under the correct rules. Services must not infer mode from context — it must be declared per request.

11.7 Mode Comparison

Resolved Questions

Questions raised in v1.0 as open. Each is now resolved with a defined position. Rationale is included so the reasoning is preserved, not just the decision.

12.1 Cross-Operator Delegation (Agent-to-Agent)

When Agent A delegates to Agent B — particularly when they belong to different operators — accountability diffuses. The user authorized A, not B. Under current legal frameworks, liability would chase the chain back to A's operator, but this becomes untenable as chains lengthen and cross organizational boundaries.

The temptation to support this early is real: multi-agent workflows are genuinely useful. But getting the accountability model wrong and trying to fix it later is harder than deferring. When cross-operator delegation is eventually specified, the consent receipt will be required to explicitly name every agent in the chain at consent time. Dynamic agent discovery that adds agents mid-task without user awareness will require fresh consent. Ambient re-delegation is never permitted.

Same-operator delegation (Agent A spawning Agent B within the same operator) is permitted under the existing consent receipt model, provided the session ID links all actions to the same user-approved task.

12.2 Offline Agents

The consent receipt's exp field is interpreted as an execution window, not merely a token expiry. When the user approves a task, the operator's UI must surface the expected duration: "this will run tonight" implies a longer window than "do this now." The user sets the window; the operator records it in the receipt.

For background jobs expected to run longer than 30 minutes, the agent MUST implement a heartbeat — a periodic signal to the user that the task is still running and still within declared scope. The operator's platform handles delivery. The user must be able to abort from the heartbeat notification without being present at a computer.

If the user revokes the consent receipt while the agent is mid-execution, the agent MUST call /agent/cancel to initiate a clean abort. Services exposing mutating APIs are REQUIRED to implement this endpoint. Partial state should be rolled back where the service supports transactions; where it does not, the audit log must record the partial execution clearly.

Consent Receipt — Extended for Offline{
  "intent":          "Process overnight batch report",
  "execution_window": {
    "earliest":  "2026-06-02T22:00:00Z",
    "latest":    "2026-06-03T06:00:00Z"
  },
  "heartbeat_interval": 1800,         // seconds between status pings
  "abort_on_revoke":    true           // always true; field is informational
}

12.3 Competing Scope Definitions

This follows the same model as OAuth: the authorization server defines scope semantics; clients request them. Operators who integrate with a service agree to those definitions. The spec additionally requires services to publish machine-readable scope schemas, eliminating the ambiguity that causes most real-world disputes:

Scope Schema (in discovery manifest){
  "id":                  "calendar.write",
  "description":        "Create and update calendar events",
  "allows":             ["events.create", "events.update"],
  "explicitly_excludes": ["events.delete", "calendar.delete"]
}

Any action not listed in allows is implicitly excluded. Any action in explicitly_excludes is a protocol violation regardless of what the operator's consent receipt declares.

12.4 Privacy of Intent Headers

The tension is real: free-text intent enables useful audit logs but leaks sensitive context to services. "Booking a meeting with my therapist" or "paying overdue rent" reveals information the service has no legitimate need to know.

The resolution separates the two audiences. The service receives only a structured type from a controlled vocabulary — enough to detect anomalous agent behaviour, not enough to infer personal context. The user-facing audit log displays the full free-text intent string, but this is fetched from the operator's own audit store, not from the service.

The controlled intent type vocabulary is defined per-scope in the discovery manifest. Services MAY reject requests with unrecognized intent types, providing a lightweight signal that an agent is operating outside expected patterns.

12.5 Standards Body Home

Standards bodies produce more rigorous, more interoperable, more durable specifications. They also move slowly and can water down core designs through forced consensus. OAuth 2.0 took years and still required a separate security BCP to be safely implementable.

The pragmatic path: ship as an open community spec, build real implementations, prove the design, then bring it to IETF OAuth WG or OpenID Foundation. This is how many durable web standards actually emerged — practitioners first, formalization second.

The exception is cross-operator delegation. Because it involves liability and accountability questions that transcend engineering, that chapter should go through a formal body from the start rather than arriving as a community proposal for ratification after the fact.

Test Vectors

Known-good inputs and expected outputs for implementers to verify their JWT handling, signature verification, and DPoP proof generation. These vectors are normative for conformance testing.

21.1 Operator Test Key Pair (ES256)

Test Private Key — JWK{
  "kty": "EC", "crv": "P-256", "kid": "aap-test-op-1", "use": "sig",
  "d":   "TEST_ONLY_9vApwBBB3iCMbDO0bRqFV7l4sLvBjPe8Z7k2Xl9m",
  "x":   "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
  "y":   "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
}

21.2 Valid Operator JWT — Expected to Pass

Input Claims{
  "iss": "test-operator.aap.dev",
  "aud": "https://test-service.aap.dev",
  "iat": 1748822400,
  "exp": 1748826000,
  "kid": "aap-test-op-1"
}
// Signed with test private key above using ES256
// Expected verification result: PASS
// Expected kid lookup: matches "aap-test-op-1" in test JWKS

21.3 Failure Vectors

19.4 Delegation Token JWT Claims

JSON Schema — JWT Payload{
  "$id":      "https://aap.dev/schemas/v2/delegation-token.json",
  "type":     "object",
  "required": ["iss", "sub", "delegated_to", "delegation_id", "scopes", "iat", "exp", "max_agent_ttl"],
  "properties": {
    "iss":           { "type": "string", "format": "uri" },          // service base URI — self-signed
    "sub":           { "type": "string" },                      // user identifier
    "delegated_to":  { "type": "string", "format": "hostname" },  // operator domain
    "delegation_id": { "type": "string", "pattern": "^del_[a-z0-9]{6,32}$" },
    "scopes":        { "type": "array", "items": { "type": "string" }, "minItems": 1 },
    "max_agent_ttl": { "type": "integer", "minimum": 300, "maximum": 86400 },
    "iat":           { "type": "integer" },
    "exp":           { "type": "integer" }
  },
  "additionalProperties": false
}

19.5 Service Account Delegation Token JWT Claims

JSON Schema — JWT Payload{
  "$id":      "https://aap.dev/schemas/v2/svc-delegation-token.json",
  "type":     "object",
  "required": ["iss", "sub", "delegated_to", "authorized_by", "org_id", "granted_scope", "iat", "exp"],
  "properties": {
    "iss":           { "type": "string", "format": "uri" },
    "sub":           { "type": "string", "pattern": "^svc_[a-z0-9_]{3,64}$" },  // service account id
    "delegated_to":  { "type": "string", "format": "hostname" },
    "authorized_by": { "type": "string", "format": "email" },
    "org_id":        { "type": "string" },
    "granted_scope": {
      "type": "object",
      "required": ["description", "scopes", "crosses_users"],
      "properties": {
        "description":  { "type": "string", "maxLength": 200 },
        "resources":    { "type": "array", "items": { "type": "string" } },
        "scopes":       { "type": "array", "items": { "type": "string" }, "minItems": 1 },
        "crosses_users": { "type": "boolean" }
      },
      "additionalProperties": false
    },
    "iat": { "type": "integer" },
    "exp": { "type": "integer" }
  },
  "additionalProperties": false
}

19.6 Auto-Revoke Policy

JSON Schema — effective_policy object{
  "$id":   "https://aap.dev/schemas/v2/auto-revoke-policy.json",
  "type":  "object",
  "properties": {
    "expires_at":         { "type": "string", "format": "date-time" },
    "inactivity_timeout": { "type": "integer", "minimum": 3600, /* seconds */ "description": "seconds" },
    "on_task_completion": { "type": "boolean" },
    "on_events":          {
      "type": "array",
      "items": { "enum": [
        "user.offboarded", "org.subscription_cancelled",
        "resource.deleted", "user.role_changed"
      ] }
    },
    "after_use":          {
      "type": "object",
      "properties": {
        "max_requests": { "type": "integer", "minimum": 1 },
        "max_writes":   { "type": "integer", "minimum": 1 }
      }
    }
  }
}

Terms & Definitions

Every functional, technical, and protocol-specific term used in this specification. Written for three audiences: implementers building systems, product owners designing features, and project managers overseeing integrations.

A

B

C

D

E

G

H

I

J

L

M

O

P

R

S

T

U

V

W