TL;DR: MCP turns LLMs from chat-only systems into tool-using agents that can read files, create tickets, and interact with development workflows, but it also expands the attack surface through prompt injection, path traversal, and supply-chain style abuse, according to Semgrep. The governance problem is no longer whether AI can act, but how identity, privilege, and context boundaries are enforced when it does.
At a glance
What this is: Semgrep explains that MCP moves AI systems from chat-only interaction into real tool use, while also introducing new exposure to malicious context, untrusted servers, and unsafe file access.
Why it matters: This matters because IAM, NHI, and AI security teams now have to govern what an AI model can reach, what context it can trust, and what privileges it can exercise inside development workflows.
Context
MCP, or Model Context Protocol, is a standard that lets an AI model connect to external tools instead of staying inside a chat window. That changes the security problem from prompt handling to tool governance, because the model can now trigger actions, read files, and interact with live systems.
The identity question is not whether the model can talk to a service, but how access is issued, bounded, and revoked once the model starts acting through tools. That puts machine identity, context trust, and least-privilege design at the center of AI-assisted development.
Semgrep's framing is typical of the current MCP debate: the technology is attractive because it improves workflow reach, and risky because it collapses the line between content and control.
Key questions
Q: What breaks when MCP servers run with shared local trust?
A: Shared local trust breaks isolation because any process on the machine may be able to call the server, and the server may inherit privileges that were never intended for broad reuse. This creates a local attack surface where authentication is bypassed or reduced to process proximity instead of explicit authorisation.
Q: What happens when AI agents use untrusted MCP servers?
A: When AI agents connect to untrusted MCP servers, the organization can inherit supply chain risk through the integration path. That can expose tools, credentials, or data to misuse, and it can create a route for malicious or vulnerable components to influence agent behavior. Security teams should treat server trust, isolation, and approval as explicit controls.
Q: How should security teams secure MCP deployments in SaaS and developer environments?
A: Security teams should treat MCP as a new trust boundary, not just another integration layer. Protect both the agent-to-server and server-to-SaaS paths with short-lived authentication, per-user authorization, tool whitelisting, and inspection of tool responses before they reach the model context. Add audit logging, data classification, and redaction for sensitive content such as PII, PHI, secrets, and source code.
Q: What should teams do when AI tools can read files and run commands?
A: They should apply privileged dependency controls before approval, including provenance checks, least-privilege scoping, runtime monitoring, and prompt or data redaction. If the tool can execute or access sensitive paths, it should be treated like a high-risk integration. The control objective is to prevent hidden automation from bypassing the enterprise boundary.
Technical breakdown
How MCP turns a model into a tool user
MCP defines a common way for an LLM to discover and call external tools, which can include file readers, ticketing systems, code repositories, and other services. The model does not become smarter in the abstract; it becomes operational because the protocol gives it a structured way to request actions and receive results. That is why MCP is central to agentic AI. Once the model can invoke tools, the security model shifts from prompt-only safety to authorisation, context integrity, and runtime containment. Practical implication: treat every MCP-connected capability as a governed access path, not just a feature of the model.
Practical implication: govern each MCP tool as a privileged integration with explicit scope, identity, and revocation controls.
Why untrusted MCP servers create prompt injection risk
An MCP server can contribute tool definitions and descriptions that the model consumes as context, which means malicious instructions can hide inside what looks like metadata. If a server is compromised, typo-squatted, or simply untrusted, the model may execute instructions that were never intended by the developer or user. This is a supply-chain problem in AI clothing: the trust decision happens before the action, inside the model's context. The risk is compounded when the server has access to secrets, file paths, or project data that the model should not be able to request. Practical implication: pin, vet, and isolate MCP servers before allowing them into production workflows.
Practical implication: restrict MCP server intake to vetted sources and isolate them from sensitive credentials and project data.
Why path traversal becomes easier when data and control blur
Traditional application security separates untrusted input from executable operations, but MCP can collapse that boundary when a model turns user intent into a file request. If a tool accepts a path string without validation, a crafted request such as directory traversal can push the server to read files outside the intended workspace. That is not a new vulnerability class, but MCP makes it more reachable because the model intermediates the request and can normalise dangerous input. The control failure is weak validation at the tool boundary, not the model itself. Practical implication: validate every file, command, and parameter at the MCP server before execution.
Practical implication: enforce strict server-side validation on every parameter the model can pass into a tool.
Threat narrative
Attacker objective: The attacker wants the model to abuse trusted tooling so that secrets, files, or code changes can be reached without direct human approval.
- Entry occurs when an attacker introduces a malicious MCP server or crafts prompt content that causes the model to call an unsafe tool.
- Credential or context harvesting follows when the model is induced to request sensitive files, secrets, or privileged project data.
- Escalation happens if the MCP server accepts unsafe paths or tool arguments and performs actions outside the intended scope.
- Impact is unauthorised access, secret exposure, or malicious code and workflow manipulation inside development environments.
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
MCP makes context a security boundary, not a convenience layer. The protocol does not just connect models to tools, it moves trust decisions into the path where models decide what to call and what to read. That creates a new governance surface for IAM and NHI teams because tool access now behaves like delegated machine privilege. Practitioners should treat MCP context as an access control domain, not just prompt plumbing.
Untrusted tool metadata is the new supply-chain attack surface for agentic AI. The article correctly points to the parallel with malicious extensions and package installs, because the dangerous object is often the thing the model imports before it acts. This is where the identity of the tool matters: if the server cannot be authenticated, scoped, and pinned, the model inherits the wrong trust relationship. Practitioners should govern tool onboarding with the same rigor used for third-party integrations and secrets distribution.
Path validation is now an AI governance control, not only an application control. When a model can turn language into file access, unsafe path handling becomes a policy failure as much as a coding failure. That widens the accountability boundary for AppSec, platform security, and AI governance teams. Practitioners should move validation to the server edge and assume the model will eventually be persuaded to request something unsafe.
Context firewalling is a useful named control concept for MCP risk. Pinning tool descriptions, isolating execution, and limiting what the model can learn from context are all attempts to keep the model from treating malicious instructions as trusted state. This is especially relevant where the model interacts with code, secrets, or internal tooling. Practitioners should build controls that preserve context integrity before tool execution begins.
Agentic AI security will converge with NHI governance faster than many teams expect. Once models can use tools, every agent becomes a non-human actor with an access pattern, a scope, and an offboarding problem. That makes lifecycle control and least privilege central to AI adoption, not optional add-ons. Practitioners should align agent controls with NHI governance, not leave them stranded in separate AI experiments.
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: MCP Security Guide
What this signals
Context integrity is now a first-class control for AI-assisted development. MCP pushes security teams to think beyond static prompt safety and toward runtime trust in tool descriptions, paths, and delegated actions. The practical shift is from reviewing what the model said to governing what the model is allowed to reach.
Agentic AI creates a non-human identity problem even when the article is framed as tooling. Once a model can read files, open tickets, or modify code, it behaves like an actor with scoped access and a lifecycle. That means IAM, PAM, and NHI controls have to extend into developer copilots and internal automation before those paths become routine.
Secrets exposure will remain the easiest way to measure MCP risk in the wild. 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to the State of Secrets Sprawl 2026. Practitioners should assume that tool proliferation without governance turns configuration files into an attractive secrets reservoir.
For practitioners
- Implement an MCP allow-list Approve only known, vetted, and internally managed MCP servers, and block ad hoc connections from developer environments and runtime agents.
- Isolate MCP servers by privilege tier Run MCP servers in containers or serverless environments with no default permissions, then grant only the minimum filesystem and network access required.
- Validate every tool argument server-side Reject path traversal, unsafe file paths, and untrusted command parameters at the MCP boundary before the tool executes.
- Pin and monitor tool context Use context integrity controls such as first-use pinning for tool descriptions so a server cannot silently alter the instructions the model trusts.
- Insert security scans into AI-assisted development Have agents run code and secret checks before changes are saved so unsafe code paths and hardcoded secrets are found at creation time.
Key takeaways
- MCP changes the control problem by letting AI models act through tools, not just generate text.
- The main risks are context poisoning, unsafe file access, and supply-chain style abuse of trusted tool definitions.
- Teams need allow-listing, isolation, and server-side validation before agentic workflows are allowed to scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI 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 Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article shows how MCP workflows can expose secrets through unsafe tool access and context abuse. |
| NHI-04 — Insecure Authentication | Trust in unverified servers and tool metadata creates an authentication and provenance problem for agents. | |
| Recommendation — Scan MCP-connected environments for secret exposure paths and revoke any credentials reachable by tools. Authenticate MCP servers and pin trusted tool definitions before granting model access. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP-enabled agents can inherit and misuse access across tools, files, and development workflows. |
| Recommendation — Constrain agent privileges and review every delegated tool path for scope creep. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern centers on stealing secrets and moving through trusted development tooling. |
| Recommendation — Map MCP abuse to credential access and lateral movement so detections cover delegated tool chains. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is whether AI tools receive and retain only the access needed for the task. |
| Recommendation — Apply entitlement scoping to every MCP tool and remove excess access immediately. | ||
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.
- Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
- Container Firewall: A container firewall restricts communication to approved network paths based on application context. It helps security teams enforce segmentation inside dynamic environments where workload relationships change quickly, reducing unnecessary exposure and limiting lateral movement across containers.
- 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.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a shared control language for governing AI agents, service accounts, and other non-human actors.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org