MCP adoption is outpacing security controls for agentic access

At a glance

What this is: This roundup tracks September 2025 MCP adoption news and security incidents, and its central finding is that MCP is spreading faster than the access controls built to govern it.

Why it matters: IAM, PAM, and NHI teams need to treat MCP endpoints as governed production access paths because agents inherit real privileges, real context, and real blast radius when controls lag behind adoption.

Context

Model Context Protocol is becoming the connective tissue between AI agents and the systems they can use, including data sources, browsers, and internal applications. In this article, the governance problem is not the protocol itself but the speed at which agentic access is moving from experimentation to production while identity and authorization controls remain uneven.

September 2025 produced a mix of ecosystem expansion and security warnings around MCP. Pomerium’s roundup shows why this matters for agentic AI governance: once an agent can call tools, reach external services, and act on context, access control has to be designed for the behaviour of the agent, not just the existence of the protocol.

Key questions

Q: What breaks when an MCP server has no clear authorization boundary?

A: Without a clear authorization boundary, teams are forced to improvise trust decisions inside the server logic itself. That creates ambiguity around who issued the token, what claims are trusted, and how consent is enforced. In practice, the result is fragile integrations, inconsistent scope handling, and a much higher chance that agent requests exceed intended permissions.

Q: Why do prompt injection attacks become more serious in MCP environments?

A: Prompt injection becomes more serious because the agent can act on manipulated content, not just display it. If the agent can call tools after reading hostile input, the attack can cross from text influence into real system action, including data access, workflow changes, or exfiltration. The risk is action abuse, not output corruption.

Q: What are the signs that an MCP access model is too broad?

A: Common signs include agents that can reach multiple internal systems through one connection, shared credentials across tools, and no per-tool audit trail. If a compromise in one server could touch email, CRM, or code workflows, the access model is wider than the business case justifies.

Q: How should teams govern MCP at scale without overexposing tools?

A: Teams should govern MCP as a capability-based control plane, with explicit approval for server provenance, granular scoping for each tool, and monitoring that covers every request and response. The goal is to keep discoverability useful while preventing shared interfaces from becoming shared privilege.

Technical breakdown

MCP endpoints turn agents into access-bearing actors

MCP is an open protocol that lets AI agents call tools and data sources through standardised interfaces. That makes the endpoint itself a security boundary, because the agent is no longer just generating text. It is operating with delegated access, and whatever authentication, intent checking, and authorization sits behind the endpoint determines how far the agent can go. When MCP is embedded in browsers, coding tools, or data platforms, the practical unit of control becomes the request path, not the model output.

Practical implication: treat every MCP server as a production access surface and apply policy to the request, not just to the model.

Prompt injection and tool abuse are the core MCP abuse paths

The article repeatedly points to prompt injection, indirect prompt injection, and tool abuse as recurring risks. These attacks work because the agent blends trusted instructions with untrusted content and then acts on that content through tool calls. In agentic systems, the dangerous step is often not the model’s reasoning but the execution that follows. Once the agent can search, fetch, write, or send data, a poisoned instruction can become an access event, a data-exfiltration event, or both.

Practical implication: separate instruction sources from execution authority and review which tools an agent can invoke after interpreting untrusted content.

Supply chain exposure makes MCP governance a trust-chain problem

The roundup’s malicious server and backdoored package examples show that MCP risk extends beyond prompts into distribution and packaging. A compromised server, registry entry, or dependency can become an access broker that sits between the agent and the target system. That turns MCP into a trust-chain problem: you are not only vetting the client and the model, but also the server, package, registry, and any remote connector behind it. Identity governance has to cover the whole delegation chain.

Practical implication: inventory every MCP server, package, and registry source as part of the access chain before allowing agent connections.

Threat narrative

Attacker objective: The attacker wants to turn trusted agent connectivity into delegated access that can be reused for data theft, workflow abuse, or broader system compromise.

1. Entry occurs when users or agents connect to a malicious or compromised MCP server that appears legitimate and is published through a package, registry, or integration path.
2. Credential access follows when the server captures tokens, API keys, or delegated session context that agents send while using the interface.
3. Escalation happens when the attacker reuses that trust to reach mail, CRM, browser, or coding workflows that the agent can already access.
4. Impact is achieved through data exfiltration, unauthorized tool use, or remote control of downstream systems through the stolen access path.

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

Agentic access has become an identity problem before it is a product problem: MCP is being adopted as if tool connectivity were the main issue, but the real issue is delegated authority. Once agents can invoke tools and touch live systems, the organisation is governing runtime behaviour, not just integration plumbing. That shifts MCP from developer convenience into identity governance territory, where access scope, intent, and auditability are the primary controls.

Identity controls built for static callers do not map cleanly to MCP behaviour: Traditional IAM assumes a known principal, a known purpose, and a stable path of action. MCP complicates all three because the agent can combine tools, switch context, and trigger actions in response to untrusted input. The result is an authorisation model that looks complete on paper but fails at execution time.

Tool exposure is now the control surface: The article’s examples show that the most important question is no longer whether an agent can connect, but which tools it can reach after connecting. Fine-grained authorization, explicit context boundaries, and per-tool policy become more important than broad platform-level trust. Practitioners should think in terms of reachable blast radius, not general AI capability.

MCP governance is becoming a supply-chain discipline: Malicious servers, backdoored packages, and registry-driven discovery mean the access path itself is part of the threat model. That expands governance from application access into ecosystem assurance, including inventory, provenance, and revocation across the full chain. The practitioner takeaway is to govern MCP like a high-value production API plus a software supply chain at the same time.

Identity blast radius is the right concept for MCP programmes: The same MCP connection can expose multiple downstream systems, multiple credential types, and multiple modes of misuse. That makes the reachable blast radius of each agent a better governance metric than simple connection counts or adoption metrics. Teams should measure how far a compromised agent or server can travel, because that determines the real control requirement.

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: AI Agent Identity Security Buyer's Guide

What this signals

Identity teams should assume MCP will keep moving upstream into more products. As that happens, the practical question becomes how quickly organisations can map each agentic connection to an accountable identity, a defined purpose, and a bounded tool set. Without that mapping, access reviews stay descriptive while the real risk grows at runtime.

Identity blast radius is the control concept that will matter most. If one MCP connection can expose mail, code, documents, or CRM workflows, the issue is not the model’s intelligence but the number of systems a single delegated path can reach. The programme signal is simple: measure reachability, not just adoption.

For practitioners

• Inventory every MCP server and connector Map each server, registry entry, package source, and downstream system the agent can reach. Classify whether the connection is read-only, write-capable, or capable of sending messages or triggering actions.
• Scope authorization per tool, not per agent Define the exact tools and operations each agent may use, then narrow access so prompt interpretation cannot automatically become broad system access.
• Treat untrusted content as execution-adjacent Assume prompt injection and indirect prompt injection can redirect the agent into calling legitimate tools with malicious intent embedded in the input.
• Verify package and server provenance before onboarding Require ownership, signing, and review of MCP packages and servers before they are allowed to expose internal systems to agent traffic.
• Measure agent blast radius continuously Test how many systems, credentials, and actions a compromised agent could reach if a single MCP connection were abused.

Key takeaways

• MCP adoption is exposing a gap between rapid agentic rollout and the access governance needed to contain delegated tool use.
• The article links that gap to prompt injection, malicious servers, and supply-chain abuse, showing that the trust boundary now extends beyond the model itself.
• Practitioners should focus on per-tool authorization, provenance checks, and blast-radius measurement before allowing agents into production workflows.

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.
• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

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.