MCP governance stops at the model boundary: what teams miss

At a glance

What this is: This analysis says mainstream AI governance stops at model oversight and leaves MCP tool calls effectively outside the control boundary.

Why it matters: IAM, security, and governance teams need to treat tool registration, runtime authorisation, and auditability as part of AI governance, not an afterthought.

Context

Enterprise AI governance has largely been designed around models, not the tools those models can reach at runtime. That leaves a blind spot when an agent can discover an MCP server and make its own tool call inside a live workflow.

For identity and access teams, the governance question is no longer limited to model review, documentation, or risk tiering. The control problem moves into tool inventory, approval, access scope, logging, and revocation for the MCP layer.

That shift matters because a mature AI governance programme can still leave the operational execution layer unmanaged. The article argues that this is now a practical security and compliance gap, not a theoretical one.

Key questions

Q: How should security teams govern managed MCP access for AI clients?

A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.

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: What should organisations do when an AI agent can call tools outside the model boundary?

A: They should add a separate governance layer for tool registration, runtime monitoring, and audit trails. The question is not whether the model is safe in isolation, but whether the agent can take an action through an external server without explicit oversight. If the answer is yes, the AI programme is incomplete.

Technical breakdown

Why model-level AI governance misses MCP runtime decisions

Most enterprise AI governance frameworks are built to classify a model, review its training data, and document its risk profile. That works when the governed unit is the model itself. It breaks when the system can independently choose a tool at runtime, because the act being governed is no longer output generation alone. MCP inserts a live decision layer between intent and action, so the governance boundary must move from static model review to runtime authorisation of tool calls and reachability. Practical implication: treat MCP tool invocation as a governed identity event, not just an AI feature.

Practical implication: Move governance controls from model approval to runtime tool authorisation and logging.

Why approved MCP servers need policy, registration, and reach controls

An MCP server is not safe simply because it is documented or technically reachable. The article’s central point is that approval needs a concrete definition: who can register a server, what must be disclosed, what changes trigger re-review, and what access the server can exercise. That is classic governance for a non-human execution surface, not model assurance. In practice, the risk is not only the server itself but the reach it inherits once an agent can discover it and call it during live operations. Practical implication: govern server registration and access scope as part of the identity lifecycle for non-human tools.

Practical implication: Define approval criteria for MCP servers and re-check them whenever tool scope changes.

Why runtime monitoring and audit trails matter more than monthly board review

A monthly review board can assess a model programme, but it cannot see which tool an agent called during a specific task unless the tool layer is instrumented. The article distinguishes between model monitoring and tool-call monitoring: the latter captures drift, misuse, and access beyond intended purpose at the moment it happens. Audit trails also matter because they let teams reconstruct who approved a server, what the agent reached, and what action was taken. Practical implication: build monitoring and evidence capture at the tool-call layer, not only in policy documents.

Practical implication: Instrument tool calls so audits can reconstruct who approved access and what the agent did.

Threat narrative

Attacker objective: The objective is to use runtime tool access to perform actions that the organisation never explicitly governed at the model level.

1. Entry occurs when an agent discovers an MCP server and is able to call it at runtime without the tool layer being separately governed.
2. Credential or authorisation exposure follows if the server can reach sensitive systems without registration-time vetting or scoped access checks.
3. Escalation happens when the agent uses that tool reach to take an action beyond what the model review process covered.
4. Impact is the resulting unmanaged security, audit, and compliance exposure from actions taken through the tool layer without governance coverage.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

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

Model-centric AI governance is structurally incomplete once agents can call tools. The common assumption in current programmes is that governance ends where the model ends, because that is where most risk reviews were designed to operate. MCP breaks that boundary by moving decisions into a runtime tool layer. The implication is not that AI governance is wrong, but that it is incomplete unless tool invocation is treated as part of the governed identity surface.

MCP introduces a new governance object: the reachable tool, not just the model. A model can be approved while the server it calls remains unvetted, over-scoped, or poorly monitored. That means the security question shifts from what the model is allowed to say to what the agent is allowed to do. Practitioners should recognise this as a governance gap in non-human identity control, not a model risk problem in disguise.

Runtime tool access collapses the usefulness of review cycles built for slower governance artefacts. Monthly model reviews, certification workflows, and documentation-based approvals do not capture a decision an agent makes mid-task. That is why auditability, registration-time vetting, and continuous monitoring become primary controls for the tool layer. The practical conclusion is that AI governance must become lifecycle governance for MCP servers and agent reachability.

MCP governance creates a named control plane problem: tool-layer trust debt. The article shows that organisations accumulate trust in tools faster than they can classify, vet, and monitor them. That trust debt is invisible in model-centric frameworks because the model still looks compliant while the tool layer grows opaque. Practitioners need to treat this as an identity and access governance issue across the full AI stack, not an isolated security exception.

Frameworks such as the EU AI Act, NIST AI RMF, and ISO/IEC 42001 remain necessary, but they are not sufficient for MCP. They govern important AI lifecycle concerns, yet they stop short of runtime tool authorisation and server-level reach. The lesson for security leaders is to keep model governance intact while adding a separate enforcement layer for agent tool access, with ownership, audit, and revocation clearly assigned.

From our research library:

• 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, according to the 2026 Infrastructure Identity Survey.
• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Tool-layer governance is becoming the missing control plane in enterprise AI. Teams that already have model review boards should now ask whether those boards actually see MCP reach, server approval, and tool-call logging. The practical gap is not policy volume but enforcement at the moment an agent makes a runtime decision.

MCP governance will force identity teams to think in lifecycle terms. A server that can be discovered, called, retired, and reauthorised behaves like a governed non-human identity surface even when the model itself is compliant. The programme implication is clear: inventory, ownership, and revocation need to extend beyond the model boundary.

For practitioners

• Define MCP approval criteria Specify who can register servers, what disclosures are required, and what changes force re-review before an agent can reach the tool.
• Inventory every reachable MCP server Track approved and informal servers together so shadow tool access does not sit outside governance or audit scope.
• Scope access by server reach Classify each server by the systems it can touch, then set access boundaries based on that reach rather than on model identity alone.
• Monitor tool calls continuously Log tool invocation, changes in tool definitions, and access to sensitive actions so drift is visible during runtime, not only at review time.
• Tie retirement to revocation When an MCP server or agent is decommissioned, revoke its credentials and remove its discoverability so old trust does not persist.

Key takeaways

• Mainstream AI governance can still leave MCP tool calls outside the control boundary, which means approved models may operate through unvetted runtime actions.
• The evidence problem is operational as much as regulatory, because tool reach, change control, and audit trails sit below the layer most AI programmes currently review.
• Security and IAM leaders need a separate governance path for tool registration, runtime monitoring, and revocation if they want AI controls to cover actual agent behaviour.

Key terms

• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.
• Runtime tool authorisation: Runtime tool authorisation is the decision to allow or block an agent’s call to an external tool while the task is in progress. It differs from model approval because the control point sits at execution time, not at deployment or certification time.
• Tool-layer audit trail: A tool-layer audit trail records which MCP server was called, by which agent, under what policy, and with what result. It is the evidence base that lets teams reconstruct behaviour after the fact and prove that approvals matched actual use.
• Model Boundary: The point at which a user-facing request crosses into model execution. For AI governance, this is where policy can intercept content before inference, but it is also where blind spots emerge if the surrounding workflow is not fully covered.

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.