MCP security turns AI connectors into a new enterprise control plane

At a glance

What this is: BigID argues that MCP turns AI connectors into a governed control plane, because the protocol expands both capability discovery and the security boundary around enterprise tools.

Why it matters: IAM, PAM, data governance, and AI security teams need to treat MCP hosts, clients, servers, tokens, and tools as one access path, because the protocol can turn model decisions into real enterprise actions.

Context

MCP standardises how AI applications reach tools, data, and services, but standardisation does not equal governance. The core problem is that a protocol layer can quickly become a control plane for access, action, and data movement if organisations do not define who or what is authorised to do each step.

For identity and security teams, the important change is that an AI workflow can now hold credentials, request context, and execute consequential actions through a shared protocol boundary. That makes the issue relevant to NHI governance, application access, and data protection at the same time.

This is not a niche integration concern. Once agents can discover tools and act through them, the security model has to cover the host, the server, the transport, the prompt path, and the downstream enterprise system as one chain.

Key questions

Q: What breaks when coding agents can reach tools and MCP servers without consistent governance and audit controls?

A: Without governance, teams lose visibility into which agents are using which tools, whether shadow IT is present, and what actions were taken. That creates audit gaps, weakens policy enforcement, and makes it harder to prove control over sensitive systems. The practical failure is unmanaged access, not just reduced convenience.

Q: Why do AI agents and MCP integrations increase IAM risk?

A: AI agents and MCP integrations increase IAM risk because they multiply the number of tool connections, service accounts, and tokens that can carry execution authority. If those credentials are embedded in configs or copied across workflows, the trust boundary moves into places that are hard to review. That makes least privilege and short-lived access much more important.

Q: What are the signs that an MCP deployment is being used unsafely by agents or downstream users?

A: Warning signs include unknown fields being accepted, risky write operations proceeding without approval, repeated retries creating duplicate actions, and tool calls reaching unexpected hosts or regions. You should also treat budget overruns, excessive concurrency, and missing audit spans as indicators that the control plane is not constraining behavior as intended. Those symptoms usually point to weak policy enforcement.

Q: How should identity teams govern MCP compared with conventional API integrations?

A: MCP needs runtime identity governance because it is not just a transport layer for requests. Conventional integrations can often be reviewed at design time, but agentic workflows require control over context, delegated authority, and the lifecycle of the credentials that power each tool path.

Technical breakdown

MCP host, client, and server trust boundaries

MCP uses a host-client-server model. The host coordinates the user experience, model, policy decisions, and exposed capabilities. Clients maintain connections to servers, while servers expose tools, resources, and prompts. The important security point is that each layer can widen the effective trust boundary if it accepts tool descriptions, server claims, or permissions too readily. In practice, this means the protocol does not secure itself. Security depends on whether the host constrains exposure, whether the client validates what it receives, and whether the server is treated like a production component rather than a plug-in.

Practical implication: define explicit trust and approval rules for every MCP host, client, and server before enabling production use.

Prompt injection, tool poisoning, and context poisoning

MCP-enabled agents do not just consume data, they can act on it. That creates a path for prompt injection when malicious content influences instructions, tool poisoning when a deceptive tool lures an agent into unsafe action, and context poisoning when a compromised knowledge source keeps shaping later decisions. These are distinct failure modes. Prompt injection is often single-use, tool poisoning targets selection, and context poisoning persists across sessions through shared memory or retrieval sources. All three exploit the fact that an agent may treat untrusted content as operational input unless the system separates instructions from data.

Practical implication: inspect retrieved content, verify tool metadata, and restrict who can modify persistent agent context.

Token audience, passthrough, and confused deputy risk

MCP can become an identity problem as much as an integration problem when tokens, scopes, and delegated actions are not tightly bounded. Token passthrough is especially dangerous because a server that forwards the same credential downstream can bypass the intended audience and blur audit boundaries. Confused deputy behaviour appears when a more privileged service acts for a less privileged requester without validating the requester’s authority. In both cases, the weakness is not the model itself but the delegation chain around it. The protocol therefore needs identity-aware controls, not just transport security.

