Why do AI agents, MCP servers, and model files create compliance risk even when code scans pass?

Why code scans miss the real compliance surface

AI agents, MCP servers, and model files can all change behaviour without changing much source code. Compliance risk appears when the control plane is outside the code path, for example in runtime permissions, model instructions, tool registration, authorization policy, secrets handling, or deployment configuration. That means a clean SAST or SCA result can coexist with a system that is still effectively ungoverned.

Model files are especially deceptive because they can embed instructions, routing, safety bypasses, or tool-use assumptions that scanners treat as inert artefacts. Likewise, an MCP server may expose powerful tools through its authorization model, not through its repository code, so the real control question is what the system can do at runtime, not only what the code imports.

For compliance teams, the important distinction is between static code quality and governed execution. A repository may be free of obvious vulnerabilities while the deployed agent still has delegated access to production data, external APIs, or privileged actions that were never reviewed as part of the scan.

Where the risk actually lives in AI artefacts and tool chains

The risk usually concentrates in the artefact boundary rather than the application source. An agent can inherit permissions from a human, a service account, or an upstream platform, then use tools, plugins, or connectors that were added after code review. In that case, the scan passes because the code is unchanged, while the operational blast radius grows through configuration and trust relationships.

MCP servers deserve particular scrutiny because the security question is often about authorization, audience binding, and token handling, not just server-side code correctness. The same applies to model files that are distributed as “content” but function as executable policy carriers, especially when they determine which tools can be called, which data can be read, or which prompts are trusted.

This is why agentic systems often need governance controls that look more like access review, change control, and runtime policy enforcement than traditional application scanning. If the artefact can trigger actions, move data, or chain tools, it belongs in the compliance scope even when no vulnerable library appears in the dependency tree.

What auditors and security teams should verify instead

Start by asking what the artefact can do after deployment, not what the repository contains before release. If an AI agent can reach external systems, read secrets, invoke tools, or act on behalf of a user, those capabilities should be inventoryable, approved, and periodically revalidated.

It also helps to separate three reviews: code integrity, runtime authorization, and artefact governance. Code scans answer one question, but compliance depends on whether the deployed agent, MCP endpoint, or model package is governed with documented ownership, change history, and access boundaries. When those controls are missing, the system may be technically clean and operationally non-compliant at the same time.

Practitioners should treat indirect execution paths as first-class assets. That includes prompt templates, tool registries, model weights, server configuration, environment variables, and any secret or token that gives the artefact authority. If the control is only visible after launch, then launch-time review and post-deployment monitoring become part of the compliance evidence set.

Risk and Threat Considerations

These systems create a false sense of assurance because standard scanners are built to inspect code structure, not delegated authority or runtime intent. The result is exposure that can persist even when the build looks clean, especially if a model file or MCP server can invoke privileged tools, access sensitive data, or reuse standing credentials.

Failure mechanism: The compliance failure occurs when runtime permissions, tool connections, or embedded instructions change behaviour outside the scanned source tree, leaving unreviewed execution paths in production.

Impact: Organisations can approve software that still violates least privilege, access governance, or change-control expectations, and a compromise of the artefact can then translate directly into unauthorised actions or data exposure.

Practitioner Guidance

What to verify: Confirm that every AI artefact has an owner, an approved purpose, a defined runtime authority boundary, and a revocation path for tools or credentials it can reach. If you cannot point to the permissions it uses in production, the scan result is incomplete.

Decision rule: If the model, agent, or MCP server can execute actions or access data beyond what the repository itself shows, require runtime governance evidence before treating the release as compliant. If it only passes static scanning, treat that as a code-quality signal, not as control assurance.

Practitioner takeaway: The real question is not whether the artefact’s code is clean, but whether its deployed authority is visible, bounded, and reviewable.

Related resources from NHI Mgmt Group

• Why do AI coding agents create architectural risk even when code compiles and tests pass?
• Why do non-human identities create compliance risk even when policies exist?
• Why do AI model servers create NHI governance risk even when deployed locally?
• Why do AI agents with MCP access create more risk than model routing alone?