Model Context Protocol security exposes a new governance gap

At a glance

What this is: This is an analysis of how Model Context Protocol changes enterprise AI connectivity and creates a new governance and attack-surface problem for AI agent access.

Why it matters: It matters because IAM, PAM, and security teams must govern who and what can invoke tools, APIs, repositories, and workflows through MCP before agent sprawl outpaces control.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 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%).

👉 Read Salt's analysis of Model Context Protocol security and enterprise AI governance

Context

Model Context Protocol is a standardized way for AI systems to discover and use external tools, data sources, and business systems. In practice, it turns agent connectivity into an identity and access problem, because every tool call can carry policy, privilege, and audit implications that traditional API reviews often miss.

For enterprise identity programmes, MCP matters because it sits between the agent and the systems of record. That makes it the control point where authentication, authorization, session handling, logging, and tool approval either constrain behaviour or fail to contain it.

Salt's article frames MCP as useful infrastructure that is being adopted faster than governance is being established. That is a typical pattern whenever a new access layer becomes operational before discovery and control are mature.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why do MCP environments increase identity governance complexity for AI agents?

A: MCP turns model-tool interaction into a repeatable identity event, which means access, logging, and approvals must work at the capability level rather than at the application level. That complicates governance because the same tool may be reused across many workflows, making privilege review and audit trails harder to standardise.

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

MCP client-server architecture and delegated tool execution

MCP uses a host, one or more clients, and servers that expose tools, resources, and prompts. The important security shift is that the server does not just return data, it also advertises capabilities and can execute actions that the agent chooses at runtime. That makes the protocol more than an integration layer. It becomes a delegated execution path where trust has to be established across user, agent, client, server, tool, and downstream system. If any one of those trust boundaries is loose, the resulting action can exceed what the original user intended.

Practical implication: Treat each MCP server as privileged connectivity infrastructure and assign explicit ownership, scope, and approval boundaries before production use.

Identity, tokens, and authorization in MCP access chains

MCP deployments often rely on bearer tokens, OAuth flows, or delegated credentials to connect agents to business systems. The risk is not just token theft, but scope drift, long-lived authorization, and confused deputy behaviour when a trusted component acts with more authority than the request deserves. Because MCP can sit in front of repositories, APIs, databases, and cloud services, weak authorization at the protocol edge can become broad downstream access. Authentication alone is not enough if the server can reach more systems than the request should permit.

Practical implication: Bind tokens to narrow scopes and verify that every MCP tool call is authorized for the specific user, agent, and action.

Tool poisoning, prompt injection, and untrusted context

MCP servers can embed hidden instructions in tool descriptions, metadata, prompts, or outputs. If an AI agent treats that content as trusted context, it may leak data, ignore security constraints, or trigger unintended tool use. This is closely related to prompt injection, but MCP adds a stronger control concern because the untrusted content can arrive through a privileged server rather than a public webpage. Structured schemas and JSON-RPC do not remove the issue if the receiving agent still accepts manipulated context as legitimate guidance.

Practical implication: Sanitize tool metadata and outputs, and isolate untrusted context before it reaches agent decision-making or execution logic.

Threat narrative

Attacker objective: The objective is to turn agent-to-tool connectivity into unauthorized data access, workflow manipulation, or downstream system compromise.

1. Entry occurs when a developer or attacker gains access to an MCP server, malicious tool definition, or exposed local tooling surface that is trusted by the agent.
2. Escalation occurs when the server's delegated authority, broad token scope, or injected instructions cause the agent to invoke tools or downstream systems beyond the original intent.
3. Impact occurs when the agent reads data, writes to repositories, triggers workflows, or touches cloud and API resources through the compromised MCP path.

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 creates a governance gap because it standardizes connectivity before it standardizes trust. The protocol makes agent-to-tool integration easy, but it does not by itself solve authentication, consent, scope control, or auditability. That means enterprises can scale access faster than they can prove who authorized what, and that is a classic identity control debt problem. Practitioners should treat MCP as a control plane that needs governance, not as a convenience layer.

