MCP security is an authorization problem, not an authentication one

At a glance

What this is: This article argues that MCP security failures stem from authorization gaps, not from authentication mechanics, because the protocol standardises connection plumbing while leaving permission decisions to implementers.

Why it matters: IAM and NHI teams need to treat MCP as a permissions-design problem, because tool access, context-window exposure, and execution-time checks determine whether AI systems stay within safe bounds.

Context

MCP is a protocol for connecting AI agents to tools, data sources, and APIs. In identity terms, that makes it a governance problem before it becomes a security product problem, because the real question is not whether a connection works but what the connected identity should be allowed to do.

Authzed's analysis is that authentication mechanics can prove who or what is connecting, but they do not answer the authorization question that determines whether a tool call, data read, or context injection is permitted. That gap becomes material when AI systems interact with user-specific data and external content at runtime.

The article's central point is that MCP implementers, not the protocol itself, own the permissioning model. For practitioners, that means the security burden sits in the design of scopes, enforcement points, isolation boundaries, and execution-time checks rather than in login flow alone.

Key questions

Q: What breaks when MCP authorization is left to individual users?

A: You get fragmented trust, inconsistent policy, and no reliable enterprise audit trail. Individual consent creates access sprawl that is hard to distinguish from sanctioned access, and revocation becomes partial or delayed because no central authority owns the full path from identity to tool access.

Q: Why do AI tool chains increase data-exfiltration risk in MCP environments?

A: Because MCP can combine private data access, untrusted content ingestion, and external communication inside one workflow. That trio creates the conditions for prompt injection or misuse to move information out of the system. The risk is architectural, not just malicious, because each tool may look safe until it is composed with the others.

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

A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.

Q: What is the difference between MCP authentication and authorization?

A: Authentication proves the agent or client is allowed to connect, while authorization determines which tools, data sets, and actions it can actually use. In MCP environments, both matter, because a correctly authenticated agent can still be over-privileged if its policy scope is too broad.

Technical breakdown

Why MCP authentication does not solve access control

MCP inherits OAuth-style authentication patterns, including token validation, scope handling, and discovery metadata, but those controls only establish identity and token validity. Authentication says who is presenting the request. Authorization decides what that subject may do with a specific tool, resource, or dataset. In MCP, the spec intentionally stops at the point where implementers must define scope meaning, access boundaries, and enforcement logic. That division matters because a valid token can still be paired with excessive capability. In practice, the security failure is not broken identity proofing. It is a permissions model that does not map cleanly to the actions an AI system can take.

Practical implication: Treat MCP rollout as an authorization design exercise, not an authentication integration exercise.

The lethal trifecta in MCP tool chains

The article points to a structural risk in AI systems: private data, untrusted content, and external communication can combine into a data exfiltration path. This is often called the lethal trifecta. MCP makes it easy to assemble that combination by connecting document stores, email tools, browsers, and other services into one agent workflow. Once untrusted content reaches the model context window, the model can be induced to process it alongside sensitive data and then send results outward through an enabled tool. The control issue is not only what the agent can see, but what enters the context window and which outputs are available to it.

Practical implication: Restrict tool combinations that create exfiltration-ready context, not just individual tool permissions.

Why deterministic authorization has to sit at execution time

The article rejects the idea that AI-based policy checks can replace access control. Probabilistic detection can help flag suspicious activity, but authorization decisions must be deterministic. That means a request is either allowed or denied at the moment the tool call happens. This is especially important because AI usage changes quickly, and permissions defined once at session start can become stale before the workflow ends. MCP environments therefore need authorization infrastructure that can evaluate a request at runtime, with current context, rather than relying only on preapproved sessions or broad role assignment. Otherwise the access model drifts away from actual behaviour.

Practical implication: Place policy enforcement at the moment of tool execution, not only at onboarding or session creation.

Threat narrative

Attacker objective: The attacker wants to leverage trusted MCP-connected workflows to extract sensitive data or trigger unauthorized actions without needing malware or stolen credentials.

