MCP security needs context-aware authorization, not static scopes

At a glance

What this is: This is an analysis of why Model Context Protocol security depends on real-time, context-aware authorization for AI agents rather than static identity checks.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that evaluate agent action, context, and intent at runtime, not just issue a token and hope policy holds.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Pomerium's analysis of secure access for Model Context Protocol

Context

MCP security is the problem of governing what an AI agent is allowed to do after identity has already been established. The article argues that static scopes and bearer-token models do not answer the harder question: whether the action is appropriate in the moment it is taken, especially when the agent can query databases, trigger workflows, and modify systems across a live session.

For IAM and NHI programmes, the practical issue is familiar even if the actor is newer. Long-lived permissions, broad tokens, and unclear authorization boundaries create the same governance drift that has historically affected service accounts, but MCP adds runtime intent and tool chaining to the problem. The result is a control model that has to inspect behaviour, not just authenticate a principal.

Key questions

Q: What breaks when AI agents rely on static OAuth scopes for MCP access?

A: Static OAuth scopes break because they describe delegated permission at the moment of issuance, not the live intent behind each agent action. In MCP, the agent can chain tool calls, change context, and trigger downstream effects that were never visible when the scope was granted. Security teams need per-action authorization, not just valid authentication.

Q: Why do AI agents make Zero Trust more important for identity governance?

A: AI agents make Zero Trust more important because the trust boundary shifts from login to each action the agent performs. An authenticated agent can still become unsafe if prompt injection, confused deputy behaviour, or scope drift changes what it is effectively doing. Zero Trust is the only model in this article that keeps evaluating behaviour as context changes.

Q: How can security teams know whether MCP authorization is actually working?

A: They should look for evidence that each tool call is being independently judged and that allow or deny decisions are logged with context. If the only control is token acceptance, authorization is not really working. A functioning model produces auditable decisions tied to user identity, request path, and action type.

Q: Who is accountable when an AI agent with valid access performs an unauthorized action?

A: Accountability sits with the organisation that defined the access boundary, because a valid token does not equal a valid intent decision. In practice, IAM, platform, and security owners need a shared policy model for MCP so that responsibility is not lost between the model, the proxy, and the backend service.

Technical breakdown

Why static OAuth scopes fail for MCP agents

OAuth 2.1 proves who received delegated access, but it does not evaluate why a specific action is happening right now. In MCP environments, an agent may be authenticated once and then execute a chain of tool calls that were not fully knowable at issuance time. That means the original permission grant can no longer describe the real risk of the session. Static scopes also struggle with prompt injection and confused deputy patterns, because the token remains valid even when the instruction context has changed. The security boundary has moved from login to action, and OAuth alone does not follow it.

Practical implication: treat OAuth as identity plumbing, not as the policy decision point for MCP tool use.

Per-action authorization and intent-aware control in MCP

Per-action authorization checks each request against user identity, request context, tool target, and the action itself. In MCP, this is the difference between a broad session token and a decision engine that asks whether a database query, file read, or system update is acceptable in this moment. Intent-aware controls matter because AI agents can combine small allowed actions into a larger unintended outcome. This is especially important where agents operate on behalf of users but without human review between steps. The control model has to evaluate the request path, session attributes, and role context before each operation.

Practical implication: place a policy layer in front of MCP servers that can approve or deny each discrete action.

Zero Trust for model context protocol traffic

Zero Trust for MCP means no implicit trust for an authenticated agent, a trusted network, or a previously approved session. Each interaction must be re-evaluated because the agent’s behaviour can change as context changes. In practice, that leads to identity-aware proxies, short-lived assertions, logging of allow and deny decisions, and policy enforcement at the application layer rather than in the model or the backend service. The article’s deeper point is that MCP introduces machine-speed action into a control model built for slower, human-paced request cycles. That mismatch is where risk accumulates.

Practical implication: enforce MCP access through a Zero Trust proxy that logs and conditions every tool request.

Threat narrative

Attacker objective: The objective is to hijack an agent session so legitimate access is turned into unauthorized data access or system change at scale.

