Should production MCP agents use OAuth 2.1 or cloud credentials?

Production MCP agents should normally use OAuth 2.1 to reach a protected remote MCP server and workload identity to obtain short-lived credentials for cloud APIs. Those mechanisms protect different hops. Asking which one wins hides the boundary that needs protection.

I have seen teams put a developer's refresh token in a secret store, call it automation, and discover during an incident that nobody knows which agent used it. I have also seen teams replace a static cloud key with a one-hour token while leaving a permanent client secret beside it. The token got shorter; the attacker's path did not. A production design has to identify the principal, narrow what it can do, make every credential expire, preserve a fast way to cut access, and leave enough evidence to reconstruct one tool call.

For a remote HTTP MCP deployment, the clean default is two exchanges. The agent authenticates to the MCP authorization server and receives an access token whose audience is that MCP server. The workload then uses its platform identity to obtain credentials for the exact cloud account, role, service account, or managed identity needed by the downstream tool. If the agent and MCP server run in the same trusted process over stdio, the first exchange may disappear, but the cloud identity requirement does not.

Stop treating the two credentials as substitutes

OAuth 2.1 and short-lived cloud credentials answer separate questions. OAuth answers whether this client may call this protected resource on behalf of itself or a user. Cloud IAM answers whether this workload may perform a provider action against a named cloud resource. A bearer token for the MCP server should not double as a credential for object storage, a database, or a deployment API.

The current Model Context Protocol Authorization specification makes a protected HTTP MCP server an OAuth resource server. The client must send the resource parameter defined by RFC 8707 when it requests authorization and a token. The server must validate that the token was issued for its own audience, and it must reject expired or invalid tokens with HTTP 401. The same specification forbids accepting or forwarding tokens meant for some other service.

That last rule matters. Token passthrough feels efficient because the MCP server can hand an upstream bearer token to a downstream API. It destroys the boundary instead. The MCP security guidance calls out the resulting accountability gap: the MCP server may not distinguish clients, while the downstream log may record an identity that does not describe the component that actually forwarded the request. Audience validation, rate limits, and provider-specific policy can also be bypassed.

A sound request path looks like this:

1. The runtime proves its workload identity to an authorization or security token service.
2. It receives an MCP access token restricted to the MCP server and required scopes.
3. The MCP server authorizes the requested tool before invoking it.
4. The tool obtains a separate short-lived cloud credential for its downstream resource.
5. The MCP server records the decision and correlates it with the cloud provider's request record.

Do not let step four reuse the token from step two. If the downstream API accepts OAuth, the MCP server still needs a new token exchange with a downstream audience. Same token format does not mean same credential.

Which identity should an unattended agent carry?

An unattended agent should carry a non-human workload identity tied to its runtime and deployment, not a copied user session. The identity should be different for production and non-production, and different again when two agents have materially different duties. That separation gives you a principal you can disable without locking out a person or stopping unrelated jobs.

Use the cloud's native identity when the workload runs inside that cloud: an AWS IAM role for compute, a Google Cloud service account reached through Workload Identity Federation, or an Azure managed identity. For Kubernetes, use the provider integration that binds a service account to the cloud identity. For another cloud, a CI system, or an on-premises runner, federate the runtime's signed OIDC assertion or equivalent native credential into the target provider's security token service.

AWS explicitly recommends temporary credentials from IAM roles and federated principals instead of long-term IAM user access keys. Google Cloud calls Workload Identity Federation the preferred choice for external workloads and warns that service account keys require the operator to protect the private key. Microsoft says managed identities let an Azure resource obtain Microsoft Entra tokens without exposing owner-managed credentials. The names differ, but the operating model is the same: establish trust in the runtime, then mint a limited credential when code needs it.

A confidential OAuth client using client_credentials can represent the agent at the MCP boundary. That does not justify placing a permanent shared client secret in every replica. Prefer private_key_jwt, mutual TLS, or a federation path supported by the authorization server, with the private operation anchored in a managed key or runtime identity. If the authorization server only supports a client secret, keep one secret per workload and environment, limit who can read it, and treat its rotation as a separate obligation from access-token renewal.

Do not use a founder's, SRE's, or service owner's refresh token for a daemon. Refresh tokens represent an existing grant and are often long-lived enough to survive many access-token cycles. They also tangle the agent lifecycle with a human account, consent changes, employment changes, and interactive reauthorization. A production job needs an identity whose owner is the workload and whose removal procedure is documented.

Scopes do not replace cloud policy

