Shortcuts like hardcoded secrets, long-lived tokens, and token passthrough turn temporary access into persistent delegated privilege. Once an AI agent can reuse those credentials, it may reach tools, APIs, or production actions that were never intended to stay available. The issue is not only exposure of a secret, but the expansion of the agent’s effective scope.
How insecure MCP OAuth shortcuts turn access into delegation
MCP is built to let an AI agent reach tools safely through OAuth-based authorization, but shortcuts break the boundary between a short-lived grant and durable privilege. Hardcoded secrets, copied tokens, and passthrough patterns make the agent act with credentials that outlive the task, so the access path becomes reusable instead of temporary. That changes the security model from mediated access to persistent delegation.
When the shortcut is a secret embedded in code, config, or context, the compromise point is no longer just the MCP client or server, but every place the credential can be replayed. That is why the control question is not simply “can the agent connect?” but “what exact scope, audience, and lifetime does the agent inherit, and can that be enforced per action?”
For a deeper view of why MCP authorization must preserve resource boundaries, see Model Context Protocol: Authorization specification. For the OAuth machinery behind these delegated flows, RFC 6749: The OAuth 2.0 Authorization Framework remains the base reference.
Why token passthrough amplifies the agent’s effective privilege
Token passthrough is risky because it lets the agent reuse a human or upstream token without re-evaluating whether the original authorization still fits the agent’s action. In practice, that can collapse user intent, task scope, and runtime authority into one bearer credential, which makes downstream tools treat the agent as if it had full standing permission. The result is privilege expansion by inheritance, not by explicit approval.
Long-lived tokens make the problem worse. Even if the initial use was legitimate, the credential can persist after the task, after the user session, or after the intended context has changed. If the token can call production APIs or administrative functions, an agent compromise, prompt abuse, or simple overreach can translate into real operational damage long after the original request ended.
That is why sender-constrained tokens and audience restriction matter. RFC 8707: Resource Indicators for OAuth 2.0 helps bind access to the intended resource, and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) reduces replay value if the token is stolen.
What makes MCP shortcuts especially dangerous in agentic systems
AI agents do not merely display data, they execute actions. If an MCP shortcut gives the agent broad or reusable authority, the agent can move from reading context to modifying systems, invoking tools, or triggering workflows the original user never consciously approved. That is why the risk is privilege, not just exposure: the agent’s effective scope grows beyond the intent of the original delegation.
In agentic workflows, this issue often shows up as confused deputy behaviour, where the agent becomes a powerful intermediary for actions it was never meant to own. The safest design treats the agent as a bounded subject with explicit per-action authorization, not as a convenient carrier for human credentials. Where delegation is required, token exchange or short-lived approval should preserve the difference between “on behalf of” and “as if it were the principal.”
For identity and delegation patterns that fit this model, AI Agent Authorisation Guide is the most direct internal reference. For broader identity and lifecycle context, Agentic AI Identity Guide explains how delegation, registration, and retirement should be handled, while MCP Security Guide covers the authorization model, token passthrough, and gateway patterns that prevent shortcut-driven privilege creep.
Risk and Threat Considerations
Insecure MCP OAuth shortcuts create a durable attack surface because one leaked or overbroad token can be replayed across tools, sessions, or production workflows. The practical risk is not only secret theft, but silent privilege expansion: an attacker, or an unintended agent action, can use the inherited credential to reach resources that were supposed to remain tightly bounded.
Failure mechanism: Hardcoded secrets, long-lived bearer tokens, and passthrough flows remove the checks that would normally re-evaluate scope, audience, and lifetime before each action. Once the credential is reusable outside the original context, the agent can keep acting with stale authority.
Impact: Unauthorized API calls, tool misuse, data exposure, and production changes become more likely, and revocation becomes harder because the original delegation path was never designed to be temporary or narrow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded secrets and token reuse are central to the privilege risk. |
| NHI-04 — Insecure Authentication | MCP OAuth shortcuts weaken authentication and token validation for agent access. | |
| NHI-05 — Overprivileged NHI | Passthrough and long-lived tokens expand the agent’s effective scope beyond intent. | |
| Recommendation — Eliminate exposed secrets and replace reusable credentials with short-lived, bounded access. Use strong OAuth client authentication and bound tokens for each agent connection. Restrict agent credentials to least privilege and task-scoped access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The issue is agent authority expanding through inherited credentials and delegation. |
| ASI02 — Tool Misuse | Overbroad MCP access lets agents invoke tools and actions beyond intended scope. | |
| Recommendation — Enforce per-action authorization and remove standing privilege from agents. Gate high-impact tool calls behind explicit policy and approval. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifetime, storage, rotation, and revocation directly shape this risk. |
| AC-6 — Least Privilege | The core problem is excessive authority inherited by the agent. | |
| IA-9 — Service Identification and Authentication | MCP agents and tools authenticate as non-human actors and need bounded trust. | |
| Recommendation — Manage agent credentials with short lifetimes, rotation, and revocation controls. Limit each agent to the minimum permissions needed for the task. Authenticate agent-to-service calls with constrained non-human identities. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Verify each request and avoid standing trust for agent credentials. |
| Recommendation — Treat each agent request as untrusted until policy verifies it. | ||
Practitioner Guidance
What to verify: Confirm that the MCP flow uses short-lived, audience-bound credentials and that the agent never stores reusable human secrets in code, prompts, or local configuration. If the token can still work after the task should have ended, the design is already too permissive.
Decision rule: If the agent can call production tools or sensitive APIs, treat passthrough as a last resort and require per-action authorization or a constrained delegation mechanism instead. If you cannot explain who can revoke the access and when it expires, the privilege is effectively standing.
What practitioners underestimate: The biggest failure is often not obvious compromise, but scope drift. A credential that was “only for setup” or “only for this workflow” becomes a standing capability once it is copied, reused, or inherited by the agent.
Practitioner takeaway: The control objective is not to eliminate agent access, it is to ensure every agent action is bounded, attributable, and expiring faster than the opportunity to abuse it.