MCP changes how AI agents reach tools, data, and risk

At a glance

What this is: MCP is the protocol that lets LLMs connect to external tools, and the key finding is that this shifts AI from text generation toward action execution.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern tool access, context trust, and privilege boundaries for AI systems that can act across applications and repositories.

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%).
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Semgrep's analysis of MCP security risks for AI agents

Context

MCP, or Model Context Protocol, matters because it converts an LLM from a conversational system into one that can invoke tools and interact with real environments. That changes the security question from model output quality to control over action, data access, and delegation boundaries. For identity teams, the primary issue is not the protocol itself but the way it expands the number of identities, secrets, and permissions an AI system can touch.

The article frames MCP as foundational infrastructure for agentic AI, which is the right lens for security review. Once a model can read files, create tickets, or trigger code changes, the relevant controls start to look like NHI governance, sandboxing, least privilege, and trust validation for tool descriptions. That is an emerging pattern, not yet a mature operating model.

Key questions

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Why do AI agents create accountability problems for IAM and NHI teams?

A: AI agents create accountability problems because traditional IAM proves who authenticated, while agent governance must prove what the actor did with that access. When the system can act, forget, and continue later, the organisation needs evidence across the whole task lifecycle. Identity controls alone do not show whether the action was justified or repeatable.

Q: How can organisations tell whether an MCP integration is safe to keep in production?

A: A safe MCP integration has a named owner, documented scopes, observable activity, and a working offboarding path. If any of those are missing, the integration is still experimental from a governance perspective, even if developers already rely on it.

Q: What is the difference between sandboxing an MCP server and trusting the model to behave safely?

A: Sandboxing limits what the server can reach if it is compromised. Trusting the model assumes the LLM will always interpret instructions correctly and stay within intent, which is not a control. The safer pattern is to combine isolation, least privilege, and explicit validation so the model never becomes the last line of defence.

Technical breakdown

How MCP turns a chatbot into an action-capable agent

MCP is a standard interface between an LLM and external tools, so the model can select and invoke capabilities beyond plain text generation. In practice, that means the model no longer just recommends an action, it can request file reads, issue API calls, or trigger workflow steps through connected servers. The security shift is that the model becomes a decision layer over executable interfaces. That creates a new control plane where tool choice, scope, and prompt context all influence what the system can do.

Practical implication: treat each MCP connection as a privileged integration and review the tools it can invoke before enabling it.

Why prompt injection becomes more dangerous in MCP environments

When an MCP server feeds descriptions or instructions into model context, malicious text can be interpreted as operational guidance rather than inert data. That creates a prompt-injection path where a compromised server, poisoned description, or malicious payload can steer the model toward unsafe actions. The article's example of a hidden instruction in a tool description shows why this is more than a text safety problem. It is an execution problem created by blurred boundaries between instructions, data, and control.

Practical implication: pin tool metadata, validate server provenance, and constrain what context the model is allowed to trust.

Why path traversal and tool abuse remain classic application security problems

The article's file-read example shows that MCP does not eliminate familiar application security flaws. If a trusted tool accepts unsanitised input, the model can become a delivery mechanism for path traversal, overbroad file access, or unintended command execution. The underlying issue is still parameter handling and authorization at the tool boundary. Security teams should read this as an application and identity governance problem, not just an AI safety issue, because the model is operating through existing access paths.

Practical implication: enforce path validation, server-side authorization, and isolated execution for every MCP-backed tool.

Threat narrative

Attacker objective: The attacker wants to steer an AI agent into disclosing sensitive data or performing unsafe actions through trusted tool channels.

1. Entry occurs when an attacker introduces a malicious MCP server, tampered tool description, or crafted prompt into the agent workflow.
2. Escalation happens when the model trusts the injected context and requests actions or data that exceed the user's intended scope.
3. Impact follows when the agent exposes files, credentials, or development assets, or triggers unsafe changes inside connected systems.

NHI Mgmt Group analysis

MCP creates a new identity and privilege boundary, not just a new integration pattern. Once an LLM can choose and call tools, the security question becomes who or what is authorised to act, under which context, and with which constraints. That moves MCP into the same governance territory as service accounts, delegated access, and privileged automation. The practical conclusion is that AI tool access must be modelled as a controlled identity surface, not a convenience feature.

