MCP security and governance gaps in agentic AI toolchains

At a glance

What this is: This is an analysis of MCP as a universal connector for AI tools and data, with the key finding that standardisation makes agentic workflows more useful but also easier to over-permission and misuse.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern AI tool access as a runtime control problem, not just an integration design problem.

Context

MCP, or Model Context Protocol, is a standard for connecting AI systems to tools and data sources through a common client-server model. In practice, that means an agent can reach code repositories, documents, APIs, and operational systems through one interface instead of one-off integrations.

For identity teams, the governance issue is not the protocol itself but the trust model it creates. Once AI systems can invoke tools, request data, and trigger side effects in real time, the core questions become who granted the access, what scope was exposed, and how those actions are audited and constrained.

That shifts MCP into the same governance conversation as NHI, workload identity, and agentic AI access control. The article's central point is that interoperability increases utility, but it also creates a much larger control surface for credentials, permissions, and unsafe automation.

Key questions

Q: What breaks when MCP servers are not governed like integrations?

A: What breaks is the trust boundary. If an MCP server can connect an agent to tools or data without clear ownership, logging, and access limits, the server becomes part of the effective attack path. That creates hidden delegation and makes it harder to prove which actions were authorised.

Q: Why do broad MCP permissions increase AI agent risk?

A: Broad permissions expand the blast radius of any prompt injection, configuration error, or credential compromise. An agent can act at machine speed across APIs, databases, and files while appearing to behave normally. That makes least privilege and separation of duties essential, especially where production or regulated data is reachable.

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: Should organisations treat MCP approvals as a security control or a usability choice?

A: Security control. Approvals determine which tools an AI system can reach, which actions it can trigger, and how quickly damage can spread if a token is misused. If approvals are broad or permanent, they become standing delegation for the agent, so they should be governed like privileged access.

Technical breakdown

MCP client-server architecture and tool exposure

MCP uses a host, client, and server model. The host is the AI application, the client translates model requests into MCP calls, and the server exposes capabilities such as resources, tools, and prompts. That separation makes tool access more modular, but it also means the server becomes the policy and trust boundary for whatever data or action it exposes. In identity terms, the server is not just an integration point. It is the control plane for what the model can see and do in a given session.

Practical implication: Treat every MCP server as a governed access surface with explicit scope, identity, and logging.

Why tool calls create a governance problem

The protocol is designed so a model can ask for data or trigger actions through standardised calls. That is useful, but side-effecting tools can write to databases, create pull requests, send messages, or run deployment steps. Once those actions are available to an AI workflow, the risk shifts from hallucinated text to authorised misuse, prompt injection, or unintended execution. The important distinction is that MCP standardises interaction, not intent. Governance must therefore focus on what the tool can change, not only what the model can say.

Practical implication: Classify MCP tool endpoints by blast radius and restrict write-capable actions more tightly than read-only resources.

Authentication, approval, and auditing in agentic toolchains

Backslash Security notes the need for least privilege, user approvals, OAuth-based authentication, encryption, and centralised logging. Those controls matter because MCP can connect into coding, testing, and CI/CD environments where a single credential may unlock multiple systems. In an agentic workflow, the risk is not only leakage of a token but also delegated access being reused across several tool calls before a human notices. Audit logs help, but only if the underlying identities, scopes, and approval gates are already well defined.

Practical implication: Anchor MCP governance in least-privilege scopes, approval gates for sensitive tools, and centralised audit review.

Threat narrative

Attacker objective: The objective is to turn trusted AI tool access into a scalable path for credential abuse, data exposure, or unsafe execution across connected systems.

