Ten MCP security risks that enterprise teams keep underestimating

At a glance

What this is: This is Willow's breakdown of ten MCP security risks, centred on how the protocol's missing native controls create exposure across authentication, credential handling, tool integrity, auditability, and server trust.

Why it matters: It matters because MCP is increasingly the access layer between AI agents and enterprise systems, so IAM teams must treat protocol governance, tool trust, and delegated access as one control problem.

By the numbers:

• Research shows 43% of MCP servers vulnerable to command injection.

Context

MCP is a protocol for connecting AI agents to enterprise tools, but in practice it also becomes an identity and authorisation boundary. When the protocol omits built-in authentication and pushes all security enforcement to implementers, teams inherit a governance gap before they even connect the first tool.

That gap matters because the article's risks are not isolated bugs. They show how tool schemas, runtime outputs, approval flows, credentials, and audit logs can all become part of the same access path when AI agents operate through delegated agent access and shared context.

Key questions

Q: What breaks when MCP deployments rely on the protocol for security boundaries?

A: The control boundary breaks first, because MCP does not supply native authentication or capability enforcement. Security then depends on every implementer building consistent controls around the protocol. That creates uneven trust, inconsistent logging, and access paths that are easy to misconfigure across different servers and teams.

Q: Why do insecure credential handling patterns persist in MCP environments?

A: They persist because the protocol gives teams no shared credential lifecycle model, so each server invents its own storage and passing method. In practice that pushes secrets into configuration files, environment variables, and local storage, where they are harder to govern, rotate, and revoke at scale.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should security teams respond when AI agents can change each other's configuration?

A: They should treat cross-agent writes as privileged actions and separate configuration stores by trust zone. When one agent can alter another agent's tools or server list, the issue is not convenience but delegation risk, so approval and integrity controls need to sit on the configuration path.

Technical breakdown

Why MCP's trust model fails without native authentication

MCP delegates security enforcement to the implementer, which means the protocol itself does not create a trustworthy access boundary. That design choice makes every deployment dependent on local policy, local storage, and local logging quality. In identity terms, the protocol assumes the surrounding environment will supply the controls that the protocol does not define. For enterprises, that means the security outcome varies by implementation rather than by standard. Once AI agents can invoke tools, send outputs onward, and inherit context across servers, the missing trust primitive becomes the core architectural issue. See the MCP Security Guide.

Practical implication: Treat MCP as an insecure control plane until authentication, authorisation, and audit requirements are explicitly wrapped around it.

How schema manipulation and tool output poisoning bypass static review

MCP attacks are not limited to visible tool descriptions. The article shows that parameter names, default values, type definitions, non-standard fields, and even tool outputs can steer model behaviour, which means the attack surface lives in structured data as much as in natural language. That matters because static scanners often inspect only the obvious fields and miss the machine-readable instructions embedded elsewhere. The result is a control failure where the model consumes untrusted schema or response content as if it were authoritative guidance. In practical terms, the tool interface becomes an input channel, not just an execution endpoint. Read OWASP Agentic Applications Top 10.

Practical implication: Validate every schema field and sanitize tool outputs before they reach model context.

Why insecure credential storage becomes systemic in MCP deployments

The article makes clear that MCP provides no credential management primitives, so each server invents its own handling pattern for tokens and keys. That produces inconsistent storage, world-readable files, and credentials exposed through environment variables or local configuration. The issue is not only leakage but lifecycle failure: credentials are created, stored, and reused without a central policy layer. In NHI terms, this is exactly where secrets management breaks down, because the same identity material is copied into multiple weakly governed places. The more servers a team adds, the more the credential estate fragments.

Practical implication: Move MCP credentials into managed secret storage and remove them from configuration files and process-visible environments.

Threat narrative

Attacker objective: The attacker wants to turn trusted MCP connectivity into unauthorized access to secrets, systems, or enterprise data while leaving minimal visible evidence.