The real risk is context trust, not protocol novelty. A malicious MCP server works because the model may treat tool descriptions as instructions, which collapses the distinction between metadata and control. That is a sharper version of a long-standing supply-chain problem, but now the compromise path reaches into runtime decision-making. Security teams should treat tool provenance, allow-listing, and context pinning as first-class controls, because the attack surface is defined by what the model is allowed to believe.

Agentic AI governance will converge with NHI governance faster than many programmes expect. The same control questions recur: credential scope, secret handling, session isolation, and auditability of action. The field needs a clearer named concept here: context-to-action drift, where the instructions supplied to a model gradually become executable authority. That drift is what makes MCP operationally risky, and it is why identity teams should be involved before agentic workflows scale.

Security teams should not respond by banning the protocol, but by constraining the operating model. The article is right that the technology is becoming foundational, which means organisations need guardrails rather than blanket rejection. The governance challenge is to decide which tools can be called, which data can be exposed, and how those decisions are recorded. That is an architecture and policy problem, and the teams that solve it early will shape how safe agentic AI becomes in practice.

What this signals

Context-to-action drift is the governance issue that MCP introduces into AI programmes. Once a model can turn instructions into tool use, the boundary between guidance and authority becomes unstable, which means security teams need to define where model context ends and enforced control begins. That is why allow-lists, context pinning, and server-side authorisation matter more than model intent.

The operational signal for practitioners is simple: if an AI workflow can reach code, files, or secrets without a separately enforced privilege model, it is already outside acceptable governance. OWASP Agentic Applications Top 10 helps frame the broader risk landscape, while identity teams should translate that risk into tool scoping, auditability, and bounded delegation.

MCP is likely to accelerate rather than slow the spread of agentic workflows, which means the question shifts from whether teams will adopt it to whether they will govern it before scale. Programmes that already manage secrets, workload identity, and privileged access have the right control vocabulary. The gap is adapting those controls to AI systems that decide which tools to call and when to call them.

For practitioners

• Implement allow-listing for MCP servers Approve only vetted internal or trusted external MCP servers, and require explicit review before any new tool is added to an AI workflow. Pair that with provenance checks so the model does not trust unauthorised tool definitions.
• Isolate every MCP tool in low-privilege execution Run MCP-backed services in containers or serverless functions with zero default permissions and narrow filesystem or API access. This limits the blast radius if a server, prompt, or tool definition is compromised.
• Pin tool context and validate instructions before execution Use context protection controls that lock tool descriptions after first trust and reject unexpected changes in server metadata. This reduces the risk of prompt injection through altered instructions or poisoned context.
• Treat AI file access like any other privileged integration Validate paths server-side, enforce authorisation at the tool boundary, and log every model-initiated request that touches source code, secrets, or sensitive directories. The model should never be the enforcement layer.

Key takeaways

• MCP turns AI from a conversational interface into an action layer, which makes identity, privilege, and context control the core security issues.
• Tool trust is now a supply-chain and runtime problem at once, especially when context can be manipulated or misread by the model.
• Teams should govern MCP with allow-lists, sandboxing, and server-side validation before agentic AI workflows become normal production behaviour.

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 Injection: A failure mode where malicious or misleading content enters an agent's decision path and affects what it does next. In MCP environments, the injected context can alter tool selection, broaden data exposure, or trigger unsafe follow-on actions across multiple systems.
• Tool Allow List: A tool allow list defines which external tools, APIs, or actions an agent is permitted to reach. It limits the agent’s operational scope before execution and is a key control for reducing blast radius when a model or workflow is misconfigured.
• Identity-To-Action Drift: The gap between an identity that appears legitimate and the actual actions performed under that identity. In agentic environments, drift can happen within a single session, which means authentication alone does not prove safe execution or bounded intent.

What's in the full article

Semgrep's full post covers the operational detail this analysis intentionally leaves for the source:

• Implementation detail for allow-listing MCP servers and deciding which internal tools qualify for trust.
• Examples of running MCP services in isolated environments with low or zero default permissions.
• Practical context-protection ideas for pinning tool descriptions and resisting prompt injection.
• Semgrep's own use case for wiring MCP into developer security workflows before code is saved.

👉 Semgrep's full post covers the MCP attack paths, allow-listing approach, and security workflow example.

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 in the contexts that matter to security teams. It helps practitioners connect identity controls to the broader access and delegation problems created by agentic AI.