MCP security exposes the governance gap in AI agent access

At a glance

What this is: Cyberhaven argues that MCP security is now an identity and data governance problem because AI agents are using runtime connections to reach enterprise systems with broad, poorly observed access.

Why it matters: IAM, IGA, PAM, and data security teams need to govern MCP as a live integration surface, because agent access decisions, credentials, and tool outputs create risk that perimeter controls and static reviews miss.

Context

MCP security is the governance problem that appears when AI agents connect at runtime to enterprise tools, data sources, and services through Model Context Protocol. The issue is not merely that agents can reach more systems, but that they do so with permissions, tool choices, and data flows that traditional IAM reviews were never designed to observe.

Cyberhaven's analysis frames this as a live control gap across NHI governance, secrets management, and data security. When an agent can decide which tool to call, what data to retrieve, and when to act, static approval models and perimeter-only monitoring stop matching the way access is actually exercised.

The practical question for security leaders is whether MCP connections are being governed as identities, as data pathways, or as unreviewed convenience plumbing. In most environments, they are all three at once, which is why inventory, scope control, and telemetry become inseparable.

Key questions

Q: What breaks when AI agents use MCP without strong scope enforcement?

A: Least privilege breaks in practice because the agent can execute far more than the business task requires. When tool permissions are broad, the difference between legitimate use and abuse becomes narrow, and a normal workflow can become a data exposure or unauthorized action path without any obvious boundary crossing.

Q: Why do MCP integrations create so much operational risk?

A: They create risk because the protocol connects runtime agent decisions directly to enterprise systems, often through broad tokens, weak logging, and unreviewed server permissions. That combination raises the chance of data exposure, prompt injection, and unauthorised actions. The more tools an agent can call, the more important runtime governance becomes than static policy.

Q: What are the warning signs that an MCP deployment is overexposing enterprise tools?

A: Warning signs include overly broad tool discovery, agents reaching adjacent data without a fresh policy check, and responses being reused after user permissions change. Those symptoms show the protocol is enabling reach faster than the governance model can constrain it.

Q: How should teams respond when an MCP session can reach production systems?

A: Treat it as a session-governance problem, not a normal permissions review. Require task-scoped access, runtime policy for dangerous sequences, and correlated logging before deployment. If the session can read source code and trigger production changes, the authorisation boundary is too broad for safe autonomous use.

Technical breakdown

Why MCP turns AI agents into runtime access brokers

MCP exposes tools and resources through a structured protocol that lets an AI agent request access at runtime, then receive data or trigger actions based on the current prompt and context. That means the access path is not fixed at provisioning time. Instead, the agent selects from available tools inside the session, which is why MCP changes the governance problem from static entitlement review to live runtime authorisation. In identity terms, the control boundary shifts from who is allowed to have access to what the system is allowed to ask for on behalf of the agent. Practical implication: treat each MCP server as an identity-mediated access broker, not just an integration endpoint.

Practical implication: map every MCP server to the exact tools and data it can broker, then constrain that set to the minimum runtime scope.

How prompt injection and tool poisoning exploit MCP tool calls

MCP tool responses can return external content that is then placed directly into the model's context window. If that content contains hidden instructions, an attacker can steer the agent through indirect prompt injection. Tool poisoning is the related failure mode where the server misrepresents what a tool does, so the model believes a safe description while the underlying action is risky. In both cases, the agent is not being hacked in the traditional sense. The trust boundary is being abused through the tool-response channel itself. Practical implication: inspect and sanitise tool outputs before they re-enter the model context, especially for systems that can write, delete, or transmit data.

Practical implication: validate MCP outputs before they reach the LLM, and block any tool path that can alter or export sensitive data without review.

Why MCP credentials become high-risk secrets when they are stored like config

Most deployed MCP implementations still rely on API keys or OAuth tokens that sit in configuration files, environment variables, or shared deployment settings. That creates a familiar but dangerous pattern: credentials are broad, durable, and often detached from the specific agent identity that should hold them. Once a runtime or server is compromised, those credentials can be reused at scale. The problem is not merely leakage. It is that the authentication model is usually weaker than the access model it is supposed to protect. Practical implication: move MCP credentials into governed secrets management, bind them to specific agent identities, and rotate them on a defined schedule.

Practical implication: inventory MCP credentials as secrets, not configuration, and revoke any token that is shared across environments or lacks a clear owner.