1. Entry occurs when an AI agent receives legitimate access through an OAuth token or similar delegated credential and begins interacting with MCP tools.
2. Escalation happens when prompt injection or confused deputy behaviour turns an approved session into unauthorized tool use, data retrieval, or system modification.
3. Impact follows when one compromised agent can exfiltrate sensitive data, trigger workflows, or alter infrastructure at machine speed before a human can intervene.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static scopes are the wrong governance primitive for MCP. Static authorization was designed for request paths where the actor, tool, and intent are stable enough to evaluate at grant time. That assumption fails when an agent can chain actions, select tools dynamically, and change the effective risk of the session after authorization. The implication is that MCP governance cannot be reduced to token issuance or coarse scope design.

Model context protocol exposes an identity blast radius problem, not just an access problem. One prompt can cascade into database access, API calls, and configuration changes across several systems. That means the security issue is not a single permission but the breadth of what one authenticated agent can reach once runtime decisions begin. Practitioners should read this as a blast-radius control problem, not an authentication problem.

Context-aware authorization is becoming the baseline control for agentic access. The article makes clear that the new perimeter is intent, not network location or bearer-token possession. That is why NHI governance, Zero Trust, and application-layer enforcement are converging around the same operational requirement: every action must be judged in context. The practitioners who keep treating agent access as a login problem will miss the actual risk window.

AI agents should be governed as non-human identities with behavioural variance. MCP does not make the identity problem disappear, it makes the actor more dynamic. The control model must therefore assume that the same credential can produce different risk outcomes across time, tool choice, and session context. The implication is that identity governance now has to account for runtime behaviour, not only provisioning state.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 52 NHI Breaches Analysis shows how exposed credentials and over-permissioned identities repeatedly become breach entry points.

What this signals

Identity blast radius: MCP adoption is turning access scope into a runtime governance problem, which means teams will need policy layers that evaluate action, context, and intent before a tool call executes. That shift aligns closely with Zero Trust thinking and with the OWASP Non-Human Identity Top 10, which treats non-human access as a first-class control surface.

The operating signal to watch is whether your programme can still explain why an agent was allowed to act after the fact. If you cannot produce a contextual audit trail for a tool call, the control is incomplete even if authentication succeeded. For teams mapping this to standards, the relevant baseline is Zero Trust architecture guidance, not a static auth checklist.

As more agentic workloads are introduced, the old assumption that a valid credential is enough will keep failing in practice. NHI governance has to absorb runtime decision-making, and that means access reviews, approvals, and telemetry need to move closer to the point of action. The teams that adapt first will treat MCP as an identity problem with behavioural consequences, not as a new integration layer.

For practitioners

• Move MCP enforcement to the application layer Place an identity-aware proxy or gateway in front of MCP servers so each tool call is authorized against live context instead of relying on bearer-token validity alone.
• Constrain tool permissions by action and context Define policies that distinguish between read, query, update, and administrative actions, then require user role, request origin, and session attributes before allowing each one.
• Log allow and deny decisions with full context Capture who requested access, what tool was attempted, when it happened, and why it was allowed or blocked so investigations can reconstruct agent behaviour.
• Shorten trust windows for delegated credentials Use short-lived signed assertions for agent requests and remove raw OAuth tokens from backend services so a compromised session has less time and less reach.

Key takeaways

• MCP security is fundamentally an authorization problem, because agents can act on valid access in ways that exceed the original request context.
• Static scopes and bearer tokens do not capture intent, which leaves prompt injection and confused deputy patterns outside traditional IAM logic.
• Teams need action-level policy enforcement, auditable decisions, and shorter trust windows if they want agentic access to remain governable.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools, data sources, and services through a standard interface. In security terms, it shifts the control problem from model output to action authorization, because the agent can now trigger real operations instead of only generating text.
• Per-action authorization: A control model that evaluates each request as it happens rather than trusting a session after login. For agentic systems, it matters because the same authenticated identity can produce different risk outcomes depending on context, target system, and current instructions.
• Identity-aware proxy: A policy enforcement point that sits between an identity and the target service, applying authentication, authorization, and logging before traffic reaches the backend. In MCP environments, it helps ensure the tool call is judged in context instead of being accepted on token validity alone.
• Confused deputy: A failure mode where a trusted intermediary is tricked into using its authority on behalf of the wrong intent. For MCP and AI agents, the risk is that a valid session can be redirected into an action the original user did not actually authorize.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM strategy, it is worth exploring.

This post draws on content published by Pomerium: Secure Access for Model Context Protocol (MCP). Read the original.