MCP security exposes the governance gap in AI agent access

At a glance

What this is: MCP security is the set of controls needed to govern AI agents that connect to enterprise tools, with the key finding that most environments have broad access, weak logging, and limited visibility.

Why it matters: IAM and security teams need to treat MCP as an identity and access problem because AI agents can reach sensitive systems through runtime connections that bypass traditional review, monitoring, and least-privilege assumptions.

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 Cyberhaven's MCP security guidance for AI agent integrations

Context

MCP security is the control problem created when AI agents connect directly to enterprise tools, data sources, and services at runtime. In practice, that means an agent can discover, retrieve, and act on information in ways that were never reviewed through normal IAM or data governance processes, which makes MCP security a primary concern for AI agent identity governance.

The issue is not that integrations exist. The issue is that the integration layer now sits inside the decision path of a runtime actor that can choose tools, pull data, and trigger actions without the visibility controls teams expect from human-driven access patterns. That is a different governance problem from standard API security, and it is already showing up as shadow AI, scope creep, and weak auditability.

For most enterprises, the starting position is atypical only in degree, not in kind: the same control gaps have existed around OAuth apps, service accounts, and secrets, but MCP compresses those risks into faster, more dynamic agent workflows.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP-based agents create more risk than ordinary API integrations?

A: Because the agent is choosing actions, chaining tools, and preserving context across steps. Ordinary API controls assume predictable request patterns, while MCP can turn one legitimate session into a route for data exposure or privilege escalation. The risk increases when identity, context, and tool access are not governed together.

Q: What do teams get wrong about prompt injection in MCP environments?

A: Teams often treat prompt injection as a content problem when it is also an identity problem. If the server will act on manipulated instructions without verifying who initiated the request and what authority it should have, the injection becomes a path to real execution, not just model confusion.

Q: Who should be accountable for MCP server permissions and agent actions?

A: Accountability should sit with the business or platform owner that approved the data path, plus the security team that set the guardrails. If the agent can access regulated data or take sensitive actions, the organisation needs a clear owner for the server, the credentials, and the downstream consequences of misuse.

Technical breakdown

How MCP tool calls become an identity and access path

MCP defines a structured way for an AI model to request tools and resources from an external server. The server exposes callable tools and readable resources, and the agent decides at runtime which one to use. That makes the access path dynamic rather than pre-scripted. In identity terms, the agent is not just consuming data, it is exercising permissions through an integration layer that often sits outside normal entitlement review. If the server is granted broad access, the model inherits that reach in the moment of execution.

Practical implication: treat every MCP server as an access-bearing identity boundary, not a convenience connector.

Why indirect prompt injection is an MCP security problem

Indirect prompt injection happens when untrusted content returned by a tool carries instructions that alter the agent's behaviour. Because the content enters the LLM context window, the agent may follow attacker-written instructions embedded in a document, ticket, or web page. The security issue is not just malicious content, but the trust boundary collapse between retrieved data and model execution. Once the model treats retrieved content as actionable guidance, the attacker can shape downstream tool use, data exposure, or workflow actions.

Practical implication: validate and sanitise tool output before it re-enters the agent context.

Why MCP credentials need secrets governance

Most deployed MCP implementations rely on API keys or OAuth tokens stored in configuration files or environment variables. Those credentials are often shared, rarely rotated, and not bound tightly to a single agent identity. That creates a long-lived secret exposure pattern that is familiar from NHI failures, but worse in agentic workflows because the token can be used at runtime by a system that continuously chooses actions. The result is not just credential theft, but credential-driven operational abuse at scale.

Practical implication: move MCP tokens into a secrets management system and rotate them on a defined schedule.

Threat narrative

Attacker objective: The attacker wants to use the agentic integration path to reach sensitive data or execute unauthorised actions through trusted tooling.

1. Entry occurs when a developer, employee, or vendor-enabled workflow connects an AI agent to an MCP server with broad access to files, databases, or SaaS tools.
2. Escalation follows when the agent is given credentials or permissions that exceed the task, allowing runtime tool use across systems no human individually reviewed.
3. Impact is reached when the agent retrieves sensitive data, transmits it through a model response or external action, and leaves only partial or missing audit evidence.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is really identity governance for runtime tool use. The important shift is that permissions are no longer only assigned to humans, service accounts, or apps. They are now exercised by an AI agent making decisions at execution time, which means identity policy has moved into the control plane of the model workflow. Practitioners should stop treating MCP as just another integration standard and start treating it as governed access.