1. Entry occurs when a model or agent connects to an MCP server that exposes tools, data, or side-effecting actions through a shared protocol.
2. Credential access or misuse follows when the server is authorised with tokens or scopes broad enough to reach multiple systems from one workflow.
3. Escalation happens when the agent chains tool calls into higher-impact actions such as code changes, deployment steps, or outbound messaging.
4. Impact is reached when the workflow produces unintended data exposure, unsafe automation, or operational changes at machine speed.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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 creates an identity problem, not just an integration problem. The protocol standardises how AI systems reach tools and data, but the control question moves to runtime authority the moment a model can trigger side effects. That makes tool scope, approval, and auditability first-class identity concerns rather than integration details. Practitioners should treat MCP as delegated access that must be governed end to end.

Runtime access beats static configuration when agents can act through tools. The article shows why permissions granted once at setup can become too broad once an AI workflow begins chaining calls across repositories, ticketing, messaging, and deployment systems. The old assumption that one credential maps neatly to one purpose no longer holds when a single agent can traverse several tools in one session. Governance has to follow the action path, not the onboarding checklist.

MCP security depends on limiting side effects, not only blocking exposure. Read-only resources are easier to reason about than tools that can write, deploy, or notify, because side-effecting functions change state outside the model boundary. That makes the protocol's tool catalogue a practical control inventory for identity and access teams. Practitioners should rank tools by blast radius before they approve any agentic workflow.

Ephemeral AI convenience can still create persistent trust debt. When MCP servers are added quickly to support developer productivity, the organisation inherits a larger set of connectors, tokens, and approvals than most teams can inventory accurately. The trust debt comes from treating every new connector as a simple productivity gain instead of a governed access path. The implication is that MCP adoption must be measured by control quality, not connector count.

Named concept: MCP tool blast radius. The article illustrates how a protocol that standardises tool access also standardises the route to high-impact actions if scopes are too broad. That blast radius spans code, data, and operational systems because the same agent can move across all three. Practitioners should think in terms of blast radius per tool, per server, and per session, not just per application.

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: MCP Security Guide

What this signals

MCP tool blast radius: organisations should expect the security debate to shift from whether AI can connect to tools to how far one approved connector can move inside operational systems. When a protocol lets the same agent read code, write records, and trigger deployment, the control boundary has to be defined per tool and per session, not at the application level.

The practical test for MCP governance is whether your approval model still works when an AI workflow chains several legitimate actions together. If it does not, then the identity programme is relying on assumptions about bounded use that agentic toolchains no longer satisfy.

For practitioners

• Map every MCP server to an owner and purpose Inventory each server, the data it exposes, the tools it can invoke, and the business function it serves. Require a named owner who can approve or revoke access when the connector changes.
• Separate read-only resources from side-effecting tools Classify MCP capabilities by whether they only return information or can alter state. Give write-capable tools stricter approval, tighter scopes, and more frequent review than read-only access.
• Constrain approvals to the minimum viable workflow Do not give an agent blanket permission across coding, ticketing, and deployment just because MCP can connect them. Scope approvals to one task, one environment, and one session where possible.
• Centralise audit logs for MCP activity Send JSON-RPC and tool-invocation records into your SIEM so you can reconstruct which identity called which tool, with what scope, and in what sequence.
• Review third-party MCP servers before trust is extended Treat external or community servers as supply-chain dependencies. Validate publisher trust, authentication method, and the exact actions the server can perform before allowing it into production workflows.

Key takeaways

• MCP standardisation makes AI tool access more scalable, but it also concentrates risk in the identities and scopes that govern each connector.
• The article's security concern is not only exposed secrets but also the ease with which broad permissions can turn into unsafe execution paths.
• Practitioners should treat every MCP server as a controlled access surface, with least privilege, approval gates, and centralised auditability.

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.
• Agent Tool Blast Radius: The amount of system reach an AI agent has through its callable tools, routes, and connected services. The blast radius grows when tool exposure is broad, policy is weak, or logs cannot reconstruct the execution path. Teams should treat it as a governance boundary, not a convenience metric.
• Side-Effecting Tool: An MCP tool that changes something outside the model, such as writing data, creating a deployment, or sending a message. These tools are more sensitive than read-only resources because they convert a model request into a state change that must be authorised and logged.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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.