Threat narrative

Attacker objective: The attacker wants to steer the agentic workflow into accessing or exporting data and actions the business never explicitly authorised.

1. Entry occurs when an AI agent is connected to enterprise systems through an MCP server with broad or unsanctioned permissions.
2. Credential access follows when API keys or OAuth tokens stored in configuration files or environment variables are reused across environments or exposed to the runtime.
3. Escalation and misuse occur when indirect prompt injection or tool poisoning steers the agent into reading, modifying, or exporting data beyond the intended task.
4. Impact is realised when sensitive enterprise data is exfiltrated, records are altered, or a shadow integration remains in production without inventory or review.

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.

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 security is really governance of delegated runtime access, not just API protection. The central failure is that AI agents decide which tools to call after the session starts, so classic pre-approved entitlement models stop describing actual behaviour. That means MCP belongs inside identity governance, secrets governance, and data governance at once. Practitioners need to stop treating it as an integration convenience and start treating it as a governed access plane.

Least privilege becomes much harder to define when the identity making the decision is dynamic. A human user can be reviewed against a role, but an agent can assemble tool use from context, prompt, and retrieved data in real time. That collapses the assumption that scope can be set once and then audited later. The implication is that entitlement review without runtime telemetry will miss the real control boundary.

Shadow MCP creates the same governance debt that shadow IT created, but with faster privilege accumulation. Unsanctioned servers can be stood up in minutes, often before security ever sees an inventory record. The named concept here is runtime governance gap: a state where the organisation can describe policy but cannot observe or constrain the live access path. Practitioners should recognise that the gap is architectural, not just procedural.

Credential storage is now an identity design issue because the bearer token outlives the intended decision context. MCP deployments commonly couple broad tokens to durable server configurations, which makes revocation and ownership ambiguous. The problem is not merely stale secrets. It is that the identity carrying the authority is often invisible to the teams responsible for access lifecycle. Security leaders need to reframe this as lifecycle control over machine-held authority, not just secret hygiene.

Data security controls must move closer to the model interaction layer if they are to remain effective. Traditional DLP sees the boundary where data leaves the environment, but MCP places important decisions before that boundary inside the agent workflow. That makes lineage, output validation, and logging necessary for auditability. The practical conclusion is simple: if the organisation cannot see the tool call, it cannot reliably govern the data flow.

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.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Runtime governance gap: MCP makes the access path dynamic, which means policy that only exists at provisioning time cannot see or control the decision actually made inside the session. Security teams should expect identity reviews to miss agent-driven behaviour unless they add tool-call telemetry and ownership data.

MCP also shifts the centre of gravity for secrets risk. When API keys and OAuth tokens are attached to long-lived integrations, the control problem becomes lifecycle, not just storage, and the inventory of those credentials becomes as important as the systems they unlock. According to the State of Secrets Sprawl 2026, 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

For practitioners

• Establish a complete MCP inventory Record every MCP server, owner, connected system, permission scope, and approval status before any further expansion. Treat unsanctioned servers as governance defects, not informal productivity shortcuts.
• Constrain every MCP server to minimum tool scope Review each tool and resource exposed to an agent and remove write, delete, export, or broad read access unless the business function truly requires it. Default to read-only access and require documented justification for exceptions.
• Move MCP credentials into managed secrets Store API keys and OAuth tokens in a secrets management system, bind them to specific agent identities, and rotate them on a defined schedule. Audit for shared credentials and any token hardcoded in config or environment variables.
• Validate tool outputs before they re-enter the model Apply content inspection and allow-listing to MCP responses so instruction-like payloads cannot steer the agent through indirect prompt injection. Block or flag outputs that attempt to redirect tool choice or trigger sensitive actions.
• Log tool calls as identity events Capture which agent invoked which tool, what data was returned, and what action followed, then feed that telemetry into SIEM and data security monitoring. Use it to detect anomalous volume, unusual tools, or out-of-pattern access.

Key takeaways

• MCP security is an identity governance problem because AI agents are choosing tools and data sources at runtime, outside the scope of many traditional access reviews.
• Broad permissions, weak logging, and unmanaged credentials make MCP integrations hard to see and harder to contain once they are live in production.
• The most effective controls are inventory, least-privilege scoping, secrets governance, output validation, and telemetry that records each agent tool call.

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.
• 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.
• Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.