TL;DR: August’s MCP and agentic AI roundup shows high-severity RCE flaws, OAuth 2.1 pressure, and vendor adoption momentum, according to Pomerium and the cited incident reports. The core issue is that trust is still being granted to mutable tool chains and configurations that can be altered after approval.
At a glance
What this is: This is Pomerium's August 2025 round-up of MCP and agentic access security developments, highlighting RCE flaws, post-approval config tampering, and growing pressure to apply OAuth 2.1 and zero-trust controls.
Why it matters: It matters because MCP turns access decisions into runtime trust problems, which forces IAM, PAM, and NHI teams to govern what agents and tools can do after approval, not just at sign-in.
Context
MCP security is a governance problem before it is a tooling problem. The core issue is that agentic access can change after approval, especially when a trusted configuration file or server is modified later to introduce new commands or destinations.
In practice, that means static approval models struggle when tool chains are mutable and runtime behavior is not fixed at onboarding. For NHI and agentic AI programmes, the question is not just who can connect, but what that connection can become after trust has already been granted.
Key questions
Q: What breaks when an MCP approval can be modified after it is granted?
A: The approval no longer represents the action the system will actually execute. If a trusted configuration or server can be changed later, the original consent becomes stale and the identity boundary collapses into a mutable execution path. Teams need to treat that as an authorization failure, not just a configuration issue.
Q: Why do MCP connectors increase risk in agentic workflows?
A: They create a larger runtime trust surface because each connector can become a path to tools, commands, data, or workstation actions. If identity, intent, and configuration are not continuously checked, a single compromised or modified connector can redirect legitimate access into unauthorized behavior.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.
Q: What should teams do when an MCP server is updated or replaced?
A: Treat the change like an identity lifecycle event. Revalidate the server’s permissions, review tool descriptions and command paths, re-sign or re-approve the component if needed, and confirm that old access paths are removed before the new version is trusted.
Technical breakdown
Why post-approval MCP changes create control gaps
MCP environments are vulnerable when the trust decision is made once and the execution path is allowed to evolve later. In the Cursor AI cases described in the article, a configuration or file swap after approval changed the effective command path without reauthorisation. That pattern turns a one-time approval into a standing permission boundary that can be repurposed. For identity teams, the issue is not only compromise but mutable authorisation state. Practical control design has to treat configuration drift as an access event, not just a system hygiene issue.
Practical implication: monitor MCP configuration changes as authorization changes, not just as file edits.
OAuth 2.1 and zero trust for MCP access
The article links the MCP debate to OAuth 2.1 and zero-trust thinking because tool access needs to be constrained by fresh context, not assumed safe once a session exists. OAuth 2.1 can help standardize stronger authorization flows, but it does not solve the broader issue if the connected tool can later alter its behavior or request scope. Zero trust matters here because it forces continuous validation of identity, intent, and environment before each action. That is especially important when agents can chain tools rapidly and at machine speed.
Practical implication: require continuous authorization checks for agentic tool calls rather than relying on initial approval alone.
MCP adoption expands the identity attack surface
The article shows that MCP is becoming a practical integration layer for AI-driven workflows, which means every new server, prompt path, and connector becomes part of the identity perimeter. That widens the blast radius of any flaw because a vulnerable server can expose commands, credentials, or workstation control. The problem is not limited to one vendor or one editor. As adoption grows, governance has to extend to inventory, trust classification, and usage boundaries for every MCP endpoint that can touch production data or developer systems.
Practical implication: inventory MCP servers and classify them as governed identity endpoints before allowing enterprise use.
Threat narrative
Attacker objective: The attacker wants to turn a trusted MCP integration into a post-approval execution path that yields code execution, shell access, or broader environment compromise.
- Entry occurs when an attacker reaches an MCP-connected workflow through a malicious server, modified configuration, or vulnerable tool integration.
- Credential or command access follows when the trusted MCP path is reused after approval and the attacker swaps in a malicious action or command sequence.
- Impact occurs when the compromised MCP path executes code, opens a shell, or extends control over the developer workstation or connected environment.
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
Mutable approval is the real MCP trust failure: the article shows that one-time consent is too weak when configurations can be altered after approval and reused as an execution path. That is not a tooling defect alone, it is a governance mismatch between static approval and dynamic runtime behavior. The practitioner conclusion is that MCP access must be treated as a living authorization state, not a frozen grant.
Post-approval configuration drift is a separate identity event: the Cursor cases illustrate that a trusted MCP file can become a different control surface after the user has already approved it. That means file integrity, server identity, and command scope have to be governed together. The practitioner conclusion is that change control and access control can no longer be managed as separate disciplines for agentic workflows.
MCP expands the machine identity perimeter beyond classic service accounts: every server, connector, and tool bridge can act like an operational identity with its own trust boundary. As adoption grows, the real risk is not only exposed secrets but unbounded delegation across mutable integrations. The practitioner conclusion is that inventory and lifecycle governance now have to include MCP endpoints as first-class identity assets.
Zero-trust access becomes mandatory when agentic tools can re-compose actions at runtime: the article's security warnings point to a control model that assumes behavior can change after admission. That assumption fails when tool chains can be modified or chained into new command paths without fresh review. The practitioner conclusion is that continuous verification must move from the perimeter to the individual action.
Ephemeral trust debt is the right way to name this category: once an MCP approval is granted, the control debt accumulates every time the underlying config, server, or prompt path changes without a new decision. This is why MCP risk scales faster than conventional app integrations. The practitioner conclusion is that teams need to measure trust freshness, not just connection count.
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 Observability, Audit and Incident Response Guide
What this signals
Ephemeral trust debt: MCP programmes now need a way to measure how much hidden risk accumulates after approval. Once a connector, file, or server can be changed without a new decision, the control burden shifts from onboarding to continuous trust verification.
The practical implication is that agentic access governance must combine inventory, file integrity, and runtime authorisation checks. Otherwise, teams will keep certifying a decision that no longer matches what the system is capable of doing.
For practitioners
- Audit MCP approval points for post-approval mutation Identify where a one-time approval can be reused after a configuration or server change. Require revalidation whenever the MCP file, connector, or command set changes.
- Treat MCP configuration files as governed access objects Add file integrity checks and change alerting for ~/.cursor/mcp.json and equivalent MCP configuration locations so configuration drift is visible as an authorization event.
- Enforce continuous authorization for agent tool calls Use identity and context checks on every MCP-mediated request instead of assuming the initial session grant covers later actions and tool switches.
- Inventory and classify MCP servers before production use Maintain a register of approved MCP endpoints, owners, and allowed command scopes so teams can review whether each server still matches its intended trust level.
Key takeaways
- MCP security problems are showing up where trust is established once and then silently altered through file swaps, server changes, or runtime tool chaining.
- The article ties those risks to real attack paths, including persistent code execution through modified MCP files and wider concern about the protocol's expanding exposure surface.
- Practitioners should govern MCP as a live authorization problem with continuous verification, configuration integrity, and tight inventory of every connected server.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Mutable MCP approvals let agentic systems reuse trust in unsafe ways. |
| ASI02 — Tool Misuse | The incidents center on malicious or repurposed tool execution through MCP integrations. | |
| Recommendation — Apply ASI03 to re-authorize agentic tool use whenever scope, context, or configuration changes. Limit tool permissions and monitor for unexpected MCP-driven command paths under ASI02. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP connectors and servers become unsafe when authentication does not reflect runtime trust changes. |
| NHI-08 — Environment Isolation | The article shows MCP flaws can pivot from tool access into developer workstation control. | |
| Recommendation — Review MCP authentication flows for stale trust assumptions and revalidate access at each action. Isolate MCP-connected tools from sensitive workstations and production environments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This article is fundamentally about authorizing agentic access and keeping it current. |
| Recommendation — Apply PR.AA-05 to keep MCP entitlements aligned with current server state and approved scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern spans trusted access abuse and movement from MCP path to host control. |
| Recommendation — Map MCP abuse paths to TA0006 and TA0008 and hunt for post-approval command changes. | ||
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.
- Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org