By NHI Mgmt Group Editorial TeamPublished 2026-04-28Domain: Agentic AI & NHIsSource: Lasso Security

TL;DR: AI Usage Control is emerging as a distinct governance layer because traditional network, endpoint, and legacy DLP controls cannot inspect real-time AI interactions with enough context, according to Lasso Security. The practical issue is not whether organisations allow AI, but whether they can govern prompt-time use, data sharing, and output reuse without collapsing existing IAM assumptions.


At a glance

What this is: AI Usage Control is a runtime governance layer for AI interactions, and the key finding is that traditional security controls lack the context needed to manage prompt-time risk.

Why it matters: It matters because IAM, NHI, and human identity programmes now have to govern live AI use, not just static access, if they want to prevent data leakage and audit gaps.

By the numbers:

👉 Read Lasso Security's guide to AI usage control for enterprise security teams


Context

AI usage control is the practice of governing how people use AI tools while they are in active workflows. The article argues that this is a missing control layer because existing IAM, endpoint, and DLP tools were built for access decisions and post-event detection, not for prompt-time policy enforcement.

For identity teams, the relevance is broader than GenAI hygiene. Once AI features are embedded in browsers, copilots, and extensions, governance has to account for live interactions, role context, data sensitivity, and output handling across human users, connected services, and emerging non-human workflows.


Key questions

Q: How should security teams govern AI usage without blocking productivity?

A: Security teams should set context-aware rules that vary by role, data type, and task risk, then enforce them at runtime inside the interaction. That approach preserves low-risk use while preventing sensitive data from being shared or reused casually. Blanket blocks usually fail because users route around them.

Q: Why do traditional IAM and DLP controls fall short for GenAI?

A: They were designed for static access and post-event detection, not for live prompts, context injection, and output reuse. GenAI risk often emerges in the middle of a workflow, where intent and data sensitivity matter more than simple allow-or-deny decisions. That is why a usage-layer control is needed.

Q: What do organisations get wrong about Shadow AI governance?

A: They treat Shadow AI as a discovery problem when it is also a behaviour problem. Finding an unsanctioned tool does not stop users from sharing prompts, documents, or outputs through it. Governance has to pair continuous discovery with enforceable rules at the point of use.

Q: Who should be accountable for AI usage policy violations?

A: Accountability should sit with the identity and control owners who can enforce the policy, but business leaders must own the risk decisions for sensitive workflows. If the organisation cannot explain who approved the use case, who monitored it, and who can stop it, the control is not operational.


Technical breakdown

Runtime policy enforcement for AI interactions

AI usage control sits between traditional access governance and data loss prevention. Instead of deciding only whether a user may open an application, it evaluates what happens inside the session: prompt content, contextual data, tool type, and the inferred intent behind the action. That matters because GenAI risk is often created by legitimate users in legitimate workflows, not by obvious abuse. The control point is the live interaction layer, where policy can block, redact, warn, or require approval before sensitive information leaves enterprise control.

Practical implication: security teams need enforcement points that can inspect AI interactions in real time, not just inventories and allowlists.

Why static allowlists fail for shadow AI and copilots

Traditional security architectures assume applications and boundaries are relatively stable. AI use breaks that assumption because adoption spreads through browsers, extensions, embedded copilots, and personal work habits that security teams often do not see in advance. A static allowlist can approve a tool, but it cannot reliably govern how that tool is used once users begin sharing prompts, files, or generated content. The result is a gap between approved software and approved behaviour, which is where Shadow AI becomes operational rather than theoretical.

Practical implication: discovery has to run continuously, because usage changes faster than approval workflows can keep up.

Data classification and output governance in GenAI workflows

AI usage control is not only about stopping sensitive data from going in. It also has to govern what comes out and how it is reused. In practice, that means aligning classification rules with prompt inspection, output handling, redaction, and review requirements for high-risk tasks. The article correctly frames this as a governance problem, not just a filtering problem. If users can paste restricted data into a chatbot or repurpose model output without verification, the organisation has not controlled usage, only logged the event after the fact.

Practical implication: classification rules must be applied at interaction time and tied to both input and output handling.


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 usage control is the missing runtime layer between access governance and data protection. The article describes a category that sits inside live workflows, where traditional IAM and DLP controls have weak visibility. That framing is correct because the risk is behavioural, not just perimeter-based. Practitioners should treat AI usage control as a governance layer that closes the gap between permission and actual use.

Shadow AI is now a governance problem, not just an inventory problem. Users can adopt browser assistants, copilots, and embedded AI features faster than approval workflows can track them. That makes discovery necessary but insufficient, because the real failure mode is unsanctioned behaviour becoming routine before security teams can intervene. Practitioners should assume adoption will be decentralized and design controls that can keep up with that pace.

