MCP security turns AI connectors into a new enterprise control plane

At a glance

What this is: This is an analysis of Model Context Protocol security and the key finding that standardised AI connectivity expands the attack surface unless hosts, servers, tokens, tools, and agent actions are governed end to end.

Why it matters: It matters because MCP-enabled agents can act with enterprise credentials, so IAM, PAM, NHI, and AI governance teams must control what those agents can see, invoke, and change before autonomy becomes operational risk.

👉 Read BigID's analysis of MCP security and enterprise AI connectivity

Context

Model Context Protocol is a standard way for AI applications to connect to tools, data sources, and enterprise services, but standardisation does not equal security. In practice, MCP shifts the problem from simple data retrieval to governed action, because an agent may read records, call APIs, trigger workflows, or modify systems using inherited access.

The identity issue is the same one that underpins broader NHI governance: every agent, server, token, and tool becomes a non-human identity boundary that must be inventoried and constrained. BigID’s analysis is a strong example of a wider pattern, not an isolated product concern.

The protocol becomes risky when organisations treat servers like lightweight plugins instead of production components. That mindset leaves gaps in authentication, scope control, approval logic, and auditability, which is exactly where agentic systems need stronger governance.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do chained MCP workflows create extra identity risk?

A: Chained workflows multiply trust boundaries because each MCP server may forward the request to another server. If the originating identity is not preserved, downstream authorization loses context and may overgrant access or reject valid work. Identity propagation is essential so every hop can evaluate origin and scope.

Q: What do organisations get wrong about MCP security?

A: They often focus on network isolation or prompt filtering and miss the real issue: an authorised workload can still perform an unintended action. MCP security fails when teams trust transport and service authentication to answer an authorization question that only the request context can resolve.

Q: Who should approve high-risk actions in agentic workflows?

A: The approval model should be tied to the action, not to the existence of the agent. High-risk, destructive, or cross-environment actions need explicit human approval before execution, even when the surrounding workflow is automated. That keeps delegated authority from becoming unchecked execution authority.

Technical breakdown

How MCP host-client-server trust breaks down

MCP uses a host-client-server model. The host coordinates the user experience and policy decisions, clients maintain sessions, and servers expose tools, prompts, and resources. The security problem is that each layer can expand authority if trust is assumed rather than verified. A permissive host can expose too many tools, a weak client can pass unsafe responses into the model, and a compromised server can shape behaviour or exfiltrate data. Because the protocol standardises capability discovery, the control question becomes who is allowed to connect, what each connection can do, and how those permissions are enforced over time.

Practical implication: inventory every host, client, server, and connected tool as governed assets, not informal integrations.

Why token passthrough and audience validation matter

A key MCP failure mode is token passthrough, where a server forwards a client token to another service instead of obtaining a separate audience-bound credential. That breaks the security boundary because downstream systems no longer know which service is actually calling them, and monitoring, rate limits, and audit trails become unreliable. The protocol guidance explicitly pushes toward tokens that are short-lived, securely stored, and bound to the intended audience. In identity terms, this is about preserving the integrity of each service-to-service trust relationship rather than collapsing multiple hops into one credential chain.

Practical implication: issue distinct downstream credentials for each service and block any design that reuses a single bearer token across hops.

Prompt injection becomes executable when tools are connected

MCP changes prompt injection from a text problem into an action problem. If untrusted content arrives through a document, database record, server response, or web resource, the model can treat it as instruction rather than data and then execute tool calls on that basis. The risk increases when tools can change records, send messages, or launch workflows, because malicious context can drive consequential actions with legitimate access. This is why tool validation, output sanitisation, approval gating, and provenance checks are core controls, not optional hardening steps.

Practical implication: inspect retrieved content before execution and require human or policy approval for high-impact tool actions.

Threat narrative

Attacker objective: The objective is to turn trusted AI connectivity into unauthorised action using legitimate credentials and workflow authority.

1. Entry occurs when an attacker injects malicious content into a resource, server, or tool response that an MCP-enabled agent later retrieves as context.
2. Escalation happens when the host or client trusts that context and allows the agent to invoke tools or reuse credentials beyond the original task scope.
3. Impact follows when the agent uses legitimate enterprise access to read sensitive records, modify systems, or trigger downstream actions on behalf of the requester.

NHI Mgmt Group analysis

