TL;DR: Model Context Protocol turns agentic AI from text generation into real system action, making tool calls, server trust, and per-call identity controls the true governance boundary, according to JetStream Security. The practical implication is that MCP security must move from monitoring prompts to governing execution paths, credentials, and tool combinations.
At a glance
What this is: This is an analysis of why Model Context Protocol changes AI risk from conversational output to tool-driven action, and why governance has to focus on the execution layer.
Why it matters: It matters because IAM, NHI, and agentic AI programmes need controls for who or what can call tools, with what credentials, and under which policy before an agent can affect production systems.
Context
Model Context Protocol is the layer where an AI agent stops answering and starts taking actions. That shifts the governance problem from content safety to identity, authorisation, and tool-use control, because the harmful event is no longer a bad sentence but a valid action in a live system.
In enterprise AI, the weakest point is often not the model itself but the path from model output to external systems. Once an agent can reach email, CRM, file, or code tools through MCP security guidance, policy has to govern what the agent can do, not just what it can say.
This changes the way security teams think about shadow AI, supply chain exposure, and delegated access. The article frames MCP as an execution fabric that can magnify small trust mistakes into real operational damage.
Key questions
Q: What breaks when MCP integrations are not governed tightly?
A: Tool trust breaks first, then command integrity, then secret exposure. If an assistant can register or trust the wrong MCP server, the environment may execute commands or disclose data in ways the developer never intended. That makes MCP onboarding part of access governance, not a simple configuration step.
Q: Why do MCP-based agents increase identity governance risk?
A: Because the agent can select tools and chain actions at runtime, which means authority is no longer fixed at issuance. Traditional IAM assumes a stable entitlement set, but MCP lets context change behaviour, so the real risk is authority drift across the session.
Q: How do security teams decide when an MCP deployment is production-ready?
A: A deployment is production-ready when identity is centralized, access is group-scoped, tool calls are logged, revocation is tested, and sensitive data is filtered before it reaches model context. If those controls are missing, the system may be functional but it is not yet governable.
Q: What is the difference between a safe MCP tool and a safe MCP workflow?
A: A tool can be safe in isolation while the workflow is unsafe in combination. Read-only access, web fetch, email, and CRM tools may each look acceptable on their own, but the agent can chain them into data exposure or destructive action. Practitioners should assess the full workflow path, not just individual permissions.
Technical breakdown
Why MCP changes the threat model for agents
MCP is a tool-execution protocol, not just a messaging layer. The model sees tool names, descriptions, outputs, and context, then uses them to decide which action to take next. That means the security boundary moves from prompt safety to action safety. A harmless-looking request can result in a destructive tool call if the agent is allowed to combine tools, inherit context from a compromised server, or act with credentials that look legitimate to downstream systems. The real risk is not the text the model emits but the authority it can exercise through connected tools. See the Agentic AI Security Guide.
Practical implication: Treat every MCP connection as an executable permission boundary, not a passive integration.
Why MCP servers behave like a new software supply chain
MCP servers are often installed from public registries or repos in the same casual way teams add developer dependencies. That creates a supply chain problem: unvetted dependencies, unknown provenance, local credentials, and hidden tool behaviour all enter the environment together. The server is not only a data source. It can also supply instructions, tool descriptions, and outputs that the model will trust unless the environment constrains them. This makes inventory, provenance, and drift control central to MCP governance, because the server layer can change the agent’s effective behaviour without changing the model itself. See the AI Supply Chain Security and AI-BOM Guide.
Practical implication: Inventory MCP servers and verify their provenance before allowing them to participate in production agent flows.
Why per-tool review misses cross-server abuse paths
Security teams often review each MCP server in isolation, but agents compose tools across servers. A read-only file tool and a web-fetch tool can be harmless on their own yet combine into an exfiltration path. That is why tool inventory alone is insufficient. The relevant question is whether the agent can chain permitted actions into a harmful outcome across multiple systems. This is where policy has to become path-aware, because the danger is often in the sequence of actions the agent can assemble at runtime, not in any single approved action. Read OWASP Agentic Applications Top 10.
Practical implication: Analyse combined tool paths, not just individual server permissions, before approving agent workflows.
Threat narrative
Attacker objective: The attacker objective is to convert ordinary agent access into real system changes that appear legitimate at the point of execution.
- Entry occurs when an agent is given access to an MCP server and inherits the server's tools and context as part of normal operation. The initial interaction is legitimate, which is why the exposure is easy to miss.
- Credential or authority abuse follows when the agent acts through valid enterprise credentials or trusted server outputs, so the resulting request looks like a normal user action.
- Escalation happens when a manipulated tool description, hidden instruction, or unsafe tool combination steers the agent into a harmful action path that the original request did not intend.
- Impact lands in the downstream system of record, where the agent can send data, delete records, or otherwise change state at machine speed with no obvious prompt-side anomaly.
Breaches seen in the wild
- Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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 governance is now the real control plane for agentic AI. The important shift is not that models got smarter, but that they can now trigger state change in enterprise systems. Once the protocol carries action rather than only language, the control boundary moves to the point where identity, tool selection, and execution meet. Practitioners should stop treating MCP as a transport detail and start treating it as an access governance surface.
Prompt safety is no longer sufficient once a model can act. Traditional AI controls can reduce bad text, but they do not govern a tool call that sends email, deletes records, or moves data across systems. That is a different class of risk because the harmful event completes inside normal business workflows. The implication is that AI security and identity security now intersect directly at the action layer, especially where agents inherit human or service credentials.
Trust in MCP must be built as an identity problem, not a content problem. The article correctly points to discovery, hardening, authentication, and policy as sequential dependencies. In practice, that means the organisation has to know which servers exist, which identities they use, and what action scope each one opens. The governance question is no longer whether the model can be trusted to answer well. It is whether the environment can prove who authorised the action and under what delegated authority.
Shadow AI becomes operationally dangerous when it is attached to real tools. Unmanaged agents are not just unknown software; they are unknown actors with reach into business systems. That makes discovery and inventory foundational, because an undiscovered server can still participate in a real workflow and expose the organisation before any central review occurs. Practitioners should treat unmanaged agent infrastructure as an identity and supply chain issue, not a chatbot hygiene issue.
Tool chaining creates an identity blast radius that individual approvals cannot see. The named concept here is identity blast radius: the set of downstream systems an agent can affect when multiple tools are combined under one runtime identity. That blast radius is larger than any single server review suggests, which is why per-tool approval is not enough. Security leaders need to reason about the composed path from granted access to final system impact, not just about isolated entitlements.
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.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
The next governance question is not whether organisations will adopt MCP, but whether they will treat agent action paths as first-class security objects. Discovery, authentication, and policy need to converge before the agent reaches a live system, because post-event review arrives after the tool call has already changed state.
Identity blast radius: MCP expands the blast radius of a single agent because one runtime identity can touch email, CRM, file, and web systems in sequence. That makes tool-path analysis a governance requirement, not an optimisation. Security teams should expect the control model to shift from app-by-app approval to composed-action approval.
The scale of the problem is visible in the surrounding ecosystem: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. That figure points to a category that is already operational, not hypothetical, and it argues for inventory and containment before broad deployment.
For practitioners
- Inventory every MCP server Map which developer laptops, endpoints, and hosted services already run MCP servers, then record the tools each one exposes.
- Require short-lived identities for agent actions Broker MCP requests through enterprise identity and avoid persistent secrets for agents or servers wherever possible. See the Agentic AI Identity Guide.
- Review tool combinations, not only server lists Test whether safe-looking tools can combine into exfiltration, deletion, or other harmful action paths across systems.
- Enforce drift detection on approved server setups Baseline the approved tool list, server configuration, and descriptions, then alert when they change unexpectedly.
- Block high-risk actions in the traffic path Place policy at execution time so risky actions are denied or flagged before the agent completes them.
Key takeaways
- MCP changes AI governance by turning model output into real system action, which moves the control problem to identity and execution.
- The article's central warning is that safe-looking tools and normal credentials can still produce harmful outcomes once an agent chains them together.
- Discovery, hardening, identity, and path-aware policy are the controls that matter most when agents can act through MCP.
Related NHI Mgmt Group resources: MCP Security Guide · AI Supply Chain Security and AI-BOM Guide · Agentic AI Security Guide · Shadow AI and AI Agent Discovery Guide
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 | MCP lets agents exercise delegated tool authority that can be misused at runtime. |
| ASI02 — Tool Misuse | The article centres on harmful actions taken through legitimate tool calls. | |
| Recommendation — Constrain agent identity scope and review every tool call path for privilege abuse. Validate that each tool call is authorised for the current task and context. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP security depends on strong identity proofing and short-lived credentials for non-human actors. |
| NHI-05 — Overprivileged NHI | The risk rises when agents can reach more tools than their task requires. | |
| NHI-08 — Environment Isolation | The article highlights the danger of combining tools and credentials across weakly separated environments. | |
| Recommendation — Use short-lived authentication and eliminate long-lived secrets for MCP servers and agents. Minimise tool scope and remove unused MCP permissions from agent identities. Separate MCP environments so one agent cannot bridge unrelated systems without review. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about authorising agent actions through governed permissions. |
| ID.AM-02 — Software Platforms and Applications Inventory | MCP governance starts with knowing which servers and tools already exist. | |
| Recommendation — Apply PR.AA-05 to ensure agent entitlements match current task scope and policy. Inventory MCP servers and exposed tools before allowing them into production. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes credential-mediated tool abuse and movement across connected systems. |
| Recommendation — Map MCP abuse scenarios to credential access and lateral movement detections. | ||
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.
- MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- 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.
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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org