MCP authorization gaps expose enterprise AI agent access control failures

At a glance

What this is: This is an analysis of why MCP authentication does not solve agent authorization, and why static credentials, broad roles, and delegation chains leave AI agent access control exposed.

Why it matters: IAM, NHI, and AI governance teams need to treat agent authorization as a runtime control problem, because authentication at session start does not constrain what an agent does after it connects.

By the numbers:

• Only 8.5% of MCP servers use OAuth, according to Trust3.
• 1,862 MCP servers are exposed on the public internet, according to Trust3.
• More than 30 CVEs were filed against MCP implementations in a single 60-day window, according to Trust3.
• The official MCP registry grew to over 3,000 registered servers, according to Trust3.

Context

MCP authorization is the gap between confirming an AI agent’s identity and deciding what it may do after it connects. In enterprise deployments, that gap matters because the agent is no longer a passive client. It can query data, call tools, and fan out across systems.

The article argues that conventional IAM patterns break when applied to agentic systems because access must be judged at action time, not only at login time. That is a governance problem for NHI and agent identity programmes, not just a protocol detail.

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 autonomous agents make traditional RBAC less reliable?

A: RBAC becomes less reliable because it assumes the privilege holder will interpret context, follow policy, and remain accountable in a human decision loop. Autonomous agents can chain actions, ignore human intent, and complete work before any review cycle can intervene. That means role assignment alone no longer describes the real risk.

Q: How do security teams know if agent authorization is actually working?

A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.

Q: What should organisations do when MCP endpoints rely on static credentials?

A: They should assume the exposure window is too wide and replace persistent secrets with task-scoped grants, strong audit trails, and action-level policy enforcement. Static credentials are especially dangerous when agents can reach multiple systems from one session, because compromise in one place can propagate everywhere.

Technical breakdown

Why MCP authentication does not equal authorization

MCP, or Model Context Protocol, standardises how AI agents connect to tools and data sources. Authentication proves the caller is valid, but it does not decide which records, functions, or downstream services the caller may touch. That distinction is decisive in agentic environments because the agent can continue reasoning after entry, combine tools in new ways, and traverse delegation chains. In practice, the security boundary shifts from “who are you?” to “what may you do right now, for this declared purpose?” Without that second control, an authenticated agent can still operate far beyond the intent of the original request.

Practical implication: Treat authentication as necessary but insufficient, and place authorization checks at the point of each action.

Why RBAC and OAuth scopes break down for AI agents

Role-Based Access Control and OAuth scopes were built around predictable human workflows and static application behaviour. AI agents are different because they can compose tasks at runtime, inherit roles too broadly, and move through multi-agent delegation chains where the original user context disappears. That creates role blast radius, identity loss, and credential aggregation risk. A role that is acceptable for a person can be dangerously wide for an agent that may act across Snowflake, Salesforce, internal APIs, and document stores in one session. The central issue is not the role name. It is the mismatch between static grants and dynamic machine behaviour.

Practical implication: Review whether your current role and scope model assumes stable intent, then redesign for task-scoped access.

Why tool poisoning becomes worse when authorization is weak

Tool poisoning hides malicious instructions in MCP metadata such as tool descriptions, parameter names, or error text. The agent reads those instructions as part of its normal reasoning path, even when a human would not notice anything suspicious. If the agent also has standing access to private data or external systems, the poisoned instruction can propagate through the tool chain and trigger unauthorized actions. This is why authorization and content trust cannot be separated in agentic systems. Once the agent can both consume untrusted content and act on it, every unchecked tool call becomes a potential execution path.

Practical implication: Assume every tool payload can influence action selection, and enforce authorization before the action executes.

Threat narrative

Attacker objective: The objective is to turn a legitimate agent connection into broad, uncontrolled access to enterprise data and tools.

1. Entry occurs when an AI agent authenticates successfully to MCP, often with static credentials or weakly governed OAuth use.
2. Escalation follows when the agent inherits broad roles or unscoped tokens that let it reach multiple data sources and tools.
3. Impact appears when the agent is able to execute unintended reads, writes, or downstream calls across enterprise systems without per-action checks.

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.
• 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.

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

Authentication-only designs create a false boundary for agentic systems: MCP proves identity, but identity proof does not equal entitlement. Once the agent is inside, the control question changes from access to action, and that is where conventional IAM assumptions begin to fail. The implication is that enterprise AI governance must treat authorization as a runtime decision, not a session property.

Role blast radius is the wrong mental model for agents: RBAC assumes broad, durable permission sets can be tolerated because human intent is relatively stable. Agentic systems break that assumption because the same identity can behave differently from one task to the next, and delegation chains can strip away the initiating user context. That means the programme problem is not merely overprivilege. It is the collapse of intent visibility across machine-to-machine execution.

Purpose-bound access is now an identity control, not a convenience feature: When agents can query a table, call an API, and pivot into another system in one workflow, standing privilege becomes the primary source of blast radius. Fine-grained authorization, identity propagation, and time-bound grants are the minimum structural requirements for governable agentic access. Practitioners should interpret this as a shift from user-centric access control to action-centric enforcement.

Tool poisoning turns protocol trust into a governance problem: MCP metadata is part of the decision surface, not just the transport surface. If the agent can ingest untrusted instructions and act on them without per-action checks, the protocol itself becomes a propagation layer for abuse. The named concept here is authorization gap amplification: one weak decision point can expand across every downstream tool call, so the right question is not whether the agent is authenticated, but whether each action is still entitled to proceed.

Agent identity management must converge with NHI governance: AI agents are non-human identities with runtime decision behaviour, which means their access lifecycle cannot be managed with human IAM assumptions alone. Discovery, purpose scoping, delegation controls, and revocation have to be treated as lifecycle controls for machine actors. The practitioner conclusion is simple: if the organisation cannot explain an agent’s current authority in one step, it does not have governable agent identity.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 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: AI Agent Authorisation Guide

What this signals

Authorization now sits at the centre of agent governance: Authentication establishes that an agent can enter the environment, but the real control question is whether each action is still entitled to proceed. That shifts programme design toward per-action policy, purpose binding, and delegation visibility across NHI and agentic AI estates.

Authorization gap amplification: When an MCP deployment accepts untrusted tool metadata and broad credentials at the same time, one weak control can spread across every downstream tool call. Security teams should treat tool descriptions, parameters, and error paths as part of the trust boundary, not as harmless metadata.

For practitioners

• Inventory every MCP-connected agent Map which agents, tools, data stores, and APIs are reachable through MCP, then classify each connection by business purpose and privilege scope.
• Replace standing access with task-scoped grants Move away from persistent tokens and broad roles, and issue time-bound permissions that are tied to a declared purpose and expire automatically.
• Propagate user identity through delegation chains Ensure downstream tools see the initiating user, the declared purpose, and the current authorization verdict, not just the service account identity.
• Enforce authorization at each action point Place policy checks between the agent and the resource so every read, write, or tool call is evaluated before execution rather than after the session begins.
• Treat tool metadata as part of the trust boundary Review descriptions, parameters, and error text for poisoned instructions, and require the same governance over tool content that you apply to code and prompts.

Key takeaways

• MCP creates a governable identity surface only if authentication is paired with action-level authorization.
• Static credentials and broad roles create excessive blast radius when AI agents can reach multiple enterprise systems from a single workflow.
• The control shift is toward purpose-bound access, delegation visibility, and per-action enforcement at the point of use.

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.
• 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.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Purpose-Based Access: An access model that allows or denies AI use based on why the request is being made, not only who the requester is. It is more precise than role alone because it can combine identity, data labels, and request context to control sensitive AI interactions at runtime.

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.