Why do policy documents fail to control AI model and MCP server usage?

Why This Matters for Security Teams

Policy documents often fail in AI environments because they are descriptive, not controlling. A clause that says an AI model or mcp server must be approved does not stop an engineer from connecting a new tool, a data scientist from swapping a model, or an operator from reusing a stored secret. The gap is especially visible when governance lives in documents while enforcement lives in separate platforms, because no single control point confirms what is actually running.

For AI and agentic systems, that gap matters more than in traditional IT. Model choice affects data exposure, prompt handling, output quality, and downstream actions. MCP server usage adds another layer of risk because it can extend an agent’s tool access, data reach, and execution authority. The result is not just shadow IT, but shadow behavior inside systems that can act, call tools, and move data without a human reviewing every step. Current guidance from the OWASP Top 10 for Agentic Applications 2026 reinforces that these risks need technical guardrails, not only policy statements.

Security teams also underestimate how often policy is treated as evidence of control during audits or incident reviews. In practice, many security teams encounter unauthorized AI usage only after logs, cost spikes, data leakage, or prompt abuse have already occurred, rather than through intentional governance.

How It Works in Practice

Effective control comes from putting the policy decision inside the workflow and the runtime path, not only in a document. That usually means connecting model registries, MCP server allowlists, secrets management, access policy, and logging so the system can enforce what the policy says. If the policy says only approved models may be used, then the application, orchestration layer, or gateway must verify that approved status before the model is called.

For MCP server usage, the important question is not only whether a server exists, but whether the agent is authorised to discover it, connect to it, and use its tools under the right identity and scope. A good control design separates approval from execution:

• Approval defines which models and MCP servers are permitted for a use case.
• Enforcement blocks unapproved endpoints, models, or tool calls at runtime.
• Monitoring records actual usage, including prompts, tool invocations, and exceptions.
• Secrets and credentials are scoped so a model or agent cannot silently expand its reach.

This is where the NIST Cybersecurity Framework 2.0 is useful at an operational level: governance, asset management, access control, and monitoring must work together, not as separate paperwork exercises. NIST AI risk guidance and OWASP agentic guidance both point toward the same operational principle: model and tool usage should be governed by enforceable controls, not by memory or after-the-fact review. Where organisations mature faster, they also add explicit exception handling, so temporary approvals expire and are visible in telemetry. These controls tend to break down when AI usage is embedded in local scripts, developer laptops, or ad hoc agent sandboxes because the enforcement layer never sees the request.

Common Variations and Edge Cases

Tighter model and MCP server control often increases operational overhead, requiring organisations to balance speed of experimentation against auditability and containment. That tradeoff is real, especially in research teams, product prototyping, and rapid automation programmes. Best practice is evolving on how much friction is acceptable, but there is no universal standard for this yet.

One common edge case is “approved but unsafe” usage. A model may be on the allowlist, yet still be connected to sensitive data, exposed to untrusted prompts, or granted excessive tool scope. Another is delegated access through an AI agent: the model itself may be permitted, but the agent’s downstream actions are not adequately constrained. In those cases, the policy may be technically true while the operational exposure is still unacceptable. The OWASP Agentic AI Top 10 is useful for thinking about these delegation and tool-use failure modes.

Another edge case is fast-moving model supply chains. If a team pulls a new model version, a hosted endpoint, or an MCP server configuration from a pipeline without revalidation, the original policy statement becomes stale immediately. The practical answer is versioned approval, continuous discovery, and automatic retirement of expired exceptions. In environments with high automation and many local integrations, policy documents fail most decisively because they cannot keep pace with changes in model endpoints, tool permissions, and secrets reuse.

Related resources from NHI Mgmt Group

• Why do model-level defenses fail as the main control for MCP?
• Why do inventory and policy documents fail to prove AI governance maturity?
• Why do model guardrails fail as a sole control for AI agents?
• Why do MCP tools need server-side policy checks instead of token-only controls?