Employees use unapproved AI tools when the sanctioned path is slower, less useful, or disconnected from how they actually work. Fear of falling behind makes the behaviour rational from the user side. Security teams need to reduce friction, not just increase penalties, if they want compliant adoption.
Why This Matters for Security Teams
Unapproved AI use is not just a policy exception. It is a governance gap that can expose sensitive data, create shadow workflows, and bypass review of model outputs, retention, and access. The real problem is usually misalignment: if a sanctioned tool is slower, less capable, or hard to reach, employees will route around it. That creates risk across data handling, legal exposure, and account control, especially when prompts include customer data, source code, or internal plans.
Security teams often focus on blocking access, but the better question is whether the approved path is actually usable in day-to-day work. The NIST Cybersecurity Framework 2.0 is useful here because it links governance, risk, and operational controls rather than treating policy as a standalone artifact. In practice, many security teams encounter shadow AI only after sensitive data has already been entered into a public tool, rather than through intentional policy compliance.
How It Works in Practice
Employees adopt unapproved AI tools when they perceive a clear productivity gain and a low chance of immediate consequence. That can happen even in mature environments if approved tools lack key features, require too many approvals, or do not fit common tasks like drafting, summarising, coding, or searching internal knowledge. Good controls therefore combine enablement, guardrails, and detection.
Operationally, this usually means treating AI use like any other controlled technology domain:
- Define which data classes may be entered into AI tools, and which are prohibited.
- Provide an approved path that is fast enough to compete with consumer tools.
- Set logging and monitoring expectations for prompts, uploads, and output use where feasible.
- Use role-based access, procurement review, and acceptable use rules together rather than separately.
- Review third-party AI terms for training, retention, and data residency before broad rollout.
NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant because it maps well to access control, auditability, system configuration, and data protection requirements. Security teams should also understand the workflow reality: if a model is embedded in a browser extension, personal account, or mobile app, it may sit outside normal enterprise logging and identity controls. That is where policy often loses to convenience.
Best practice is to pair awareness with practical control points in browsers, SaaS gateways, endpoint policy, and identity governance, then measure whether users are actually moving to the approved service. These controls tend to break down when employees work across unmanaged devices and personal accounts because the organisation loses visibility before policy enforcement can start.
Common Variations and Edge Cases
Tighter AI controls often increase friction, requiring organisations to balance confidentiality against speed, usability, and business demand. There is no universal standard for every AI use case yet, so current guidance suggests risk-tiering rather than treating all tools the same.
For example, a low-risk public chatbot used for grammar help is very different from a model that processes source code, customer records, or regulated content. In regulated environments, approved AI services may need stronger review, logging, and contract terms, while lower-risk internal use can often be governed with lighter controls and explicit usage boundaries. The challenge is that employees rarely classify their own task correctly in the moment.
Some teams also assume that banning tools solves the problem, but bans often push usage underground. A more durable approach is to publish clear allowed-use scenarios, make the approved alternative easier to access, and define what happens when employees need an exception. In practice, adoption improves when the sanctioned tool is the path of least resistance, not the path of maximum paperwork.
Where the issue intersects with identity governance, the concern is not just the tool itself but who can use it, what account they use, and whether enterprise controls apply to that session. That is why AI access decisions should sit alongside identity, endpoint, and data governance instead of being treated as an isolated policy memo.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | AI policy failures are a governance and risk management issue. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege limits who can use sensitive data in AI workflows. |
Treat unapproved AI use as a governed risk with defined ownership, review, and escalation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