Runtime autonomy breaks the least-privilege assumption at provisioning time. Least privilege works when the actor's intent is known before the session begins. With MCP-connected agents, tool choice happens mid-session, which means the access needed can expand after the task starts. That is a structural governance problem, not just a configuration mistake. The implication is that static entitlement design no longer describes actual exposure.

Shadow MCP is the new shadow IT. If developers can stand up servers and connect agents without review, then access inventories and recertification cycles will miss the real control point. The gap is not only visibility into the server, but also who authorised the data path, what the agent can do, and whether those permissions still match the original business purpose. Practitioners need inventory discipline before policy can work.

Tool poisoning turns the trust model inside out. MCP server metadata is meant to help the model decide which tool to invoke, but a compromised or deceptive server can misstate its purpose and shape downstream behaviour. That means the thing being trusted is not just the connection, it is the description of the connection. Security teams should recognise this as a governance failure in the integration catalog, not a narrow content filtering problem.

From our research:

• 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%), according to AI Agents: The New Attack Surface report.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to the same report.
• For a broader view of how agentic risk is being modelled, see OWASP Agentic Applications Top 10 and how it maps emerging agent behaviour to security controls.

What this signals

MCP trust debt: teams that spin up agent integrations faster than they inventory them are accumulating an access layer they cannot explain later. With only 18% of MCP server deployments implementing any form of access scoping for tool permissions, the practical question is not whether risk exists, but whether governance can still catch up before the integration footprint becomes normalised.

The reader should expect MCP security to converge with broader AI governance and NHI programmes, especially where secrets, tool permissions, and audit trails meet. If the organisation is already struggling to track where AI systems can read data, the control gap will widen unless MCP activity is pulled into the same lifecycle, monitoring, and review disciplines used for other privileged identities.

For practitioners

• Build a complete MCP server inventory Record every MCP server, the agent or user that relies on it, the resources it reaches, and the business owner who approved it. Without that inventory, permission review and incident response will remain incomplete.
• Apply least-privilege scoping to every tool and resource Restrict each server to the minimum read, write, export, or delete rights needed for its stated function. Use read-only by default and require explicit approval for sensitive actions.
• Move MCP credentials into secrets management Store API keys and OAuth tokens in a secrets management system, rotate them on a defined schedule, and bind them to the narrowest feasible agent identity. Do not leave them in config files or shared environments.
• Log agent tool calls as security events Capture which agent invoked which tool, what data was returned, and what action followed. Feed those events into SIEM or data monitoring so misuse and prompt injection leave an audit trail.
• Validate tool output before it reaches the model context Inspect retrieved content for instruction-like patterns, override language, or prompt syntax before it re-enters the LLM context window. Treat tool output as untrusted input until it is cleaned.

Key takeaways

• MCP creates a new access layer where AI agents can reach enterprise data and tools at runtime, often outside existing IAM review paths.
• The main failure modes are overly broad permissions, indirect prompt injection, weak credential handling, and poor visibility into tool calls.
• Practitioners should inventory servers, scope access tightly, log activity, and treat MCP credentials and outputs as governed security inputs.

Key terms

• Model Context Protocol: An open protocol that lets AI agents connect to tools and data sources through a structured interface. In security terms, it is an access path that can carry sensitive permissions, runtime decisions, and data movement into the model workflow, so it must be governed like any other privileged integration.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• 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.
• 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.

What's in the full article

Cyberhaven's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for inventorying MCP servers across development and production environments
• Practical examples of least-privilege scoping for read, write, export, and delete tool permissions
• Detailed logging and monitoring guidance for feeding MCP tool calls into SIEM and data security workflows
• Operational advice on managing MCP API keys and OAuth tokens as secrets rather than configuration values

👉 Cyberhaven's full post covers MCP threat scenarios, mitigation steps, and the AI-layer data lineage angle.

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 or identity security programme, it is worth exploring.