TL;DR: Model Context Protocol gives AI agents a standard way to reach enterprise tools and data, but it also creates new exposure across identity, authorization, prompt integrity, and shadow infrastructure, according to Salt. The governance gap is now the lack of visibility and control around agent-to-tool connectivity, not the protocol itself.
At a glance
What this is: Salt argues that Model Context Protocol is becoming the control layer for agent-to-tool access, while governance, authorization, and visibility controls are still catching up.
Why it matters: For IAM, NHI, and autonomous workflow teams, MCP turns agent connectivity into a first-class governance problem because every tool call can inherit identity, privilege, and trust failures from the systems it bridges.
Context
Model Context Protocol is a standardized way for AI systems to discover and interact with external tools, data sources, and business systems. In practice, it turns AI agents into active participants in enterprise workflows, which means identity, authorization, and audit assumptions now extend to agent-to-tool connectivity.
The governance gap appears because MCP adds a new control layer without automatically enforcing authentication, role boundaries, prompt integrity, or tool approval. That leaves security teams with a growing class of shadow infrastructure where access can expand faster than inventory, review, or sanctioning processes can keep up.
For NHI and agentic AI programmes, the issue is not whether MCP is useful. The issue is whether organisations can govern a shared protocol that lets an agent discover tools, inherit permissions, and trigger actions across multiple downstream systems.
Key questions
Q: What breaks when MCP server discovery is missing from security controls?
A: Without MCP discovery, security teams cannot see which tools an agent can reach or what those tools are allowed to do. That creates hidden privilege expansion, especially when local stdio servers bypass network-only inspection. The result is incomplete policy enforcement and a much larger effective attack surface for the agent.
Q: Why do MCP servers increase risk when tool permissions are too broad?
A: MCP servers can expand risk because they sit between an AI client and sensitive backends, often with enough reach to query data, trigger workflows, or modify records. If permissions are broad, a compromised or misbehaving agent can move from one tool to another with little friction. Least privilege and scoped discovery reduce that blast radius.
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: What is the difference between API security and MCP security?
A: API security focuses on protecting known endpoints and request boundaries. MCP security must also govern the agent’s state, the context it carries, and the sequence of tool actions it can trigger. In practice, that means moving from endpoint-centric controls to workflow-centric access policy and continuous enforcement.
Technical breakdown
How MCP creates a new trust boundary for agentic systems
MCP uses a client-server model in which an AI host runs clients that connect to servers exposing tools, resources, and prompts. That is more than a transport layer. It is a structured trust boundary where the model can discover capabilities, choose a tool, and then pass context into an execution path that touches repositories, databases, APIs, or workflow engines. The security problem is that the protocol standardizes connectivity faster than it standardizes governance. Without strict policy enforcement, the server becomes a privileged intermediary rather than a simple integration point.
Practical implication: Treat every MCP server as production connectivity infrastructure, not as a convenience layer.
Why tool poisoning and prompt injection matter in MCP
Tool poisoning happens when a malicious or compromised MCP server hides instructions in tool descriptions, metadata, prompts, or outputs. Prompt injection is adjacent: untrusted content influences the agent’s reasoning and causes unintended actions. These are not classic API failures because the agent interprets context before acting. In MCP, that means the trust problem is not limited to data authenticity. It extends to how tool output is presented, how instructions are serialized, and whether the agent can distinguish operational content from embedded control signals.
Practical implication: Sanitize tool outputs and treat all server-supplied context as untrusted input.
Where bearer tokens and delegated permissions become fragile
Many MCP deployments rely on bearer tokens, delegated permissions, OAuth flows, or token passthrough. That creates a familiar but sharper identity problem: once a token is broad, long-lived, or weakly scoped, the agent can carry authority into every downstream system it touches. The article’s governance point is that access is no longer held in one place. It is distributed across the agent, client, server, and target system. This is where confused deputy risk appears, because a trusted component may exercise authority on behalf of a user in ways the user did not intend.
Practical implication: Bind token scope and authorization checks to the user, agent, client, server, and requested action.
Threat narrative
Attacker objective: The attacker aims to use the trusted agent-to-tool pathway to read, leak, or alter sensitive enterprise data and actions without clear user intent or sufficient controls.
- Entry begins when an AI host connects to an MCP server that exposes tools, resources, or prompts to an agentic workflow.
- Credential access or abuse occurs when delegated permissions, bearer tokens, or broad scopes let the agent reach repositories, APIs, databases, or workflow systems.
- Escalation follows when poisoned tool output, weak authorization, or confused deputy behaviour causes unintended actions across downstream systems.
- Impact is the exposure, modification, or exfiltration of enterprise data and actions through a trusted AI connectivity path.
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.
- 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 is not just another integration pattern, it is a governance layer for agentic access. Once an AI system can discover tools and execute actions through a shared protocol, the question changes from connectivity to authority. The relevant control plane is no longer only API security or IAM in isolation. It is the combined governance of agent, client, server, and downstream resource, which means identity teams must treat MCP as a first-class part of the access model.
Prompt integrity becomes an identity control problem when the agent is the decision-maker. Tool descriptions, metadata, and outputs can shape behaviour in ways traditional authorization checks do not see. That means the attack surface is no longer confined to what the server returns. It includes what the agent believes the server means, so security teams need to rethink where trust is established and where it is consumed.
Shadow MCP server inventory is the new shadow API problem, but with delegated action attached. Untracked servers can expose data, trigger workflows, and connect to privileged systems without the kind of formal review that enterprises expect for production assets. The named concept here is agent-to-tool governance gap: the distance between discovering an MCP server and proving it is authorized, bounded, and observable. Practitioners should assume that gap is already widening.
Static credential and long-lived delegation assumptions are being stretched by agentic workflows. MCP deployments often inherit token models that were built for predictable service access, not dynamic tool selection and context-driven execution. That breaks the assumption that a permission granted at setup time still accurately represents the action taken at runtime. The implication is that entitlement governance must shift toward per-action control, not just per-connection approval.
Security teams that separate MCP from the systems it reaches will miss the real exposure path. The protocol is only one hop in a longer chain that includes repositories, databases, cloud accounts, and workflow engines. The practical conclusion is that MCP governance has to be measured by the downstream authority it can activate, not by whether the server itself looks isolated.
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.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Top 10 Agentic AI Identity Issues
What this signals
Agent-to-tool governance gap: MCP creates a control problem that sits between inventory and authorization, and that gap widens every time developers add a new server without a sanctioning workflow. Security teams need continuous discovery, not periodic audits, because the real exposure is the authority each server can activate.
Access reviews alone will not govern MCP well if servers can change tool exposure faster than certifying cycles run. The control point has to move closer to issuance, scope binding, and runtime authorization decisions, especially when an agent can discover new capabilities on demand.
MCP also changes how shadow IT appears in practice: the asset is no longer just an undocumented service, but a hidden path from an agent to a business action. That makes inventory quality, ownership clarity, and downstream telemetry the minimum viable foundation for governance.
For practitioners
- Establish continuous MCP server discovery Inventory servers across endpoints, workstations, containers, CI/CD systems, and cloud instances, then classify each by owner, exposed tools, authentication status, and sanctioning status.
- Enforce authentication and scoped authorization Require explicit identity checks for every MCP interaction and deny unauthenticated access to sensitive tools, data sources, or workflows.
- Sanitize tool output and JSON-RPC payloads Validate schemas before execution, treat server-supplied context as untrusted, and isolate deserialization or command paths that could reach privileged systems.
- Review delegated tokens and consent paths Bind scopes to the intended audience, reduce token passthrough, and verify that user intent still matches the action an agent can trigger downstream.
- Vetting third-party MCP servers before production use Evaluate community servers like other third-party dependencies by reviewing code where possible, scanning for malicious behaviour, and testing in a non-production environment.
Key takeaways
- MCP introduces a new governance layer for AI agents because it standardizes access to tools, data, and workflows across the enterprise.
- The main risk is not the protocol alone, but the gap between agent connectivity and the controls needed to govern identity, authority, and context.
- Teams need continuous discovery, scoped authorization, and downstream visibility if they want to keep agent-driven access inside policy boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP deployments often omit mandatory authentication at the protocol boundary. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns about broad scopes and privileged intermediary servers. | |
| NHI-10 — Human Use of NHI | Developers can create MCP access paths manually, turning human workflow into machine authority. | |
| Recommendation — Require authenticated access for every MCP server before it can reach sensitive tools or data. Reduce MCP server scope so each tool can only reach the resources it genuinely needs. Govern developer-created MCP access paths as controlled NHI assets, not ad hoc convenience links. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes delegated tokens and downstream movement through connected systems. |
| Recommendation — Map MCP token abuse and downstream hopping to TA0006 and TA0008 in your detection content. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether MCP entitlements remain bounded across agent, client, and server layers. |
| Recommendation — Apply PR.AA-05 to verify MCP permissions, entitlements, and authorization boundaries end to end. | ||
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.
- 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.
- 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.
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.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org