OAuth scopes should describe the MCP capabilities the client may request, while cloud policy should restrict actions, resources, and conditions at the provider. A scope named deploy is not sufficient if it silently maps to administrator access across every account. A cloud role named MCPAgent is no better if every tool invocation receives it.

The MCP authorization specification recommends selecting the scopes from the server's WWW-Authenticate challenge and supports step-up authorization after an insufficient_scope response. That is useful for interactive clients. An unattended client should not automatically chase broader scopes until a request succeeds. It should have a declared ceiling, fail closed when a tool asks for more, and send the request to an approval path or a configuration change.

Design the scope-to-policy mapping from the tool inward. Start with the exact API operations that one tool performs, the resource identifiers it may touch, and any constraints on region, environment, tags, namespace, branch, or time. Then expose an MCP scope that selects that capability. Keep read and write operations separate where a meaningful read-only mode exists. Keep destructive operations out of a broad write scope when the provider can express them separately.

A practical policy record can be small enough for code review:

agent: release-notes-prod
mcp_resource: https://mcp.internal.example/releases
mcp_scopes:
  - releases:read
  - releases:draft
cloud_identity: releases-writer-prod
allowed_actions:
  - object.get
  - object.create
resource_prefix: releases-prod/drafts/
max_credential_ttl_seconds: 900
auto_scope_upgrade: false
human_approval:
  - object.delete
  - release.publish

This fragment creates two useful failure modes. A prompt injection that calls release.publish stops before the cloud request because the tool policy requires approval. A compromised agent that calls another storage prefix reaches the provider with a credential whose resource policy rejects it. If the provider cannot express the restriction, put it in a broker that issues narrower credentials or redesign the tool. An instruction inside a model prompt is not an authorization control.

Avoid one identity shared by all MCP tools. Shared identity makes policy changes risky because nobody knows which tool needs which permission, and its logs collapse many callers into one principal. If creating an identity per tool is too granular for your platform, group tools by permission set and blast radius, then record the tool name and policy version for every decision.

Short lifetime helps only when bootstrap is safe

A short-lived token limits how long a stolen token can be replayed, but it does not make the token narrow or prove who stole it. A fifteen-minute administrator token can do more damage than a one-hour token that can read one object prefix. Choose lifetime after scope and audience, not instead of them.

The more important question is what mints the next token. If an agent exchanges a long-term access key or static client secret for a short-lived token, an attacker who steals the bootstrap secret can mint tokens until you rotate or revoke that secret. The visible credential expires, while the durable credential remains available. Workload identity removes that stored bootstrap secret by asking the platform to attest which runtime is making the request.

Set the access-token lifetime around the operation and recovery path. Interactive MCP sessions can often tolerate a short token plus a refresh flow. Batch agents should request a credential shortly before a task, keep it in memory, and discard it after the task. A long deployment may need renewal, but the worker should renew through the same workload identity and re-evaluate policy. Do not write temporary credentials to a workspace, include them in model context, attach them to traces, or return them in tool results.

Cloud SDK default credential chains are helpful only when you control their order. In development, a chain may fall back to a developer login or a local credentials file. The same code in production should require the platform identity and fail if that identity is unavailable. Otherwise a mounted home directory, a permissive container image, or an old environment variable can silently change which principal the agent uses.

Token caching needs an owner and an upper bound. Cache by audience, scope, cloud role, and tenant rather than by the vague label cloud_token. Refresh before expiry with a small safety window, but do not create a background loop that renews unused credentials forever. Isolate caches between tenants and agents. A cache collision that returns a valid token for the wrong account is an authorization failure even if every cryptographic check passes.

Rotation and revocation solve different failures

Rotation replaces the credential used for future authentication. Revocation stops an existing grant, session, key, role assumption path, or policy binding. Teams often celebrate automatic rotation while lacking a tested way to cut an agent off during an incident.

OAuth 2.1 requires confidential clients to authenticate at the token endpoint and binds refresh tokens to the client. For public clients, the specification requires sender-constrained or one-time refresh tokens so reuse can be detected. That protects renewal, but it does not guarantee instant invalidation of every access token already issued. A self-contained access token may remain accepted until expiry unless the resource server checks revocation or the authorization system pushes another control.

Cloud temporary credentials have the same operational wrinkle. AWS notes that temporary credentials remain valid until they expire, although permissions are evaluated on each request. Changing the role policy or adding an explicit deny can stop subsequent requests without waiting for the session to end. In other systems, cached tokens or cached group claims can delay a permission change. Microsoft documents that managed identity token caching can make group or role membership changes take hours to appear, so direct assignments and a tested denial mechanism matter when response time is strict.

Write a revocation ladder before launch:

