MCP security and agentic access risks are accelerating in 2025

At a glance

What this is: This is Pomerium’s August 2025 roundup of MCP and agentic access security developments, with the clearest finding being that trusted MCP configurations can be abused after approval to achieve remote code execution.

Why it matters: It matters because identity teams now have to govern non-human access paths where approval, tool trust, and execution can diverge after the fact across NHI, agentic AI, and platform access programmes.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Pomerium's August roundup on MCP security and agentic access risk

Context

MCP security is now an identity governance problem as much as it is an application security problem. When a trusted tool bridge can be swapped, auto-started, or reused after initial approval, the security boundary moves away from the prompt and into the lifecycle of access, intent, and configuration control.

For NHI and agentic AI programmes, that shift matters because the risky object is no longer just a token or secret. It is the combination of permission, tool connectivity, and execution path, which means teams need controls that survive post-approval mutation rather than assuming the first authorisation event is enough.

The August incidents in this roundup show that agentic access is already colliding with zero-trust expectations. The practical question is no longer whether agents can call tools, but whether those tool calls remain bounded when the surrounding configuration changes.

Key questions

Q: How should security teams govern MCP integrations that can execute commands locally?

A: Treat every MCP integration that can execute commands as a privileged runtime path, not a documentation convenience. Require integrity-protected configuration, revalidated authorisation, and monitoring for file changes that alter execution behaviour after approval. If a trusted configuration can be rewritten, the access control is not durable enough for production use.

Q: Why do MCP-based agent workflows increase identity risk compared with ordinary app integrations?

A: MCP-based workflows increase identity risk because they bind tool access to runtime context, configuration state, and execution triggers. A one-time approval can be reused after the underlying file or command path changes, which means the trust decision can outlive the trusted object. That creates a wider identity blast radius than static integrations.

Q: What do security teams get wrong about zero trust in agentic access environments?

A: Teams often assume zero trust means the initial connection is enough if the gateway is authenticated. In agentic environments, that is incomplete. The key question is whether the tool, its configuration, and its execution path are continuously revalidated, because any one of those can change after the first approval.

Q: Who is accountable when an approved MCP tool is later modified and causes compromise?

A: Accountability usually spans the platform owner, the team that approved the integration, and the operator responsible for configuration integrity. The governance failure is treating approval as a one-time event instead of an ongoing control relationship. Frameworks that emphasise access lifecycle and continuous verification are the right reference points here.

Technical breakdown

How malicious MCP file swaps turn trusted approval into code execution

In Cursor-style MCP flows, a user may approve a configuration once and then treat the connection as trusted. The weakness is that the configuration file itself remains mutable, so an attacker who can alter it later can preserve the appearance of legitimacy while changing the command that runs. That creates remote and persistent execution without requiring a fresh approval step. The technical failure is not just the presence of a tool bridge, but the absence of binding between the approved intent and the later-executed configuration state.

Practical implication: bind approval to immutable configuration or signed policy state, not to a file path that can be edited after consent.

Why MCP auto-start behaviour expands the attack surface

Auto-start integrations shift risk from interactive use to background execution. If a local MCP configuration is rewritten to launch commands when a project opens, the system can execute attacker-controlled actions before a human notices the change. That matters because the trigger is operational convenience, not adversarial intent, and the attack path exploits trust in startup behaviour rather than a classic login compromise. In practice, auto-start turns a single approval into a recurring execution primitive.

Practical implication: separate approval from execution triggers and disable unattended MCP startup where the configuration can be altered locally.

Why OAuth 2.1 and zero-trust controls are being pushed into MCP

OAuth 2.1 matters in MCP because tool access is fundamentally an authorisation problem, not just a model orchestration problem. If the protocol can connect conversational inputs to infrastructure and data sources, then the authorisation layer has to define who or what can act, what scopes are valid, and how those scopes are revalidated over time. Zero-trust practice fills the other gap by assuming the connection itself is not inherently trustworthy just because it was once approved. That combination is why Docker and other commentators are pressing for stricter controls around the ecosystem.

Practical implication: apply explicit scope validation, reauthorisation, and zero-trust boundaries to every MCP-connected workflow.

Threat narrative

Attacker objective: The attacker wants to convert a trusted MCP integration into persistent execution and downstream control over the victim environment.