Standardised AI connectivity creates governance debt if identity controls lag behind protocol adoption. MCP reduces integration friction, but it also multiplies the number of entities that can act on enterprise data. That means hosts, clients, servers, prompts, tools, and tokens all need explicit ownership and policy boundaries. For identity teams, MCP is not just an AI integration pattern, it is a new class of non-human identity estate that must be managed like production access.

Token boundary failure is the most misunderstood MCP risk. When a server reuses a client credential downstream, the organisation loses the ability to prove who actually authorised the action and which service consumed the privilege. This is a classic trust-collapse pattern in machine identity governance, and it is where least privilege, audience binding, and separate downstream credentials matter most.

Prompt injection becomes a governance issue only when organisations let untrusted context become executable context. The protocol itself can move data and instructions efficiently, but that efficiency is dangerous if retrieved content can steer high-impact tool use without validation. Practitioners should treat tool outputs, server metadata, and retrieved resources as untrusted inputs until they are checked, because the control gap is instruction provenance, not model intelligence.

MCP security will converge with agentic AI governance, not sit beside it. As more copilots and autonomous workflows use the same tool layer, the market will move toward unified control of access, approvals, lineage, and audit across agents and humans alike. The organisations that separate AI governance from identity governance will struggle to answer basic questions about who or what changed a system and why.

Named concept: AI connectivity control plane. MCP is pushing enterprises toward a control plane where identity, data access, tool permissioning, and runtime oversight must be governed together. That concept will matter increasingly for security architecture reviews, because the real risk is not the protocol alone but the operational authority it concentrates in one place. Practitioners should plan for unified policy enforcement across the entire agent path.

What this signals

AI connectivity is becoming an identity governance problem before it becomes a platform problem. MCP pushes enterprises toward one operational question: which non-human identities are allowed to connect context to action? If that question is not answered centrally, teams will accumulate disconnected approvals, inconsistent scopes, and audit gaps across agents, tools, and data paths.

Audience-bound credentials and approval boundaries will matter more than protocol adoption speed. The protocol can standardise integration, but it cannot decide which actions deserve trust. Practitioners should expect more scrutiny on token design, tool permissions, and runtime approvals as agentic workflows move from pilots into production.

Control-plane thinking is the next step for agent governance. The enterprises that succeed will not just list approved servers, they will connect identity lifecycle, data classification, and action-level policy into one oversight model. That is how MCP moves from a technical interface to a governable operating surface.

For practitioners

• Map every MCP-connected non-human identity Inventory hosts, clients, servers, tools, prompts, credentials, and data sources as separately governed assets. Record ownership, business purpose, permission scope, and the systems each identity can change.
• Eliminate token passthrough across MCP workflows Require audience-bound tokens for each downstream service and block any design that forwards a bearer token unchanged. Separate authentication for the MCP server from authentication to the target API.
• Treat retrieved context as untrusted input Validate provenance for resources, server responses, and tool metadata before the model can act on them. Add content inspection, output sanitisation, and approval gates for destructive or high-impact operations.
• Restrict high-impact tool use to approved paths Require policy or human approval before deleting data, changing permissions, transferring sensitive records, or executing production actions. Keep those tool calls in a monitored path with complete audit logging.
• Build an approved server and tool inventory Approve MCP servers like production components, not plug-ins. Review publisher identity, dependencies, network behaviour, update process, and the permissions each tool exposes before enabling it.

Key takeaways

• MCP expands AI from text generation into governed action, which makes identity and access controls central to its security model.
• The biggest risks are not abstract. They are excessive permissions, token misuse, prompt injection, malicious servers, and weak auditability.
• Organisations need inventory, approval, audience-bound credentials, and runtime monitoring before agentic workflows can be trusted at scale.

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.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.

What's in the full article

BigID's full article covers the operational detail this post intentionally leaves for the source:

• A breakdown of MCP host, client, and server responsibilities in enterprise deployments.
• Specific mitigation patterns for prompt injection, tool poisoning, and token passthrough.
• Guidance on governed access, role-based controls, and data policy enforcement for AI workflows.
• Examples of how BigID applies its data governance controls to MCP-enabled use cases.

👉 The full BigID article covers MCP attack patterns, control boundaries, and mitigation details for practitioners.

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 helps practitioners align access, oversight, and lifecycle controls across human and non-human identities.