MCP governance stops at the model boundary: what teams miss

At a glance

What this is: This analysis argues that mainstream AI governance programs stop at the model boundary and do not adequately govern agent tool use through MCP.

Why it matters: For IAM and security teams, that gap matters because tool access, approval, and auditability now shape non-human identity risk as much as the model itself.

By the numbers:

• Only 19% of organisations have full visibility into AI usage.
• 80% of business leaders cite explainability, ethics, bias, or trust as a major roadblock to generative AI adoption.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Obot's analysis of MCP governance beyond the model boundary

Context

MCP governance is the missing control layer between AI models and the tools they can call at runtime. Existing enterprise AI governance frameworks were built to classify models, review training data, and manage documented risk, but they were not designed to govern an agent that discovers a tool mid-session and decides to use it. In practice, that leaves the tool layer unreviewed even where AI governance appears mature.

That gap matters for non-human identity governance because tool access is now an execution path, not just a technical integration. Once an agent can reach dozens of MCP servers, security teams need to know which tools were approved, who owns them, what they can touch, and how their behaviour is audited after registration. For organisations already managing AI risk, the question is no longer whether the model was assessed. It is whether the runtime action was governed.

The article’s starting position is typical for enterprises that have invested in model governance but not in tool-layer controls. That is a common maturity failure, not an edge case.

Key questions

Q: How should security teams govern MCP agents that can switch between tool calls and generated code?

A: Security teams should treat tool calls and generated code as separate execution modes with different control requirements. Direct calls are easier to log and approve, while generated code can compress many actions into one runtime block. Governance should define when each mode is allowed, what permissions it may inherit, and what evidence must be retained for review.

Q: Why do model governance frameworks miss MCP risk?

A: Because they were designed to classify and review models, not the runtime actions that happen after a model discovers a tool. The control failure is at the boundary where a valid model decision becomes an unaudited external action, which is why tool governance has to be explicit.

Q: What breaks when MCP servers are approved once but allowed to change later?

A: The original approval no longer describes the current access surface. If tools, backends, or ownership change after onboarding, the enterprise is operating on stale risk information. That creates blind spots in authorization, logging, and recertification, because the governing record reflects a past state rather than the server’s present capabilities.

Q: Who should own MCP gateway governance in an enterprise AI programme?

A: Ownership should sit with the teams responsible for identity, security architecture, and platform governance together, because MCP gateways span access control, routing, and observability. Treating the gateway as only a network component leaves policy gaps. Treating it as only an AI platform feature leaves accountability unclear.

Technical breakdown

Why model-level governance stops at runtime tool calls

Most AI governance frameworks treat the model as the regulated object. They focus on training data, documented risk tiers, explainability, and review evidence, which works until the system reaches beyond its own output and initiates a tool call. MCP changes the control surface because the consequential action is no longer just a response. It becomes an external request against a reachable service, often with side effects the model framework never inspected. That is why a program can be compliant on paper and still leave the tool layer ungoverned in operation.

Practical implication: separate model governance from tool governance and inventory every reachable MCP server as a governed asset.

What risk classification needs to measure in an MCP environment

MCP risk is not determined by the presence of a model or the brand of the AI stack. It is determined by what the tool can reach, what data it can expose, and whether it can trigger actions in production systems. A read-only internal wiki connector has a different governance profile than a tool that can write to a database or update a payment workflow. That means risk classification has to be based on reach, side effects, and approval boundaries, not on a generic AI use-case label or a monthly review board cycle.

Practical implication: classify MCP servers by reachable systems and permitted actions, then align approval rigor to that access scope.

How runtime monitoring and audit trails change the governance model

Tool-call monitoring is different from model monitoring. Model monitoring looks for drift, bias, or output quality issues. MCP monitoring has to track which tool was called, what context was used, whether the call was authorised, and whether the resulting action matched the approval intent. Without that trail, organisations cannot explain an AI-driven action to auditors or incident responders. Auditability becomes a lifecycle control, not a reporting feature, because approval at registration means little if the tool changes behaviour after deployment.

Practical implication: log tool calls at the identity, approval, and action levels so runtime behaviour can be reconstructed later.

Threat narrative

Attacker objective: The attacker objective is to exploit the gap between model governance and tool governance so that agent-driven actions occur without approval, traceability, or adequate control.

1. Entry occurs when an agent discovers and reaches an MCP server that was never vetted beyond basic documentation review.
2. Escalation happens when the agent invokes a tool whose real permissions and side effects were not classified at registration time.
3. Impact follows when the tool call creates an unaudited action, exposing data, changing state, or extending access outside the intended governance boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Model governance without MCP governance is an incomplete control plane. The article is right to separate governance of the model from governance of the tool layer because the runtime decision to call a server is a different identity event. EU AI Act, NIST AI RMF, and ISO/IEC 42001 all help with model accountability, but they do not by themselves answer who approved a tool call or what side effect it produced. For practitioners, that means the programme boundary must move from model review to action governance.