AI usage control redefines what “least privilege” means in an AI context. The policy target is no longer only system access, but what an identity may do with prompts, context, and outputs in a specific moment. That extends identity governance into the usage layer without collapsing it into broad blocking. Practitioners should re-evaluate whether their current access model can express intent, sensitivity, and task scope at runtime.

Identity programmes will need to govern AI use across human, service, and workflow identities. The article starts from human productivity use cases, but the same governance logic will spread into automated workflows and NHI-backed integrations. That means access review, logging, and policy exceptions will increasingly need to describe how AI is used, not only who signed in or which app was approved. Practitioners should prepare for cross-domain governance rather than siloed AI policy.

AI usage control is becoming the practical test of whether AI governance is real. Many organisations already have policy language, but policy without runtime enforcement does not change risk. The market is moving toward controls that can observe, classify, and act during the interaction itself. Practitioners should measure whether their governance can operate at the moment of use, not only at deployment or audit time.

From our research:

  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
  • 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
  • For the broader control model, see Top 10 NHI Issues, which shows why inventory and rotation problems keep resurfacing.

What this signals

AI usage control will become a governance benchmark for organisations that already struggle with hidden identity and secret sprawl. The same control gaps that leave secrets in code and config files will also leave AI usage undocumented if policy stays at the document level. Organisations that cannot enforce behaviour at runtime will find that discovery alone does not create governance evidence.

Runtime enforcement is the key distinction between AI policy and AI control. If an organisation can only describe acceptable use after the fact, it has a policy programme, not a control programme. That distinction matters for auditability, because regulators and internal risk teams will increasingly ask for evidence of enforced decisions rather than written intent.

AI usage control should be aligned with established identity and zero trust models, not treated as a standalone tool category. The operational question is whether identity context, data sensitivity, and session behaviour can be evaluated together in the moment. For teams building that model, the NIST Cybersecurity Framework 2.0 remains a useful organising reference for govern, protect, detect, and respond functions.


For practitioners

  • Map AI usage points across the workflow layer Inventory browser assistants, copilots, extensions, and embedded AI features that employees actually use, then tie each one to identity context and data sensitivity. Keep the mapping current because usage changes quickly.
  • Define runtime rules for prompt-time data handling Classify which data types may be submitted, masked, redacted, or blocked before they enter an AI interaction. Align the rules to role and task context so that low-risk use stays possible while sensitive material is protected.
  • Extend access reviews beyond applications to AI behaviours Review not only which tools were approved, but how they are being used, what outputs are reused, and which exception paths are active. This makes governance evidence match actual operational risk.
  • Integrate AI controls with identity and logging systems Connect AI usage controls to IdP attributes, classification labels, and audit logs so that enforcement can explain why an interaction was allowed or blocked. That linkage is what makes governance defensible in audits and investigations.

Key takeaways

  • AI usage control addresses the gap between approved access and actual AI behaviour inside live workflows.
  • The strongest evidence in the article is that organisations need runtime enforcement because static controls cannot keep pace with shadow AI and embedded copilots.
  • Practitioners should shift from tool approval thinking to interaction governance, where prompts, context, and outputs are controlled as part of the identity model.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10AI usage control governs live AI interactions and prompt-time risk.
NIST CSF 2.0PR.AC-4Role and context-based access decisions support AI usage governance.
NIST Zero Trust (SP 800-207)AC-4Context-aware policy enforcement mirrors zero trust decisioning for AI use.

Apply continuous verification to AI sessions and evaluate sensitivity before data is shared.


Key terms

  • AI Usage Control: AI Usage Control is the practice of governing how AI tools are used during live work, not just whether they are approved. It applies policy at the point of interaction so teams can inspect prompts, data context, and outputs before risk leaves the enterprise boundary.
  • Shadow AI: Shadow AI is AI software or features used without security, legal, or governance oversight. In practice it includes browser assistants, copilots, extensions, and embedded AI features that enter workflows informally and create risk because their use is invisible to standard inventory and approval processes.
  • Runtime Enforcement: Runtime enforcement is control applied while an action is happening, rather than before deployment or after an incident. For AI governance, that means deciding in the moment whether a prompt can proceed, be redacted, be warned on, or be blocked based on identity and data context.
  • Prompt-time Data Exposure: Prompt-time data exposure is the risk that sensitive information is shared with an AI model at the moment a user submits input. Unlike classic data transfer events, this happens inside an ordinary workflow and can be accidental, making context-aware policy and inspection essential.

Deepen your knowledge

AI usage control and runtime governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-driven workflows, it is worth exploring.

This post draws on content published by Lasso Security: Comprehensive Guide to AI Usage Control for Enterprise Security Teams. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-04-28.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org