Security governance for agentic AI has focused almost entirely on the reasoning layer. What agents decide, which detections they act on, whether a human signs off before a consequential action runs. That work matters, and it is not finished. But it leaves a different problem building underneath it.
The Model Context Protocol layer connects agents to the tools, data sources, and APIs they need to function. And it has run ahead of the governance models built to see it, according to Sysdig's 2026 Cloud Native Security and Usage Report. MCP servers do not expose inference interfaces. They expose the connective layer between models and the systems they can act on. That is a different class of risk, and most organizations are not governing it yet.
This article features contributed insights from Ivan Milenkovic (Qualys), Ganesh Kirti (TrustLogix), Shomron Jacob (Iterate.ai), Peter Chuzie (SimSpace), Amit Gautam (Abluva), and Mona Rajhans (Palo Alto Networks).
One Credential Behind Everything
The foundational risk in MCP is structural, not incidental. "MCPs power and its risk come from the same property: one agent, many tools. Most MCP implementations today still rely on coarse permissions," comments Ivan Milenkovic, VP Risk Technology EMEA at Qualys. "If the agent holds the API key, it can usually invoke everything behind it."
The access model most teams deploy is one credential with reach across every system behind it, plus a quiet assumption that the agent stays in scope. That is not a security model. And the exposure runs deeper than permissions, into the tooling layer itself. Milenkovic points to the surface that gets the least attention. "That becomes dangerous the moment prompt injection can influence which tools the agent decides to call, and tool descriptions themselves are turning out to be an under-appreciated injection surface."
The fix starts with inventory, not permissions. Find where MCP servers run, which agents connect to them, and which model drives each agent. Then scope. Per-tool scopes, contextual authorization, and human approval for sensitive operations all follow from that inventory, and none of them work before it exists.
MCP Creates a Privileged Intermediary
The gap is not only about permissions. It is a blind spot in how identity and access frameworks were built. Ganesh Kirti, Founder and CTO at TrustLogix, describes the position an MCP server occupies. "MCP servers create a new class of privileged intermediary, one that sits between people, agents, tools, and data, but that most identity and access frameworks have never been designed to see, let alone govern."
The practical cost is the audit trail. An agent connecting through MCP can inherit permissions nobody explicitly granted it, and tool calls run with no inspection. The chain between a user, the agent acting for them, and the data being touched breaks down, taking any record of authorization with it. "You cannot tell whether a given action was authorized, by whom, and under what policy," he reasons.
The answer Kirti points to is a policy decision point that evaluates every tool call in context. Which user originated the task, which agent acts for them, what the task scope is, and whether the system being reached falls inside the granted purpose. "Purpose-based access control is not an optional feature in agentic environments. It is the only model that holds when agents are operating autonomously at scale."
Perimeter Thinking Does Not Fit MCP
Part of why MCP governance lags is a borrowed mental model. Teams apply perimeter security to a protocol that has no perimeter. Shomron Jacob, Head of Machine Learning and Platform at Iterate.ai, names the failure mode. "Organizations are applying perimeter-style thinking to an architecture that doesn't have a perimeter. They define what a human user can access, map it to a service account, and hand it to an agent. The problem is that agents chain tool calls in ways no human workflow anticipates. A single misconfigured permission can cascade through an entire automated sequence before any meaningful review happens."
The correction is discipline, not engineering complexity. Scope the tool permission layer before the workflow goes live, and rebuild least-privilege for systems that act on their own at speed. Jacob is blunt about the cost of doing it late. "You treat the tool permission layer like it matters from day one not after the agent workflow is already running in production. Rethink least-privilege from scratch for systems that act autonomously at speed. Scoping permissions after the fact just means you're documenting the blast radius instead of limiting it."
Scope reactively and you are not governing. You are writing a retrospective on exposure that already exists.
Build the Control Point First
The architecture that closes the gap needs a dedicated governance layer between agents and the systems they reach. Peter Chuzie, Senior AI Solutions Architect at SimSpace, frames what that layer handles. "MCP does not just connect an agent to a tool. It creates a new access path."
That access path raises concrete questions. What the agent can see, what it can change, when it needs explicit approval, and how anyone reconstructs events afterward. Chuzie's image for the answer is a controlled opening, not a wall. "I think of it a bit like a floodgate. Once organizations figure out how to govern MCP access, they can open the flow in a controlled way and safely expand agentic capabilities across security and the business. Without that layer, teams may still deploy agents quickly, but the flow becomes harder to see, harder to control, and much riskier over time."
The governance layer is not a brake on capability. It is what makes expanding capability safe. Organizations will build it either before an incident or after one.
Controls Belong Next to the Data
Most teams reach for a single switch at the MCP layer. Turn a tool on, turn it off. Amit Gautam, CTO at Abluva, watches that approach break down fast in production. "Simple on/off tool switches at the MCP layer prove insufficient." The failure shows up as resource exhaustion and quiet overreach, where "agents with broad or long-lived permissions via MCP can overwhelm databases through rapid, looped queries, access data beyond their scoped intent, or propagate compromised actions downstream."
The fix runs in two places at once. The MCP layer needs to watch how the agent behaves, not just which tools it holds. "Real deployments need behavioral understanding—monitoring intent, reasoning traces, and usage patterns—with auto-controls like rate limiting, dynamic least privilege, and circuit breakers."
And Gautam's deeper point is that no single layer holds on its own. A guard at the MCP layer fails the moment the agent layer is subverted, so enforcement has to sit closer to the resource. "A strengthened MCP layer (secure agent-MCP connections and tool-level guards) must pair with deeper, resource-proximate controls: a separate secure data plane enforcing fine-grained, context-aware policies regardless of upstream agent behavior."
The Model Is Not the Weak Point
The agent's reasoning quality is rarely what fails first. Mona Rajhans, Senior Engineering Manager at Palo Alto Networks, locates the real exposure. "The same MCP and tool-integration layers that make agentic security powerful, including access to repositories, IAM systems, cloud telemetry, ticketing systems, and infrastructure APIs, also create entirely new trust-boundary risks."
She ties it to a consistent pattern in AI-assisted exploitation. "The model is often not the weakest link. The workflow around the model is." An agent can be well-aligned, well-supervised, and technically sound, and still reach systems it was never meant to touch, because the MCP layer connecting it was never governed.
For regulated sectors and critical infrastructure, that gap carries the same weight as any other misconfigured access path. MCP is now part of the operational fabric of cloud environments, the way APIs became critical infrastructure before anyone codified the standards for governing them. The gap is specific, it is bounded, and it compounds with every deployment that ships without a governance model in place.