1. Entry occurs through a malicious or modified MCP configuration that is treated as trusted after an initial approval event.
2. Escalation follows when the altered configuration executes attacker-controlled commands, producing remote shell access or persistent code execution.
3. Impact lands on the developer workstation or connected environment, where the attacker can steal credentials, run arbitrary commands, or pivot into adjacent systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Approval does not equal trust durability: MCP exposes a governance gap where a one-time consent event is treated as if it covers future execution state. That assumption fails because the configuration can change after approval while the tool path still appears legitimate. The implication is that identity governance for agentic access has to follow the lifecycle of the binding, not the lifecycle of the first approval.

Identity security for agentic access is becoming configuration security: The article shows that tool connectivity, startup behaviour, and post-approval mutation now sit inside the identity boundary. That makes MCP a useful example of how access control, workload identity, and software supply chain risk converge in agentic environments. Practitioners should treat mutable tool wiring as part of the authorised surface, not as a separate implementation detail.

Zero trust is the right posture, but not the whole control set: Zero-trust language appears repeatedly because MCP makes implicit trust expensive. However, the real governance issue is whether each tool invocation remains bounded after the initial session starts. For identity programmes, that means continuously verifying not just the caller, but the integrity of the call path itself.

Dynamic tool access creates identity blast radius: Once an agent or developer tool can reach infrastructure, secrets, or code execution through a local configuration bridge, a small trust failure can cascade fast. That is why this category does not behave like traditional application access. The practitioner conclusion is that blast radius now depends on how much runtime authority the tool chain inherits from the approved identity.

Agentic access governance still assumes stable state, and MCP breaks that assumption: Least privilege was designed for a condition where access scope is knowable at grant time. That assumption fails when the actor can rebind tools, mutate configuration, or trigger execution through changing context after approval. The implication is not merely to add another control, but to rethink whether grant-time policy can describe runtime behaviour at all.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For deeper governance context, the Ultimate Guide to NHIs explains why lifecycle control, rotation, and offboarding matter when access becomes machine-driven.

What this signals

Mutable tool paths should now be treated as part of the identity perimeter: Once a trusted MCP integration can be rewritten after approval, programme owners need to assume that access decisions may outlive the object they were meant to secure. That changes how teams think about recertification, evidence, and drift monitoring across agentic and non-human access.

A practical programme response is to separate human approval, configuration integrity, and execution telemetry into three different control layers. If those layers are merged, a single approval can become a standing privilege path for code execution.

The broader signal is that agentic access is forcing IAM, PAM, and workload identity teams to converge on runtime verification. The boundary is no longer the login or token alone, but the integrity of the tool chain that turns identity into action.

For practitioners

• Bind approvals to immutable configuration state Require signed or version-locked MCP configurations so an approved tool path cannot be silently swapped after consent. Review any workflow where approval is granted once but execution may recur from a mutable local file.
• Disable unattended auto-start for mutable MCP integrations Treat project-open triggers as execution events, not convenience features, unless the configuration is integrity-protected and monitored. This is especially important for desktop tools that can run commands before a user notices a change.
• Revalidate scope at every tool invocation Use zero-trust and OAuth 2.1 controls to re-check scope, audience, and intent whenever an MCP-connected tool requests access to code, data, or infrastructure. One approval should not authorize unlimited reuse.
• Inventory MCP paths that can reach secrets or shell access Map every MCP connection that can touch credentials, local shell execution, or infrastructure APIs, then classify it by blast radius. High-impact paths need tighter monitoring than read-only integrations.

Key takeaways

• MCP becomes a governance problem when trusted configurations can be altered after approval and still execute.
• The August incidents show that mutable tool paths can convert convenience features into persistent code execution opportunities.
• Practitioners should treat configuration integrity, reauthorisation, and execution monitoring as core identity controls for agentic access.

Key terms

• Model Context Protocol: A protocol that connects AI systems to tools and data sources through a standardised interface. In practice, MCP becomes an identity problem when access to those tools is granted, reused, or altered outside the original approval state, making configuration integrity part of the security boundary.
• Agentic access: Access granted to an AI system or agent that can select tools and act through runtime decisions rather than fixed scripts. The governance challenge is that the actor may change what it does after approval, so identity controls must account for dynamic behaviour and not just the initial grant.
• Identity blast radius: The amount of damage a compromised identity or trusted access path can create before it is contained. For MCP and agentic systems, blast radius depends on what the connected tool can reach, including code execution, secrets, and infrastructure APIs, not just whether the caller is authenticated.
• Configuration integrity: The property that a trusted file, policy, or routing rule has not been altered since it was approved. In agentic access flows, this matters because a valid approval can become unsafe if the underlying configuration changes and still triggers the same trusted execution path.

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.

This post draws on content published by Pomerium: August 2025 Agentic Access and MCP Content Round-Up: Security, Innovations & Growth. Read the original.