AI policy enforcement gaps are driving shadow AI and runtime risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WitnessAI's blog post: AI policy enforcement fails when organisations rely on static documents and legacy DLP instead of runtime controls that understand AI conversations and user intent.

Why it matters: It matters because IAM, security, and governance teams need policies that change behaviour in the moment, especially as employees and AI agents use approved and unsanctioned AI tools side by side.

Context

AI policy enforcement is the point where written rules become runtime controls. In this article, the core gap is not the absence of policy language, but the absence of operational machinery that can govern AI use as it happens.

That gap matters for AI governance, human IAM, and agentic AI programmes alike. If policy can only be read after the fact, employees will route around it, and AI use will move into shadow channels that security teams cannot reliably see or constrain.

Key questions

Q: What breaks when policy is only documented for AI agents instead of enforced inline at runtime?

A: When policy lives only in a document, the agent can still attempt risky actions, and the downstream system may accept them unless a control blocks them in real time. Inline enforcement changes that failure mode. Denied actions stop at the tool call, which prevents unauthorized data access, unsafe egress, and high-impact operations from ever reaching the target system.

Q: Why do rigid AI controls push users toward shadow AI?

A: Rigid controls create friction for legitimate work, so users look for faster paths outside the approved stack. When security teams only offer block-or-allow decisions, productivity pressure wins and personal accounts, unsanctioned models, or unapproved plugins become the practical workaround. Governance fails when the control design ignores workflow reality.

Q: How do organisations know if AI governance is actually working?

A: They should be able to reconstruct a live interaction from identity context, policy outcome, accessed resources, and enforcement evidence. If the organisation can only show a policy document or a generic alert, governance is incomplete. Working AI governance leaves behind reviewable artefacts that compliance, legal, and security teams can use without guessing what happened.

Q: What is the difference between policy evaluation and policy enforcement for AI agents?

A: Policy evaluation is the decision step that determines whether access should be allowed. Enforcement is the point where the application, gateway, or infrastructure component actually blocks or permits the action. For agents, the two must stay aligned across every tool and protocol the agent can reach.

Technical breakdown

Why legacy DLP fails against conversational AI

Legacy DLP was built around inspectable artifacts such as files, email, and transfers. Conversational AI is different because prompts and responses are transient, context-dependent, and often embedded in browser sessions or application workflows rather than in durable documents. Static pattern matching can identify a word or phrase, but it cannot interpret whether a prompt is benign research or a risky attempt to move sensitive material into an external model. That makes the control blind to the actual behaviour that matters. In AI policy enforcement, the unit of risk is the interaction, not the file.

Practical implication: review whether your current controls can inspect live AI interactions, not just stored content.

Intent-based classification and policy granularity

AI enforcement has to understand purpose, not just text. Intent-based classification uses context and behavioural signals to determine what a user is trying to do, then applies different policy actions by organisation, team, individual, and model. That matters because a legal associate comparing contract clauses, an engineer generating code, and a marketer drafting copy may all use similar prompts but face different governance rules. Without that granularity, security teams are forced into blunt allow-or-block decisions that create friction and push users toward unsanctioned tools. The technical requirement is policy that can adapt at runtime without losing auditability.

Practical implication: design AI policy tiers that vary by role, data type, and approved model rather than one global rule set.

Runtime controls across human users and AI agents

AI enforcement is no longer only about people typing prompts. The article also points to AI agents making tool calls and consuming data inside runtime workflows, which means the control plane has to govern both human and machine interactions. That expands the problem from prompt filtering to access control, response protection, routing, and logging across browser tools, native apps, developer environments, and API-driven agent activity. When the same policy layer has to address both human users and AI agents, the control has to operate before execution, not after review. The architecture must be designed for decision-time enforcement.

Practical implication: extend AI policy controls to agent tool use, API calls, and response inspection, not just user prompts.

NHI Mgmt Group analysis

AI policy enforcement is a control problem, not a documentation problem. Written policy has value only when it becomes a runtime decision layer that can inspect, classify, and constrain behaviour as it happens. Organisations that stop at PDFs and approval lists create a false sense of governance because the actual enforcement point remains undefined. The implication is straightforward: AI governance must be evaluated by executable controls, not by the existence of policy language.

