AI policy enforcement gaps are driving shadow AI and runtime risk

At a glance

What this is: This is an analysis of why AI policy documents fail without runtime enforcement, and the key finding is that legacy security controls cannot govern conversational AI use effectively.

Why it matters: It matters because IAM, PAM, and governance teams now have to enforce AI usage across human users and AI agents, not just write policy for them.

👉 Read WitnessAI's analysis of AI policy enforcement and shadow AI

Context

AI policy enforcement is the runtime layer that turns written AI rules into actual controls over tools, data sharing, and approved use cases. The article argues that the gap between policy and enforcement is where AI risk concentrates, because employees will use whatever tool lets them get work done when approved options are too weak or too rigid.

For identity and access teams, the important shift is that AI usage is becoming a governance and enforcement problem rather than a pure compliance exercise. That puts approved stack design, data handling rules, and role-based permissions into the same operational conversation as access control, exception handling, and shadow AI containment.

Key questions

Q: How should security teams enforce AI policy without driving users to shadow AI?

A: Use runtime controls that can apply different responses based on risk, such as allow, warn, block, and route, instead of relying on a simple allow-or-block model. Pair that with approved tools that are usable enough for real work, or users will route around governance to stay productive.

Q: Why do traditional DLP tools fail for AI policy enforcement?

A: Traditional DLP was designed for files, email, and other inspectable artefacts, not for conversational prompts and model outputs. It also cannot reliably infer context or intent, so it either misses risky AI usage or blocks legitimate work, which makes users look for unsanctioned alternatives.

Q: How do organisations decide which AI interactions should be blocked versus routed?

A: Decide by risk, purpose, and data sensitivity. Block high-risk actions such as prompt injection, credential exfiltration, and sharing prohibited data categories. Route sensitive but legitimate requests to approved internal models or apply tokenisation so the task can continue without exposing regulated data.

Q: What should a mature AI governance programme measure beyond written policy?

A: Measure whether policy is enforced at runtime, whether exceptions are becoming routine, and whether users are adopting shadow AI because approved tools are too constrained. Those signals show whether governance is changing behaviour or only producing documentation.

Technical breakdown

Why legacy DLP fails on conversational AI

Legacy data loss prevention was built to inspect files, email, and transfers, not transient prompt-and-response exchanges. Conversational AI changes the inspection surface because the content is dynamic, short-lived, and often appears harmless in isolation. Keyword matching also misses purpose. A contract review prompt and a data exfiltration prompt can share similar language while carrying very different risk. That is why policy enforcement for AI needs context-aware classification rather than artifact scanning alone.

Practical implication: replace file-centric inspection assumptions with controls that can evaluate AI conversations at runtime.

Intent-based classification in AI policy enforcement

Intent-based classification looks at what the user is trying to do, not just what words appear in the prompt. That matters because many risky AI interactions contain no obvious sensitive markers. A system that can infer purpose can distinguish legitimate legal review from unsafe data sharing, which reduces false positives and makes enforcement sustainable. In practice, this is the difference between a control that users work around and one that can operate inside daily workflows without collapsing into exception handling.

Practical implication: classify AI interactions by purpose and context, not by keyword triggers alone.

Layered policy controls across users and models

Effective AI enforcement has to apply across organization-wide baselines, team rules, individual exceptions, and per-model governance. Different groups use AI differently, so a single control plane cannot treat legal review, software development, marketing content, and finance analysis the same way. Per-model policy matters because different AI systems have different data handling and risk characteristics. The control logic has to follow the person, the team, the model, and the use case together or enforcement will be too blunt to hold.

Practical implication: build layered policy scopes so controls can vary by role, department, exception, and model.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

AI policy without enforcement is a governance artefact, not a control. The article is right that the written policy only matters if it changes runtime behaviour. That means the real failure mode is not lack of policy language, but lack of operational machinery that can bind use cases, data types, and access decisions together at the moment of interaction. For practitioners, the lesson is that AI governance must be measured by enforced behaviour, not document completion.

Shadow AI is the predictable outcome when approved AI is either missing or unusable. The article describes the same behavioural pattern from three angles: no policy, inadequate approved tools, and overly rigid controls. In each case, users route around governance to stay productive. That is an access control problem as much as a security problem, because the organisation has created conditions where unsanctioned pathways are the easiest path to work.