1. Disable the individual agent identity or its federation trust.
2. Deny the affected action or resource at the cloud policy layer.
3. Revoke its OAuth grant, refresh token family, or client credential.
4. Stop the workload and clear any external token cache.
5. Rotate a bootstrap secret only if one exists and may have leaked.

The order changes with the incident. A leaked access token calls for a fast provider deny and workload stop. A stolen client secret calls for client credential rotation and token revocation. A malicious prompt does not necessarily mean credentials leaked; suspend the tool, preserve the run evidence, and narrow the policy before restarting.

Test this ladder. Issue a credential in a staging account, begin harmless repeated reads, disable the identity, and measure when calls stop. Record which control ended access and which logs prove it. Your required maximum exposure window should come from that observed result, not from the token's advertised expires_in field alone.

Token exchange must preserve audience boundaries

Every issued token should name or imply one intended resource, and every resource should enforce that audience. The MCP client requests a token for the canonical MCP server URI. The MCP server validates that audience. When the server calls a cloud API, it obtains a credential for that provider and target, not a general token forwarded by the client.

RFC 8707 exists because a scope alone does not reliably identify where a token may be used. Two resource servers can recognize the same scope word and still represent completely different trust zones. The MCP specification therefore requires the resource parameter in authorization and token requests and tells servers to accept only tokens issued for their own resources. Treat that requirement as a minimum, then check issuer, signature or introspection result, expiry, not-before time, client identity, tenant, and authorized scope.

A gateway does not remove this responsibility. If one gateway fronts several MCP servers, decide whether the gateway is the sole resource server or whether it exchanges the external token for an internal token with a narrower audience. Do not let every backend accept the same edge token by convenience. That turns compromise of one route into access across the gateway.

Sender-constrained tokens can reduce replay when the stack supports them. Mutual TLS binds a token to a client certificate; DPoP binds it to a proof key. They are useful for a high-risk remote hop, but they do not repair excessive scope, shared identities, or missing audit context. They also add key custody and proxy compatibility work. Deploy them where replay risk justifies that work, and keep short lifetimes and audience checks.

Watch redirects and retries. An HTTP library must not forward the Authorization header to a different host after a redirect. An agent retry must not respond to 401 by obtaining a broader token without policy. A tool that follows a provider-supplied URL must use an allowlist and acquire credentials only after it resolves the final trusted audience.

Audit the chain, not only the final API call

A useful audit trail links the agent run, authorization decision, MCP tool call, token issuance, and cloud API request without recording a credential. Provider logs alone rarely explain why the model selected a tool or what policy approved it. Agent traces alone rarely prove which cloud principal changed the resource.

Assign a non-secret run ID when the agent accepts work. For every tool call, record the tool name, normalized arguments or a safe hash, caller identity, tenant, MCP token subject and audience, requested scope, policy version, approval identity when applicable, result class, and provider request ID. Record token expiry and a fingerprint of the token identifier if your issuer supplies one, but never the bearer value, refresh token, authorization header, assertion, or signed proof.

A minimal event should look predictable enough for a log query and an incident script:

{"event":"mcp_tool_authorization","run_id":"run_01J...","tool":"release.create_draft","caller_subject":"agent:release-notes-prod","mcp_audience":"https://mcp.internal.example/releases","scope":"releases:draft","policy_version":"git:8f31c2a","decision":"allow","cloud_principal":"releases-writer-prod","cloud_request_id":"req_7b...","credential_expires_at":"2026-07-27T14:15:00Z","token_fingerprint":"sha256:4ab..."}

Redact tool arguments by field, not by hopeful string matching. Prompts, file contents, SQL text, and API payloads can contain secrets that were already present in the source system. Store the smallest evidence needed to explain the decision. Put sensitive payload captures behind separate access controls and retention rules.

Google Cloud's Workload Identity Federation guidance gives a concrete example of why issuance logs matter. Data Access logs for its Security Token Service and IAM APIs record token exchange and service account impersonation, while later resource activity may show the impersonated service account. Google recommends a unique subject mapping and correlation with the external identity provider so an investigator can reconstruct who initiated the chain. Enable those logs explicitly; do not assume every data access event is on by default.

AWS CloudTrail records calls to AWS STS and later calls made with the assumed role. Requiring a meaningful role session name and SourceIdentity where supported helps retain the original actor across role assumption. Azure exposes managed identity sign-in logs, but shared user-assigned identities can still make several resources look like one caller. Choose system-assigned identities when attribution to one resource matters more than reuse.

Alerts should target impossible or dangerous behavior, not mere token issuance. Examples include an agent assuming a role outside its environment, a new audience, a denied destructive tool followed by direct cloud attempts, credential issuance after the workload was stopped, or one run touching unrelated tenants. Tie every alert to the revocation ladder and an owner who can act.