Shadow AI is often the symptom of control design failure. The article describes three predictable breakdowns: no policy, an approved stack that does not meet user needs, and enforcement that is too rigid to support legitimate work. In each case, people route around the system because the path of least resistance is outside the sanctioned stack. The practitioner lesson is that governance quality is measured by whether users stay inside the control boundary when productivity pressure rises.

Intent-based enforcement is the named concept that separates workable AI governance from keyword filtering. Static rules cannot reliably distinguish between similar-looking prompts with very different risk profiles, especially in conversational AI where context and purpose matter more than literal terms. That is why intent must become part of the policy decision itself, not a post-processing layer. The implication is that AI policy should classify behaviour, not just content, if it is to be enforceable at scale.

AI enforcement now spans human IAM and autonomous execution paths. The article explicitly covers both human employees and AI agents, which means policy has to govern prompt use, tool calls, and response handling across different actors. That widens the identity problem from user access to runtime authority and makes boundary-setting a governance discipline rather than a tooling choice. The implication is that teams should align AI controls with the same lifecycle and authorization thinking they already apply to privileged access and machine identity.

Runtime guardrails replace the outdated assumption that prevention must be all-or-nothing. Allow, warn, block, and route create a more usable control model than binary decisions because not every AI interaction has the same risk profile. This matters because blanket blocking drives exception culture and tool sprawl, while graded enforcement preserves productivity and auditability. The practitioner conclusion is that AI governance should be graduated, contextual, and enforceable at the point of interaction.

From our research library:

• Only 37% of organisations had policies for managing AI or detecting shadow AI, according to IBM's 2025 Cost of a Data Breach Report.

What this signals

AI governance has crossed from guidance into control design. Teams should stop asking whether policy exists and start asking whether the organisation can enforce it at the moment a prompt, tool call, or agent action occurs. That is the dividing line between document-based compliance and operational governance.

Shadow AI is a governance signal, not just a user-behaviour problem. If employees keep leaving the sanctioned path, the approved stack is either too weak, too narrow, or too hard to use. Security leaders should treat repeated policy bypasses as evidence that the control model needs redesign, not just more communication.

For practitioners

• Map AI policy to runtime control points Identify where policy is actually enforced across browser tools, native apps, developer environments, embedded copilots, and API-driven agent calls. If enforcement exists only in documents or after-the-fact review, the control is not operating where risk occurs.
• Replace binary allow-or-block logic Introduce graduated responses such as warn and route so legitimate work does not automatically push users into unsanctioned tools. The goal is to reduce shadow AI by making the approved path usable under real business conditions.
• Classify AI interactions by intent and context Build policy logic that evaluates what the user is trying to do, which data is involved, and which model is receiving the interaction. Keyword-only filters are too coarse for legal, engineering, finance, and marketing use cases.
• Extend governance to AI agents as well as people Treat agent tool calls, response handling, and delegated actions as enforceable policy events rather than background automation. If an AI agent can act, the governance model must account for that runtime authority.

Key takeaways

• AI policy fails when organisations treat it as a document instead of an enforceable runtime control.
• Legacy security tools struggle because conversational AI requires context-aware enforcement, not static pattern matching.
• The practical answer is graduated, intent-aware controls that keep approved AI use usable while containing shadow AI.

Key terms

• AI Policy Compliance: AI policy compliance is the practice of governing how AI is used so that interactions stay within legal, regulatory, and internal boundaries. It combines policy, security, and auditability, but the real test is whether the organisation can enforce rules during live AI behaviour, not just document them after the fact.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Intent-based classification: Intent-based classification evaluates what a user or system is trying to do, not just what text or file is present. In AI governance, it distinguishes routine work from risky interaction by reading context, purpose, and sensitivity. That matters when regulated data is handled conversationally rather than through formal file transfer.
• Runtime control: Controls that enforce policy while an AI system is operating, rather than after the fact. For healthcare chatbots, runtime control includes data masking, output filtering, access scoping, and immutable logging so the organisation can defend the interaction itself.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.