Intent-based classification is a named control gap: keyword-based enforcement cannot understand AI purpose. Static detection was designed for inspectable artefacts, not conversational intent. When policy depends on keywords alone, the system misses legitimate high-risk interactions and over-blocks safe ones, which drives exception fatigue and bypass behaviour. The practical conclusion is that AI enforcement must classify context, not just content, if it is to remain usable in production.

Per-model governance is now part of identity governance, not a separate AI concern. The article shows that different models carry different data handling assumptions, and those assumptions affect who can use what, for which purpose, and under which conditions. That makes model-level policy a governance requirement rather than a tooling preference. Identity teams should treat model choice as an access decision with policy consequences, not as a neutral application detail.

The AI enforcement gap is already broadening the identity surface. The article explicitly includes both human employees and AI agents in the enforcement model, which means the control problem no longer stops at user authentication. As AI tools become part of daily execution, access decisions move from occasional approvals to continuous runtime mediation. Practitioners need to reframe AI policy as identity enforcement across people, tools, and agent-driven workflows.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• For the broader identity picture, Ultimate Guide to NHIs , Why NHI Security Matters Now explains why governance pressure rises as machine identity sprawl grows.

What this signals

AI enforcement will increasingly be judged like identity enforcement. If policy does not change runtime behaviour, it will be treated as theatre by both auditors and operators. For identity teams, that means approval lists, exceptions, and data handling rules now need to be enforceable in the same way access policies are enforced in other parts of the environment.

Intent-based enforcement is becoming the practical boundary between acceptable AI use and shadow AI. As more employees use conversational systems for real work, controls that cannot understand purpose will either under-block or over-block. The result is predictable: work shifts to unmanaged tools, and governance loses its effective perimeter.

AI policy is converging with broader non-human identity governance. The same discipline that manages access scope, runtime boundaries, and accountability for service accounts now has to extend into AI systems and agents. That makes governance architecture more important than policy wording, because the control plane, not the document, determines what can actually happen.

For practitioners

• Map AI policy to runtime control points Identify where policy must become enforceable at the moment of interaction, including browser-based tools, native apps, developer environments, embedded copilots, and agent-driven API calls. Use those touchpoints to define where allow, warn, block, and route decisions should occur.
• Replace keyword-only checks with intent-based review Classify AI usage by the purpose of the interaction, not just the literal prompt text. Prioritise controls that can distinguish legitimate business use from risky data sharing without relying on static patterns.
• Define policy scopes at multiple levels Set organisation-wide baselines first, then layer team, individual, and per-model rules on top so controls can match business context instead of forcing one standard across every use case.
• Measure shadow AI as an access outcome Track where users bypass approved AI tools because controls are too weak or too rigid. Treat that behaviour as a governance signal that your policy stack is not usable enough to sustain adoption.

Key takeaways

• AI policy fails when it remains a document instead of a runtime control layer.
• Legacy DLP and keyword matching cannot reliably govern conversational AI or prevent shadow AI.
• Layered, intent-aware enforcement across users and models is now a core identity governance requirement.

Key terms

• AI policy enforcement: The operational layer that turns written AI rules into technical controls at the moment of use. It governs which tools, data, and actions are allowed, warned on, blocked, or rerouted so the policy actually changes behaviour instead of remaining a document.
• Shadow AI: AI tools or agents used without organisational approval, visibility, or governance. It usually appears when sanctioned AI is missing, too weak, or too restrictive, and it becomes an identity problem because unmanaged access routes start to carry business data and decisions.
• Intent-based classification: A control method that evaluates why an AI interaction is happening rather than matching only the words in the prompt. It helps distinguish legitimate work from risky behaviour when the text itself looks ordinary, which is essential in conversational AI environments.
• Runtime control: A security control that acts while an interaction is happening, not after the fact. In AI governance, runtime control is what makes policy enforceable because it can inspect context, apply a decision, and shape the result before the AI response or data transfer completes.

Deepen your knowledge

AI policy enforcement and shadow AI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to turn written AI policy into enforceable runtime control, this is a useful place to start.

This post draws on content published by WitnessAI: AI policy enforcement and the gap between policy and runtime control. Read the original.