1. Entry occurs when a malicious MCP server, poisoned tool output, or hostile link reaches the agent through a trusted integration path.
2. Credential access follows when the agent reads secrets from files, config stores, or exposed environment variables that were never meant to be broadly readable.
3. Escalation happens when modified tool definitions, shared context, or cross-agent configuration changes extend the attacker influence into other tools or agents.
4. Impact lands in data exfiltration, command execution, or unauthorized system actions that appear to originate from legitimate tool use.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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 introduces a governance failure before it introduces a technical one: the protocol delegates authentication and enforcement to implementers, so the trust boundary is external to the standard itself. That means two MCP deployments can behave radically differently even when they appear to use the same protocol. Enterprises should read this as an access governance problem, not just a protocol adoption question.

Credential leakage is not a side effect in MCP, it is a design pressure: when a protocol lacks native credential primitives, teams push tokens into config files, environment variables, and ad hoc local stores. That creates durable secret sprawl across servers, tools, and developer machines. The named concept here is credential governance debt: every local workaround increases the amount of identity material the organisation must later inventory, rotate, and revoke.

Schema and output channels collapse the old input validation model: MCP tools can steer model behaviour through fields that static review often overlooks, while runtime outputs can smuggle instructions into the agent's next action. That breaks the assumption that only visible prompts need scrutiny. The implication is that tool governance, not just application security, now sits inside the identity trust boundary.

Shadow MCP servers are the non-human identity version of shadow IT: individual developers can deploy connected servers outside approved governance, often with production access and no audit trail. That pattern matters because the server itself becomes a privileged machine identity with its own lifecycle and offboarding risk. Organisations need to treat server registration, approval, and retirement as part of the same control family.

The audit gap is the most dangerous signal in this entire category: if you cannot answer what tool was invoked, what data was read, and what triggered the action, then you do not have a governable MCP estate. Audit failure here is not a reporting issue, it is a containment issue, because the platform can erase the evidence needed to prove misuse. Practitioners should assume that unlogged MCP activity is already uncontrolled.

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.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

Identity blast radius: MCP turns a tool connection into a multi-identity trust chain, which means a single weak server can expose secrets, trigger tool misuse, and alter downstream agent behaviour. That is why the control point shifts from the prompt layer to the registration, approval, and revocation layer for connected systems.

MCP governance will increasingly look like NHI governance with agent-specific constraints layered on top. Teams that still treat each server as a simple integration will miss the fact that tool identity, credential identity, and agent identity now move together through the same runtime path.

Access reviews are a poor fit when the risky action happens inside a short-lived tool invocation rather than a stable account session. That is why MCP programmes need issuance-time controls, immutable logging, and policy checks before execution, not just periodic reviews after the fact.

For practitioners

• Define a central MCP authorisation policy Require a single policy layer for which agents, tools, and data sources may connect, rather than leaving each server to implement its own access rules.
• Block secrets from configuration files Move API keys and tokens into managed secret storage, and reject deployments that store credentials in world-readable config files or process-visible environment variables.
• Validate every tool schema field Scan parameter names, default values, type definitions, and non-standard fields, then remove anything that can influence model behaviour outside an approved contract.
• Separate agent configurations by trust zone Keep each agent's configuration isolated so a compromised agent cannot rewrite another agent's tool list or redirect its actions.
• Require immutable audit logging Log every prompt, tool invocation, and response to storage that cannot be altered by the agent or the server after the fact.

Key takeaways

• MCP's core risk is not one bug but a missing trust boundary, because the protocol leaves authentication, authorization, and audit enforcement to implementers.
• Credential sprawl, schema poisoning, and cross-agent privilege escalation show that MCP failures usually appear at the control-plane level before they show up as application bugs.
• Enterprise teams need central policy, isolated configurations, and immutable logging if they want MCP adoption without creating ungoverned machine access paths.

Related NHI Mgmt Group resources: MCP Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agents vs Agentic AI

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.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Shadow MCP Server: An MCP server that exists in an environment without being fully visible, approved, or governed by the teams responsible for identity and access. In practice, it becomes a hidden trust path for tools, data, and credentials, especially when developers install it directly into agent workflows.
• Cross-Agent Privilege Escalation: Cross-agent privilege escalation occurs when one AI agent gains influence over another and uses that relationship to bypass restrictions or obtain higher privileges. In multi-agent systems, weak isolation and shared trust can let agents free each other, coordinate unsafe actions, or extend access beyond intended boundaries.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.