Security teams should shorten intake, define acceptable use for sensitive data, and provide sanctioned options that solve the same job-to-be-done. If the approved route is slower or less useful, employees will continue to hide the tools they use, and the organisation will lose both visibility and control.
Why delayed approvals push employees toward shadow AI
When people need a tool to finish work, they do not wait indefinitely for security to perfect the approved path. They either use a personal account, paste data into an unsanctioned service, or route the task through a browser extension or plugin the business never reviewed. That is why the response has to reduce friction quickly, not just raise the policy bar. A practical response is to make the sanctioned option good enough for the job-to-be-done, then tighten controls around what data can flow into it. Teams evaluating approved AI tooling can use an AI Security Platform Buyer’s Guide to compare guardrails, gateways, and evaluation criteria without defaulting to the loudest vendor claim.
The core operational issue is trust and usability, not merely policy awareness. If the approved route is slow, lacks needed context, or cannot handle common workflows, employees will work around it because productivity pressure beats abstract prohibition. Security teams should therefore treat AI enablement like an access and governance problem: define where sensitive data is allowed, what classes of prompts or uploads are prohibited, and what sanctioned alternatives exist for common use cases.
That is also why intake speed matters. If requests take weeks, the organisation effectively rewards bypass behaviour. Shortening the review path, pre-approving low-risk use cases, and publishing clear data-handling rules makes the approved channel more attractive than the shadow channel. Where the work involves agents or assistants acting on behalf of users, a policy template such as Agentic AI Security Policy Template can help teams formalise registration, ownership, human oversight, and retirement before the tool spreads informally.
What security teams need to control, not just approve
Approval alone does not solve the problem if the sanctioned tool still allows risky data movement. Security teams need to control three things at once: the data categories employees may enter, the integrations the tool can reach, and the level of authority the tool receives. That means separating ordinary productivity use from use cases involving source code, customer information, regulated data, secrets, or operational instructions. It also means making the approved service fit into existing identity, logging, and monitoring practices so the business can see how it is being used.
This is where sanctioned alternatives need to be genuinely useful. If the approved option cannot search internal material, summarize common documents, or support the workflows employees actually have, adoption will stall. An enterprise rollout should therefore pair policy with delivery, including the right guardrails, connectors, and monitoring. The practical lesson from Enterprise AI Copilot Security Guide is that oversharing, connector sprawl, and weak monitoring become the real control failures when AI is introduced faster than governance matures.
Teams also need to decide where human review is still mandatory. High-impact outputs, external messages, code changes, and decisions that affect customers or regulated records should remain review-bound even if routine drafting can be assisted. The aim is not to stop AI use, but to keep sensitive actions bounded, attributable, and easy to investigate.
How to make the approved route faster than the workaround
The best response is to remove the incentive to go around security. That means a short request path, a small number of standard approved options, and clear defaults for common business scenarios. Teams should predefine which models or tools are permitted for which data classes, which departments can use them, and what logging is required. If the approved route requires too much manual exception handling, employees will keep their own AI habits and security will only learn about them after a mistake or exposure.
Discovery also matters. You cannot govern what you cannot see, so teams should look for shadow AI through sanctioned account usage, OAuth grants, API keys, browser activity, and endpoint signals. If the company already has unsanctioned tools in circulation, the response should be to bring the common ones under review rather than pretending they do not exist. A discovery-led approach is well illustrated by the Shadow AI and AI Agent Discovery Guide, which focuses on finding unmanaged AI use and moving it into governance.
Once the common use cases are visible, security teams can build a better intake queue. Prioritise requests that unblock real work, pre-approve low-risk patterns, and reserve deeper review for sensitive integrations or high-privilege use. That sequencing reduces friction without abandoning control.
Risk and Threat Considerations
When approved AI options lag, the main risk is not simply policy non-compliance, it is data flowing into systems the organisation cannot supervise. That creates blind spots for sensitive content, model behaviour, retention, and downstream access, especially if employees reuse the same service across multiple tasks or accounts.
Failure mechanism: Workers adopt personal or unsanctioned tools to meet deadlines, then paste in proprietary, customer, or regulated data because the sanctioned path is too slow, too limited, or too hard to access.
Impact: The organisation loses visibility into where data went, what was retained, and what permissions or integrations the tool may have inherited, which increases exposure, complicates incident response, and weakens accountability.
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 and OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Employee AI tools can overreach when access and authority are too broad. |
| Recommendation — Restrict agent privileges and require bounded access for sensitive or external actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Shadow AI use often exposes sensitive data, tokens, or prompts outside approved controls. |
| Recommendation — Prevent secret and sensitive-data leakage by limiting inputs and monitoring tool usage. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity is authenticated and authorized commensurate with risk | Approved AI use needs risk-based access and authorization boundaries. |
| GV.PO-01 — Policy is established, communicated and enforced | The answer depends on clear acceptable-use policy for AI tooling and data handling. | |
| Recommendation — Apply risk-based authorization to approved AI tools and their data access paths. Define and enforce AI acceptable-use policy with clear data-handling rules. | ||
| ISO/IEC 27001:2022 | A.5.10 — Acceptable use of information and other associated assets | Employees need clear rules for approved and unapproved AI use. |
| Recommendation — Set acceptable-use rules for AI tools and the information they may process. | ||
| NIST AI RMF | GOVERN — Govern | The question is about AI governance choices that shape safe adoption. |
| Recommendation — Establish AI governance that balances productivity with guardrails and accountability. | ||
Practitioner Guidance
What to prioritise: Fix the highest-friction approved use cases first, especially the ones employees reach for daily. If the sanctioned tool does not solve the common job, the policy will not hold.
What to verify: Check that the approved route has clear data-class rules, logging, owner assignment, and a usable path for exceptions. If users cannot tell what is allowed in under a minute, the control is too hard to use.
Decision rule: If a requested AI use case handles sensitive information or can trigger external actions, require review and bounded permissions before rollout; if it is low risk and repetitive, pre-approve it with narrow defaults.
Practitioner takeaway: Security succeeds here when the sanctioned path is the easiest useful path, because convenience is what determines whether employees stay inside the control boundary.
Related resources from NHI Mgmt Group
- How should security teams handle risks from AI browser extensions?
- How should security teams govern API keys used for generative AI access?
- How should security teams stop AI agents from using approved tools to exfiltrate data?
- How should security teams implement an AI governance policy in environments where employees use multiple AI tools and personal accounts?