1. Entry occurs when an AI agent connects through MCP to a tool, document source, or API with scopes broader than the task requires.
2. Credential and scope abuse follow when the agent is allowed to act on a valid token without tight, execution-time permission checks.
3. Impact occurs when untrusted content steers the agent to exfiltrate private data through an enabled outbound channel or tool call.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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

MCP authorization is the control layer that matters, because authentication only tells you who connected. MCP standardises transport and token handling, but it does not define the permission model that decides whether a specific tool call should happen. That is why security failures in this space keep clustering around scopes, tool reach, and data exposure rather than around login mechanics. Practitioners need to treat MCP as a policy design problem first and an integration problem second.

Context-window exposure has become the new trust boundary for AI workflows. Once sensitive data and untrusted input are combined inside a model context, the old assumption that access can be reasoned about at request start breaks down. The issue is not just credential strength. It is that the model can be induced to act on mixed-trust inputs in ways human reviewers never explicitly authorised. That changes how identity teams should think about containment, because the relevant boundary is runtime context, not only account possession.

Deterministic authorization must govern AI agents as first-class subjects. The article is right to reject probabilistic security as a substitute for access control. AI systems can assist with anomaly detection, but they cannot decide the legitimacy of an action with acceptable reliability when the action itself is the security event. That pushes NHI and IAM teams toward policy enforcement models that can evaluate agents, tools, and resources as explicit subjects with narrow, runtime-scoped permissions.

Identity blast radius is now a design variable, not an accident. Every additional tool, connector, and data source increases the number of permission checks and the number of places a misuse can compound. That means teams cannot evaluate MCP deployments only by whether authentication works. They must measure how far a valid token can reach, how much context it can influence, and how quickly the authorisation boundary can be reconfigured when workflows change.

AI security programmes that ignore NHI-style permissioning will misread the risk. MCP does not create a new category of identity problem so much as it exposes how fragile existing authorisation models are when machine actors can retrieve data, invoke tools, and communicate outward in one session. The practical conclusion is clear: AI governance, NHI governance, and access control design now have to be treated as one operating model, not three separate conversations.

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.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Authorization debt is the hidden MCP risk: teams can ship a working agent-to-tool connection long before they can defend the permission boundaries around it. That debt shows up when scopes become proxy security, and proxy security fails as soon as the agent can chain data access, context ingestion, and outbound communication in one session.

MCP programmes should be evaluated by how narrowly they constrain tool reach, not by how cleanly they authenticate users. If a valid token can still traverse multiple data sources and execution paths, the organisation has built a connection layer, not an identity control layer.

For practitioners

• Define MCP scopes by action, not by server Map each tool and resource to the smallest meaningful permission set, and avoid broad tokens that cover unrelated read and write operations.
• Enforce runtime authorization checks Verify every tool call at execution time using current context, current subject, and current resource state instead of trusting a session started earlier.
• Break the lethal trifecta where possible Separate access to private data, untrusted content ingestion, and external communication paths so one agent session cannot combine all three.
• Treat AI agents as first-class subjects Model agent permissions separately from human users and service accounts so review, revocation, and scoping decisions reflect the actual actor.
• Use deterministic policy decisions for sensitive actions Reserve probabilistic detection for alerting and triage, but require explicit allow or deny logic for tool calls that can move or expose data.

Key takeaways

• MCP security failures are mainly authorization failures, because the protocol standardises connectivity while leaving permission decisions to implementers.
• When private data, untrusted content, and external communication are combined, AI workflows can create an exfiltration path even with valid authentication.
• The practical control point is runtime policy enforcement, where each tool call is checked against the current subject, resource, and context.

Key terms

• 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.
• Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
• Deterministic Authorization: Deterministic authorization means the same request, policy, and context always produce the same decision. That property matters because security teams need access controls they can reproduce during audits, investigations, and incident response. It is especially important when AI is involved upstream but not at the decision boundary.
• Lethal Trifecta: A risky AI agent condition where one system can read private data, consume untrusted content, and communicate externally. When those three capabilities overlap, the agent can be tricked into disclosing sensitive information through legitimate tools without a conventional exploit.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.