Why do OAuth flows not fully govern agent behaviour in MCP systems?

Why OAuth is only one layer of control in MCP

OAuth answers a narrow question: who can get a token, for what scope, and against which resource server. In MCP, that is necessary but incomplete. The agent still needs policy that understands the tool, the context, the data being requested, and whether the next action is safe after the token is already valid.

That gap matters because the token does not describe the full business meaning of the action. A read-only token, a delegated token, or a valid client session can still lead to unsafe tool invocation if the runtime decision is not checked at the moment of use.

What OAuth does not encode about agent behaviour

OAuth is good at delegating access, not at governing intent. It can authorize a client to call a server, but it does not tell you whether the agent should continue, whether a tool call is consistent with the user’s current request, or whether the context has shifted since the token was issued.

That is why MCP systems need more than static scopes. The missing layer includes action sensitivity, step-by-step approval, session boundaries, tool-specific constraints, and safeguards against an agent reusing a legitimate token in a way the user did not mean.

In practice, the control problem is closer to runtime authorization than simple login. If the action is reversible, low impact, and tightly bounded, OAuth may be enough as one input. If the action can change data, move money, expose records, or chain into more powerful tools, the system needs a separate policy decision at execution time.

Why MCP needs runtime policy and contextual enforcement

MCP introduces an execution environment where the agent may keep acting after the initial authentication step. That creates a different risk model from a normal web login flow, because the security question is no longer only “is this client authenticated?” but also “is this exact action still allowed right now, in this context?”

Runtime policy lets the system evaluate the current user request, the active tool, the data classification, and any step-up condition before every meaningful action. It also helps prevent a token from becoming a blanket permission slip across tasks, servers, or conversations.

This is where the model needs to distinguish delegated access from delegated judgement. OAuth can delegate access rights, but it cannot on its own decide whether the agent is overreaching, whether a tool invocation crosses a trust boundary, or whether the action should be paused for confirmation. For that reason, MCP authorization guidance must sit alongside OAuth, not inside it. See the Model Context Protocol: Authorization specification for the transport and token model, and compare it with the broader OAuth model in RFC 6749: The OAuth 2.0 Authorization Framework and RFC 9700: Best Current Practice for OAuth 2.0 Security.

What happens when OAuth is treated as enough

The common failure is scope inflation by context drift. A token obtained for one task is later reused while the agent’s objective, tool chain, or data sensitivity has changed. In that situation, the token remains valid even though the original human intent is no longer a good proxy for the action being taken.

Another failure mode is confused-deputy behaviour. The agent may appear to be acting for the user, but it can also be shaped by prompts, tool output, or prior context into making a call that is technically authorized and practically unsafe. OAuth does not detect that mismatch.

In agentic systems, this is especially important because runtime actions can be chained. One permitted tool call can reveal data or create state that makes the next call far more powerful than the first. If policy is only checked at token issuance, the later steps are effectively ungated.

Risk and Threat Considerations

When OAuth is treated as the full control plane, the main risk is unauthorized or over-broad action under a valid token. That can lead to unintended data access, tool chaining, or persistent misuse even when the initial consent event looked legitimate.

Failure mechanism: The attacker, or the agent acting on unsafe context, uses a valid delegated token after the original approval moment, while the system fails to re-evaluate action risk at runtime.

Impact: Sensitive tools can be invoked outside the user’s actual intent, creating data exposure, privilege misuse, or downstream business impact that the OAuth grant itself did not prevent.

Practitioner Guidance

What to verify: Check whether the system makes an allow or deny decision at the moment of tool execution, not only at login or consent time. If the answer is “no,” OAuth is being used as an identity gate, not as a behaviour control.

What good looks like: The agent’s access is bounded by action-level policy, short-lived or scoped credentials, and explicit step-up checks for sensitive operations. The runtime decision should be visible, testable, and tied to the specific tool call.

Decision rule: If the action can change state, expose data, or trigger another privileged step, require contextual authorization in addition to OAuth. Treat OAuth as the delegation mechanism, not the final safety decision.

Practitioner takeaway: In MCP, OAuth establishes who may start the conversation; runtime policy determines whether the next action should still be allowed.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• Why is identity such a critical factor in securing AI agent systems?
• When is it appropriate to implement MCP in the context of AI systems?
• How should security teams govern AI agents that use OAuth access?