Shadow MCP is the non-human identity problem hiding inside agentic AI adoption. Developers can stand up servers on workstations, in containers, or in CI/CD with little formal review, which makes discovery and ownership the first security failure. Once those servers can reach repositories, databases, cloud APIs, or internal workflows, they behave like privileged NHIs with ambiguous lifecycle and weak accountability. Practitioners need to recognise MCP server sprawl as an identity inventory problem, not only an application integration issue.

Tool poisoning turns untrusted context into delegated authority. An MCP server can influence an agent by shaping descriptions, metadata, outputs, or prompts that the model later treats as action guidance. That is not just content injection, it is authority injection, because the manipulated text can drive execution through a privileged path. The implication is that context provenance becomes an access-control concern, and teams should stop assuming that structured transport equals trusted instruction.

Least privilege is harder to define when the tool graph is dynamic. MCP does not only expose static endpoints, it exposes capabilities that can be combined by the agent at runtime. That means a permission model built around individual APIs can still fail when the agent can chain tools into a broader outcome than any single entitlement suggests. Practitioners should re-evaluate authorization as an end-to-end action model, not a per-tool checklist.

Identity blast radius is the right concept for MCP governance. The security question is not whether an MCP server works, but how far one compromised server, token, or tool can move through connected systems. Once agents can query data, call APIs, and trigger workflows through a shared protocol, the damage boundary becomes the set of downstream systems the MCP path can reach. Practitioners need to measure that blast radius before they allow broad adoption.

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.
• 52% of companies can track and audit the data their AI agents access, while 48% still lack that visibility, according to the same research.
• That visibility gap is why OWASP Agentic AI Top 10 is the right next lens for teams formalising MCP governance.

What this signals

With 80% of organisations already reporting AI agents acting beyond intended scope, the MCP question is no longer whether agents will be useful, but whether their tool connectivity can be governed before it becomes operationally normal. Teams that delay discovery and scope control will inherit a control plane they never fully mapped.

Identity blast radius: this is the governance concept MCP teams need to internalise. Once a server can bridge an agent into repositories, databases, and internal APIs, the security boundary is defined by downstream reach, not by the protocol name. That makes continuous inventory, authorization review, and log completeness the practical measures that matter.

Security leaders should expect MCP governance to converge with API security, workload identity, and agent oversight. The programmes that survive this shift will be the ones that can answer three questions quickly: what servers exist, what they can touch, and what evidence exists for every tool call.

For practitioners

• Discover and inventory every MCP server Build a live inventory across endpoints, developer workstations, cloud instances, containers, and CI/CD systems. Capture owner, authentication state, exposed tools, connected systems, sanctioning status, and access scope so unknown servers do not become hidden production paths.
• Apply least privilege to each tool, client, and downstream system Separate read, write, and execution rights so a documentation server cannot modify repositories and an analytics server cannot touch cloud infrastructure. Review the scope again whenever tools, credentials, or exposed resources change.
• Require explicit authorization for every agent-driven action Validate the user, agent, client, server, and requested action before a tool call is allowed to proceed. Narrow OAuth scopes, bind tokens to intended audiences, and avoid token passthrough where downstream authority exceeds the original request.
• Treat tool metadata and outputs as untrusted inputs Sanitize descriptions, prompts, and returned content before it can influence agent behaviour. Use strict schema validation, isolate malformed payloads, and monitor for tool poisoning or prompt injection attempts that alter execution paths.
• Log the full MCP decision trail Record who initiated the request, which agent and client were involved, which server received the call, which tool ran, what authorization decision was made, and what downstream system was touched. Without that sequence, incident response cannot reconstruct agent-driven activity.

Key takeaways

• MCP turns AI agent connectivity into an identity and access governance problem because every tool call can carry delegated authority.
• The main risk is not the protocol itself, but unmanaged servers, weak scopes, untrusted context, and missing audit trails across the access chain.
• Enterprises need live discovery, least privilege, and action-level logging before MCP adoption scales beyond a few controlled use cases.

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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• Step-by-step MCP server discovery and inventory guidance for production environments
• Practical examples of authentication, scope control, and audit logging across agent-to-tool access
• Detailed discussion of tool poisoning, prompt injection, and confused deputy risk patterns
• Security review considerations for third-party MCP servers before production use

👉 Salt's full article covers MCP governance, risk patterns, and deployment safeguards in more operational detail.

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