Tool reach creates a non-human identity trust boundary that most AI programmes have not named. The best name for that gap is runtime governance gap: a governed model can still trigger an ungoverned execution path. Once MCP servers become discoverable at runtime, approval needs to cover tool registration, reach, and change over time, not just the model that requested access. IAM teams should treat tool reachability as a governed entitlement, not a convenience layer.

Obot’s example shows that governance failure is usually procedural before it is technical. The article describes organisations with risk tiers, certification work, and monthly review boards that still cannot say which servers were vetted beyond documentation. That is not a tooling problem alone. It is a lifecycle failure in approval, ownership, and change control for non-human identities that act through tools. Practitioners should read this as a warning that policy language without enforcement leaves audit exposure intact.

AI governance teams and IAM teams now need a shared operating model. Model review, tool registration, access control, and audit logging cannot sit in separate silos if agents can call tools independently. The identity question has shifted from who can log in to who can act, through which tool, under what approval, and with what evidence. That is where identity governance becomes operational security, not just policy management.

MCP-specific governance will become the reference pattern for agentic AI programmes. As tool ecosystems grow, the market will move toward controls that look more like IAM and PAM than like model paperwork. The organisations that mature fastest will be the ones that can prove registration-time vetting, runtime monitoring, and lifecycle revocation for tool access. For everyone else, the gap will surface first in audits and then in incident response.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a deeper planning lens, read OWASP Agentic Applications Top 10 for the runtime risk categories that make MCP governance necessary.

What this signals

Runtime governance gap: enterprise AI programmes are now splitting into two layers, model oversight and tool-layer control. The organisations that keep treating MCP as a plumbing detail will accumulate invisible authorisation paths, and that will show up first as audit friction, then as incident response blind spots.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the practical problem is no longer whether AI has access. It is whether the access path has an owner, an approval record, and a revocation point.

Security teams should expect governance demand to move closer to IAM and PAM operating models as MCP adoption grows. If a server can be discovered at runtime, it needs lifecycle management, not just policy intent, and that changes how platform, AI, and identity teams divide responsibility.

For practitioners

• Inventory every reachable MCP server Build a live register of every server an agent can discover or call, including owner, purpose, data reach, and change history. Do not rely on developer memory or documentation alone.
• Classify tools by reach and side effects Assign risk based on what each tool can touch, whether it can write state, and what approvals are needed before execution. A read-only connector and a production-write connector must not share the same control path.
• Separate model approval from tool approval Keep model review, tool registration, and entitlement approval as distinct governance steps so an approved model cannot implicitly inherit unreviewed tool access.
• Log tool calls as identity events Capture which agent, which tool, which context, and which outcome were involved in every call so audit teams can reconstruct runtime decisions after the fact.
• Revoke retired tool access immediately When a server is deprecated, moved, or rehomed, remove its discoverability and credentials at the same time so old approvals do not survive into the next environment.

Key takeaways

• AI governance built for models does not automatically govern MCP tool calls, which leaves a real runtime control gap for enterprise teams.
• The operational risk is not abstract: once an agent can discover and call tools, approval, ownership, and auditability must extend to the tool layer itself.
• Practitioners should treat MCP servers as governed non-human identities with reach, lifecycle, and revocation requirements, not as optional integrations.

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.
• Agentic Runtime Governance Gap: The distance between approving an AI agent as a project artefact and controlling its actual production behaviour. This gap appears when static approvals, access reviews, or policy documents do not keep pace with the agent’s live tool use and changing operational context.
• Tool-layer entitlement: Tool-layer entitlement is the right for an agent to reach and invoke a specific MCP server or function. It is narrower than general system access and should be governed like a high-risk non-human identity entitlement because it can create direct side effects in connected systems.
• Registration-time vetting: Registration-time vetting is the practice of checking an MCP server before it becomes discoverable to agents. It verifies purpose, access scope, policy fit, and change risk before runtime, which helps prevent unreviewed tools from entering the agent’s action space.

What's in the full article

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

• A layer-by-layer MCP governance model showing how policy, registration, runtime monitoring, and audit trails fit together.
• A practical maturity model for organisations that need to decide which MCP servers require stricter approval and monitoring.
• Specific discussion of CVE-2026-32211 and why a model-level governance programme would miss the control failure it exposed.
• Implementation detail on how Obot positions gateway-layer enforcement, credential brokering, and exportable logs for MCP.

👉 Obot's full article covers the MCP governance framework, runtime control gaps, and the CVE-2026-32211 example.

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