Practical implication: issue separate downstream credentials, bind tokens to audience, and verify initiating-user authority for every privileged action.

Threat narrative

Attacker objective: The attacker wants to convert an AI connector into a trusted execution path for unauthorized access, data exposure, or harmful business actions.

1. Entry begins when an attacker influences an MCP workflow through a malicious prompt, compromised resource, poisoned tool definition, or weakly governed server connection.
2. Credential access follows when the agent or server uses broad permissions, forwarded tokens, or an over-privileged identity to reach data and tools it should not touch.
3. Impact occurs when the agent retrieves records, changes permissions, triggers workflows, or exfiltrates sensitive information with legitimate enterprise credentials.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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 identity governance for AI-driven action. Once agents can discover tools, request context, and invoke enterprise systems, the protocol becomes an access model, not just an integration standard. That means privilege design, entitlement scope, and approval boundaries matter as much as transport controls. Practitioners should treat MCP as part of the organisation's IAM and data governance fabric.

The new failure mode is control-plane expansion without lifecycle control. The article's most important warning is that hosts, clients, servers, tools, tokens, and prompts all participate in one operational chain. If any one of them is overexposed, the agent inherits more authority than the workflow intended. That is why the named concept here is AI connector control-plane drift: the gradual shift from bounded tool access to an implicit enterprise execution layer. Practitioners should audit that drift before it becomes normal.

Non-human identities now include the AI workflow that brokers access. The agent may not be autonomous in the full sense, but it still acts as a runtime identity that can inherit permissions, call tools, and move data. That makes MCP a natural fit for NHI governance, because the question is no longer whether an account exists, but whether the account, server, or token can safely carry delegated action. Practitioners should model agents, servers, and tokens as governed identities with explicit ownership.

Security teams should stop assuming that approved connectivity is safe connectivity. Standardisation reduces integration friction, but it can also hide dangerous defaults such as broad scopes, weak validation, and unbounded context flow. In governance terms, MCP makes latent risk easier to operationalise, which is exactly why the surrounding controls need to be stronger. Practitioners should require policy, monitoring, and revocation capability before any broad rollout.

MCP demands cross-domain oversight, not a point control. The relevant frameworks span NHI governance, AI risk management, and general security controls because the protocol touches identity, data, and action in one chain. The practical conclusion is simple: if teams govern only the model or only the transport, they will miss the real exposure surface. Practitioners should align MCP with identity, data, and AI control owners from the start.

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.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

AI connector control-plane drift: once tool discovery, context retrieval, and action execution are combined, the connector itself becomes part of the enterprise control plane. That means governance has to move upstream to approval, entitlement, and revocation, not just downstream to logging.

MCP also exposes a familiar identity lesson: standardisation makes delegation easier, which means it can make overreach easier too. If an organisation cannot answer who owns each server, which token it uses, and what data it can touch, the agent is already operating inside a weak trust model.

For practitioners

• Define an approved MCP server inventory List every host, server, tool, and connected identity that can participate in production AI workflows, then assign an owner and review cadence for each.
• Separate read and write capabilities Split retrieval, query, and modification functions so agents do not inherit broad combined access that can turn a harmless query into an operational change.
• Bind credentials to audience and service Use short-lived, audience-bound tokens and separate downstream credentials so a server cannot reuse one token across multiple services or scopes.
• Require approval for consequential actions Force human or policy confirmation before data deletion, permission changes, production code execution, or any workflow that can materially alter records or access.
• Instrument agent activity end to end Log which user initiated the request, which agent and server acted, which resources were retrieved, and what downstream systems changed, while excluding secrets from logs.

Key takeaways

• MCP shifts AI connectors from simple integrations into governed access paths that can read, modify, and trigger enterprise actions.
• The main risk is not the protocol alone, but the combination of broad permissions, untrusted context, and weak identity controls around hosts and servers.
• Teams need inventory, approval, token scoping, and end-to-end monitoring before MCP-enabled agents are allowed to operate 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.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners build the control model needed for delegated access, entitlement review, and lifecycle governance across AI-driven systems.