Agent Identity: API Keys and Delegated Tokens
Separate user login, server access and downstream credentials, then assess scope, lifetime, revocation and what an incident reviewer could reconstruct.
On this page
- Direct answer: map the identity at every hop
- Three distinct identity relationships
- What the documents actually require
- Hypothetical incident: shared key versus per-user delegation
- What should a reviewer see six months later?
- Build one credential record per destination
- Limits and maintenance
- Sources
- Frequently asked questions
Covers 8 topics
- User login, client-to-server identity and downstream authorization
- Shared API keys versus per-user delegated credentials
- Audience validation, token separation and confused-deputy risks
- Credential storage, access-token expiry and renewable grants
- Revocation boundaries and integration disruption
- Agent attribution versus human-requester attribution
- Six-month incident-review evidence
- Documentation limits and monthly maintenance
Direct answer: map the identity at every hop
Interpretation: do not treat “the agent is authenticated” as a complete access model. For each destination, identify the principal whose authority is being used, the credential presented, and the human request—if any—that the operation is meant to serve. Evaluate identity, scope, lifetime, revocation and logging separately rather than choosing on the label “API key” or “OAuth.”
The MCP authorization specification describes an MCP client making protected requests on behalf of a resource owner, an MCP server acting as a resource server, and an authorization server issuing access tokens for that MCP server. MCP authorization, 2025-06-18
Interpretation: a shared, broad, long-lived credential is a poor fit when your requirements include attributing each operation to a requester and withdrawing one integration’s access independently. A per-user delegated arrangement is preferable for those requirements only if its actual scopes, renewal rules, revocation boundaries and logs support them. The hypothetical comparison below makes those assumptions explicit.
Source check: 11 September 2026, using the sources linked in this guide. This explainer uses the 2025-06-18 authorization specification, the separately dated 2025-11-25 security guidance, and Claude Code authentication documentation retrieved on that date; it does not present them as one specification revision. We did not exercise account-level authentication, credential storage, revocation or logging.
Three distinct identity relationships
| Relationship | Question to record | Evidence to request |
|---|---|---|
| User to agent application | Who signed in, and which account or organization does that login establish? | Login method, account identifier, session ownership and the record linking a request to that session. |
| Agent’s client to server | Which principal and client does this server recognize, and for which resource was the credential issued? | Credential source, issuer, intended audience, granted permissions and server-side validation evidence. |
| Server to downstream API or SaaS account | Does the destination see a delegated user, a dedicated service identity or a shared account? | Downstream credential owner, authorization grant, storage location, revocation procedure and a representative audit event. |
Use these as separate rows even when one organization operates every component. This is an editorial review model, not a claim that every agent implements the same login flow.
For an MCP server calling an upstream API, the authorization specification describes a separate access token issued by the upstream authorization server and prohibits forwarding the token received from the MCP client. Access Token Privilege Restriction
Interpretation: signing in to the agent application is not your evidence of downstream authorization; inspect the third row independently. Likewise, do not use the presence of a human account in one log as evidence that every downstream operation was requested by that person.
Where the confused-deputy problem enters
The authorization specification warns that accepting tokens for the wrong audience and forwarding them unchanged can cause a confused-deputy problem, with a downstream API incorrectly trusting their source or prior validation. Access Token Privilege Restriction
Interpretation: the dangerous collapse is treating authority established for one relationship as sufficient authority for another. A logged-in user, an authorized MCP client and a server’s downstream grant must not become interchangeable evidence of permission.
For MCP proxies using static client IDs, the authorization specification requires user consent for each dynamically registered client before forwarding to third-party authorization servers. Confused Deputy Problem
The security guide’s consent-bypass scenario depends on a combination of a static proxy client ID, dynamic MCP client registration, a third-party consent cookie and missing proper per-client consent. Confused Deputy Problem
Do not equate a static OAuth client identifier with a shared API secret, or diagnose this attack merely because an integration uses a long-lived key. Review the particular identity and consent relationships instead.
What the documents actually require
The 2025-06-18 specification makes authorization optional, says HTTP implementations supporting it should conform to this authorization specification, and says STDIO implementations should instead retrieve credentials from the environment. Protocol Requirements
Apply the following requirements within that stated scope—not as a universal standard for every agent or SaaS API.
- The MCP authorization specification requires clients to include the resource parameter in both authorization and token requests, identifying the intended MCP server. Resource Parameter Implementation
- The MCP authorization specification requires servers to validate that access tokens were issued specifically for them as the intended audience. Token Handling
- The MCP authorization specification requires the Authorization request header on every client-to-server HTTP request and prohibits access tokens in URI query strings. Access Token Usage
- The MCP authorization specification requires secure token storage, recommends short-lived access tokens, and requires refresh-token rotation for public clients. Token Theft
- The MCP security guide says servers implementing authorization must verify all inbound requests and must not use sessions for authentication. Session Hijacking
A documented requirement is not evidence that a particular implementation honours it. Request implementation-specific evidence; classify an unanswered question as unknown, not as proof of a missing control.
Delegated does not mean short-lived, narrow or theft-proof
The MCP authorization specification warns that attackers obtaining tokens from client storage or server caches or logs can make requests that appear legitimate to resource servers. Token Theft
The MCP security guide identifies unrelated access through stolen broad tokens, disruption from revoking max-privilege tokens, and obscured user intent from omnibus scopes as scope-design risks. Scope Minimization
Claude Code documentation describes a one-year OAuth token generated with claude setup-token for environments without interactive browser login. Generate a long-lived token
Interpretation: “OAuth” alone is not an acceptable answer to your lifetime question. Record the access-token expiry, refresh credential or equivalent renewal mechanism, and the maximum duration of the underlying grant. Do not count a token refresh as a fresh human approval without evidence of that approval.
Hypothetical incident: shared key versus per-user delegation
This is an explicitly hypothetical design comparison, not a report about any product. Assume an agent reaches an internal ticket API through an MCP server. In both arrangements, the human signs in to the agent application and the MCP client uses a separate credential intended for the MCP server. Only the server-to-ticket-API arrangement changes.
Assume an unauthorized bulk ticket export is discovered six months after it happened. The following storage, expiry, revocation and logging behaviours are stipulated for the example; none is a documented feature claim.
| Property | Arrangement A: shared long-lived key | Arrangement B: per-user delegated token |
|---|---|---|
| Identity and storage | The server reads a shared integration key from a secret store. Two unrelated automations use the same key. The ticket API sees one integration account. | The server obtains a downstream token under a user-specific grant for this integration. It stores access and refresh credentials in its protected credential store. The ticket API records the user subject and integration client. |
| Scope and lifetime | The key permits reading, exporting and editing all tickets, with no automatic expiry. | The access token permits reading tickets in one queue and expires after 15 minutes. The grant remains renewable until revoked; expiry alone does not end the integration’s access. |
| Revocation | Revoking the shared key stops all three consumers until they receive replacement credentials. | For this example, the API supports revoking this user’s integration grant and rejecting its outstanding access tokens without affecting other users or integrations. |
| Records retained for six months | The API retains integration account, key identifier, time, operation and target. It has no requester or agent-run identifier, and there is no retained correlation record elsewhere. | The API retains user subject, integration client, operation, target and request ID. Protected application records link that request ID to the initiating session, agent run and approved task. |
| What the reviewer can reconstruct | The reviewer can identify the shared credential used and affected tickets, but cannot distinguish the agent from the two other consumers using these records alone. | The reviewer can link the export to a user grant, integration and recorded agent run. That is evidence of the recorded authorization path, not proof that the human intended every exported ticket. |
Under these assumptions, Arrangement A trades simple credential reuse for a shared revocation boundary and an attribution gap. Arrangement B offers a narrower revocation target and more reconstructable records because we explicitly required those properties—not merely because it uses a delegated token.
Neither hypothetical arrangement prevents a compromised runtime from using its currently available authority. Neither turns valid credentials into proof that an operation was appropriate. In Arrangement B, an export within the granted queue still needs separate task and approval review; a stolen renewable credential also defeats any analysis that considers only the 15-minute access-token lifetime.
Decision: prefer B for this scenario only after confirming its stipulated properties. If the downstream API actually logs only a user subject, or revocation only prevents future refreshes, rewrite the comparison to reflect that limitation rather than carrying forward the stronger conclusion.
What should a reviewer see six months later?
The MCP security guide warns that token passthrough can prevent an MCP server from distinguishing clients and can make downstream logs show a different source identity from the forwarding MCP server. Accountability and Audit Trail Issues
Editorial recommendation: require both attribution dimensions. “Agent worker 7 performed this operation” answers a different question from “this operation used user account 42’s authority.” Ask for a retained link between them and the initiating request; do not substitute one for the other.
Request a redacted sample event and its correlation records containing, where supported:
- Downstream principal and tenant; client or integration identifier; agent run and server identity.
- Initiating human or scheduled-job owner, session identifier and relevant approval record.
- Operation, affected resource, result, timestamp and cross-system request identifier.
- Granted scopes and a non-secret credential or grant reference sufficient to locate issuance, renewal and revocation records.
Specify your six-month retention requirement for every linked record, including the identity mapping and approval record. Keep raw keys and tokens out of this evidence worksheet. Treat missing correlation as an explicit attribution limit, not permission to infer a requester from an account name.
Build one credential record per destination
- Name the destination and hop. Separate model-provider authentication, MCP access and downstream API access. Mark whether the principal is a person, dedicated workload or shared account.
- Record the active credential source and storage. Include secret-store reference or file location, runtime readers, deployment copies, fallback paths and the owner responsible for rotation. Record references, not secret values.
- Record actual granted authority. Capture scopes, role and resource restrictions, intended audience and the task that justifies each permission. Request a denied-operation check in an authorized test environment rather than relying only on a scope label.
- Record the full lifetime. Include access expiry, renewal credentials, grant expiry, renewal failure behaviour and the person or workload that can renew access.
- Define the revocation unit. Ask whether revoking this credential or grant affects one run, one user, one integration or other consumers. Request evidence of when already-issued credentials stop working and whether cached or replacement credentials restore access.
- Inspect the audit result. Request a representative event linked through all three identity relationships and confirm that the required records will still be available six months later.
- Make an explicit decision. Approve only against your stated requirements; restrict scope or sharing where evidence is insufficient; defer access where identity ownership or revocation impact remains unresolved. Assign an owner and review date to each unknown.
A vendor-documentation example: storage and renewal are separate questions
Anthropic documents Linux credential storage at ~/.claude/.credentials.json with file mode 0600. Credential management
Anthropic documents that CLAUDE_CONFIG_DIR relocates the .credentials.json file and also determines the associated macOS Keychain entry. Credential management
For Claude Code’s Console profile login, Anthropic documents automatic refresh and failed requests with Anthropic profile login expired when refresh fails, until the user signs in again. Sign in without an API key
Use those statements as prompts to inspect the actual credential route and operating environment, not as evidence about an unrelated downstream SaaS credential. No storage location, expiry or revocation behaviour for your internal API is established by these vendor statements.
Limits and maintenance
This is sourced education and an editorial decision framework, not a working configuration or an implementation certification. The example’s selective revocation, token lifetime, audit fields and retention are assumptions to validate in your systems. This article names no product as vulnerable and does not infer missing controls from documentation silence.
Review monthly; next scheduled review: 11 October 2026. A relevant MCP specification revision requires correcting this explainer rather than merely updating the source-check date. Revisit the affected credential records when authentication routes, storage, scopes, renewal, revocation or logging change.
Sources
- MCP Authorization specification — 2025-06-18: roles, transport scope, audience separation, token handling and confused-deputy framing. modelcontextprotocol.io
- Claude Code authentication documentation: product-specific storage, profile renewal and long-lived OAuth token documentation. docs.anthropic.com
- MCP Security Best Practices — 2025-11-25: proxy consent, passthrough audit risks, session authentication and scope minimization. modelcontextprotocol.io
Frequently asked questions
Should an unattended agent use a human’s delegated grant?
What if the API cannot provide a per-user token?
The digestFree
Which agents actually ship.
New agents and articles, by email, at most once a week.
Last issue · 13 October 2026Devin vs Claude Code: Which Should You Pick?
One-click unsubscribe