A production policy must survive failure tests

A production credential design is ready when you can demonstrate its failure behavior, not when the happy-path login works. Review a matrix that crosses identity, audience, scope, resource, lifetime, revocation, and evidence. Each row should contain a test someone can run after an authorization-server, SDK, proxy, or cloud-policy change.

Run at least these checks before release:

• Present an MCP token minted for another server and verify a 401 response.
• Request a tool outside the granted scope and verify 403 without automatic escalation.
• Call an allowed cloud action against a disallowed resource and verify provider denial.
• stop the workload identity, then measure how long existing and new credentials work.
• search by run ID and reconstruct the MCP decision plus the cloud request without viewing secrets.

The fourth check often exposes the gap between assumed revocation and actual caching. The fifth exposes identity collapse. If the investigator can find only a shared service account and a timestamp, the system has authentication logs, not attribution.

Review the credential path as part of every new tool, not as a platform decision made once. A read-only search tool, a deployment tool, and a billing export tool have different resources and consequences. Give each a declared policy, then reject registration if the policy requests wildcards without a written reason. Wildcards may be unavoidable for APIs that lack fine-grained controls, but that limitation should drive isolation, approvals, and monitoring.

Keep authorization outside the model. The model can propose a tool and arguments. Deterministic code validates schema, resolves tenant and resource, checks policy, obtains credentials, and performs the call. A human approval should authorize the exact normalized operation with an expiry, not place a vague approved=true flag in the conversation.

At oleg.is, I use the Team & AI Audit to trace these boundaries alongside agent permissions and operating cost, because a smaller AI-augmented team needs controls it can actually test and operate. The same review can be done internally: assign one owner to every identity, one policy repository to every permission set, and one incident procedure to every credential issuer.

Do not accept a design diagram as proof. Capture the 401, the 403, the provider denial, the revocation timing, and the correlated log query in CI or a scheduled security test. Credential systems drift when a provider changes an SDK default, a role gains a wildcard, or a proxy starts reusing headers.

When OAuth delegation is still the right choice

Use an authorization-code flow with PKCE when the agent acts on behalf of a present user and the downstream action should carry that user's consent or identity. The MCP specification requires MCP clients to use PKCE and verify that the authorization server advertises support. That flow fits an assistant reading a user's private workspace during an active session.

It fits unattended work only when the product deliberately supports offline delegation, the authorization server issues a refresh token for that purpose, and the organization accepts the user's lifecycle as part of the automation. Store the refresh token in a credential vault, bind or rotate it as the authorization server supports, narrow its grant, and handle revocation as a normal state. Never treat repeated reauthorization failures as a reason to fall back to a service owner's token.

Choose workload identity when the job belongs to the system: nightly indexing, deployment checks, queue processing, inventory scans, or an agent that serves many users under a service policy. Choose user delegation when the job belongs to a user and must stop when that user's grant stops. Some agents need both: workload identity to run, plus a separate delegated token for one user-owned data source. Keep the two principals visible in policy and logs.

Client credentials remain OAuth, but they represent the client rather than a user. They are a reasonable MCP boundary mechanism for a confidential daemon if client authentication is strong and the grant is narrow. They do not replace the downstream workload identity, and a static client secret still needs custody, rotation, and revocation.

What should you deploy for production MCP agents?

Deploy a layered credential chain: a runtime-bound workload identity, an audience-bound OAuth token for each protected MCP server, and a separate short-lived cloud credential for each downstream permission set. Remove any human refresh token, long-term cloud key, or cross-service bearer token from the normal path.

For an HTTP MCP server, enforce protected resource discovery, the resource parameter, issuer and audience validation, short access-token lifetimes, and exact 401 or 403 behavior. For a local stdio server, the MCP specification says to retrieve credentials from the environment instead of applying its HTTP authorization flow. In production, make that environment expose a platform credential endpoint or an injected one-time reference, not a permanent cloud key.

Set a policy ceiling for unattended scope changes. Separate identities by environment and permission class. Obtain credentials only when work begins, cache them by their full security context, and prevent tokens from entering prompts, traces, tool results, or disk. Correlate the run with token issuance and the provider request, then rehearse denial and revocation.

OAuth 2.1 gives the MCP hop a disciplined authorization protocol. Short-lived cloud credentials give the workload a limited provider identity. Workload identity removes the secret that would otherwise mint those credentials forever. Production needs all three ideas in the places they belong. If one token crosses every boundary, redesign the path before the agent receives a production tool.