MCP security needs context-aware authorization, not static scopes

At a glance

What this is: Pomerium argues that MCP requires context-aware authorization because static scopes and traditional network controls cannot govern AI agents acting on real-time intent.

Why it matters: IAM, PAM, and NHI teams need policy decisions that evaluate who the agent acts for, what it is doing, and whether the request is appropriate right now.

Context

MCP is a protocol layer that lets AI agents use tools and data sources as part of a live workflow. The identity problem is that the agent can move from query to action in a single session, so access decisions must follow behaviour, not just login state.

Static scopes and VPN-style controls were built for access that can be predicted in advance. When an agent can read records, call APIs, and update systems from the same prompt, governance has to shift to per-action authorisation and continuous verification.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

Q: Why do static OAuth scopes fail for agentic workflows?

A: Static scopes fail because they assume the action set is known when access is granted. Agentic workflows change the decision context during execution, so the original scope often cannot express the task, target, or risk at the moment the action occurs.

Q: What are the signs that MCP authorisation is too coarse?

A: Warning signs include broad bearer tokens reaching internal services, the same scope covering many tools, approvals that never consider request context, and audit logs that show only login events instead of per-action decisions. If an authenticated agent can change behaviour without a fresh policy check, authorisation is too coarse.

Q: How do Zero Trust controls apply to MCP server security?

A: Zero Trust applies by forcing each tool call through policy, context, and revocation rather than trusting an established session. For MCP, that means per-request authorization, isolated execution, and continuous auditability so a compromised agent or server cannot keep acting unchecked.

Technical breakdown

Why static OAuth scopes fail for MCP agents

OAuth 2.1 can authenticate an agent or user session, but it does not express real-time intent. In MCP, that gap matters because the same bearer token can be used for benign retrieval or for a high-risk action triggered by prompt injection, confused deputy behaviour, or downstream tool chaining. Static scopes describe what access was granted at provisioning time, not whether the action is appropriate in the current context. That is why scope-based authorisation breaks down when the agent’s behaviour is dynamic and the risk changes per request.

Practical implication: Use request-time policy decisions for MCP access instead of relying on scopes as the final control.

How context-aware authorization changes the control point

Context-aware authorisation evaluates the actor, the target tool or system, the request path, time, device posture, and session attributes at the moment of action. That turns authorisation into a runtime control rather than a one-time entitlement. For MCP, this is the difference between permitting an authenticated session and approving a specific file access, API call, or system update. The protocol may carry the request, but the proxy or control layer must decide whether the action matches the expected behaviour for that identity and that moment.

Practical implication: Place a policy enforcement layer in front of MCP servers so every action is checked before execution.

Why prompt injection becomes an access-control problem

Prompt injection matters in MCP because it can alter what the agent does without changing who authenticated. The identity session remains valid, but the behaviour shifts inside that session, so the attack becomes an authorisation failure rather than an authentication failure. That is why the article treats the proxy as the enforcement boundary. If the control layer only trusts the token and not the action context, a compromised instruction can cause data retrieval, workflow execution, or configuration changes that were never intended by the operator.

Practical implication: Treat prompt injection as a policy-evasion risk and verify action context before allowing tool use.

Threat narrative

Attacker objective: The attacker wants to make an authenticated agent perform unauthorized actions that expose data or change systems without triggering an auth failure.

1. Entry occurs when an attacker injects a malicious instruction into an MCP session or when a broad bearer token is reused for agent activity.
2. Credential access is not the main issue here; the weakness is that the token authorises actions without checking the live request context.
3. Escalation happens when the agent is induced to call tools, query data, or modify systems beyond the operator's intent.
4. Impact is unauthorized data access, workflow abuse, or system changes carried out at machine speed before the session is corrected.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static scopes are a provisioning assumption, not an agent control. They assume access can be granted in advance and evaluated later, but MCP agents act at runtime with behaviour that can change inside a single session. That makes scope-based governance too coarse for the actual decision point. Practitioners need to treat each tool call as a new authorisation event.

Context-aware authorization is the right control plane for MCP. The primary issue is not whether the agent is logged in, but whether the specific action is appropriate for the current identity, system, time, and request path. That aligns better with Zero Trust Identity thinking than with perimeter logic. The implication is that MCP governance belongs at the action layer, not inside static identity assignment.

Intent-aware access: the missing control is not identity verification but request-time evaluation of why the action is being taken. This is the clearest concept in the article because it captures the gap between knowing who is connected and knowing whether the behaviour is acceptable. It also explains why prompt injection, confused deputy risks, and broad bearer tokens converge on the same governance failure. Practitioners should use this lens to redesign policy boundaries for agentic workflows.

Autonomous tool use collapses the old divide between authentication and authorisation. Once an agent can query, decide, and act in one chain, authentication no longer provides enough assurance about outcome. The field needs governance models that track behaviour, not just identity, because the risk is now expressed at action time. That shifts identity security from entitlement management to continuous control of delegated execution.

Observability becomes part of governance, not just detection. When every allow or deny decision is logged with context, security teams gain evidence for compliance, incident response, and policy tuning. The significance is broader than MCP: agentic systems force identity programmes to prove not only that access exists, but that each use of access was justified. Practitioners should build auditability into the control path, not bolt it on after the fact.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Intent-aware access: MCP exposes a wider identity problem than token handling. When an agent can query, call tools, and update systems in one flow, policy has to decide whether the live request is appropriate, not merely whether the session is authenticated.

A control model built for static scopes will keep missing the actual decision point. The practical shift is toward action-level enforcement, where the proxy evaluates context, logs the outcome, and blocks behaviour that does not fit the current request.

According to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone. That scale suggests MCP governance is already becoming a secrets and authorisation problem at the same time.

For practitioners

• Define per-action policy for MCP servers Evaluate each file access, API call, and system update against live context such as user role, request path, device posture, and time of day before the action is forwarded.
• Remove raw bearer tokens from the agent path Translate external identity into short-lived signed assertions at the proxy so MCP services never receive reusable OAuth tokens from the agent itself.
• Separate authentication from authorisation in design reviews Review MCP architectures to confirm that login success does not automatically permit tool use, data access, or workflow execution.
• Log allow and deny decisions with full context Capture who requested access, what was attempted, when it happened, and why it was allowed or blocked so policy decisions are auditable and reviewable.

Key takeaways

• MCP changes the identity problem because agent sessions can move from data retrieval to system action without a new human checkpoint.
• Static scopes and network perimeter controls are too blunt for requests whose risk depends on live context and current behaviour.
• The strongest control is per-action authorization backed by audit logging, so each agent decision is evaluated before it reaches the MCP server.

Key terms

• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.