What breaks when organisations only track approved SaaS apps and ignore shadow AI usage?

Why This Matters for Security Teams

Tracking only approved SaaS creates a false sense of control. The risk is not limited to software procurement; it extends to everyday worker behaviour, where employees may paste sensitive text into public AI chat tools, connect browser extensions, or move data through personal accounts. That creates governance gaps around data handling, retention, and access review, especially when the organisation cannot prove where information went or who could retrieve it later.

This matters because shadow ai often bypasses the controls already in place for sanctioned applications. Security teams may have CASB, SSO, or endpoint controls in place, yet still miss unmanaged AI usage if they only watch an approved catalog. Current guidance suggests treating AI-assisted workflows as part of the enterprise attack surface, not as a niche productivity issue. The control question is not whether an app is on the list, but whether it can receive, store, or transform regulated content outside approved process.

For control baselines, the NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful because it ties monitoring, data protection, and access enforcement to operational evidence. In practice, many security teams encounter shadow AI only after sensitive content has already been exposed through a browser session, rather than through intentional discovery of the workflow.

How It Works in Practice

Effective discovery starts with workflow visibility, not just application inventory. Teams need to understand where users interact with AI services, what data types are entered, and whether the service is sanctioned, personal, or embedded in another tool. That includes direct prompts, file uploads, browser-based summarisation tools, and extensions that can read page content or clipboard data. Logging approved SaaS use alone will not surface these paths.

A practical approach usually combines multiple signals:

• CASB or secure web gateway telemetry to identify AI service domains and upload patterns.
• Endpoint and browser controls to detect extensions, local clients, and copy-paste activity tied to sensitive files.
• Identity and access telemetry to correlate usage with user, device, and session context.
• Data classification rules so the organisation can distinguish harmless experimentation from regulated or confidential content exposure.

For AI-specific governance, NIST AI Risk Management Framework helps structure the problem around mapping, measuring, and managing risks created by AI use, including unapproved usage paths and third-party dependencies. MITRE ATLAS is also relevant when the concern extends to adversarial manipulation of AI workflows, prompt injection, or data extraction through model interactions. When organisations need a practical policy layer, OWASP guidance on agentic and AI-driven systems can help define what acceptable use looks like in tool-using environments.

The operational goal is not to block every unsanctioned tool immediately. Best practice is evolving toward tiered response: detect, classify, then decide whether to approve, restrict, or prohibit based on the data involved and the business need. These controls tend to break down in bring-your-own-device environments because browser visibility, local storage, and unmanaged accounts reduce telemetry quality.

Common Variations and Edge Cases

Tighter discovery often increases monitoring overhead and user privacy sensitivity, requiring organisations to balance visibility against employee trust and local regulatory constraints. The right response is not identical across all environments.

In regulated industries, shadow AI becomes a records, privacy, and retention issue as much as a security issue. In customer support, finance, or legal teams, a single prompt can contain personal data, contract terms, or privileged material, which means the organisation may need stronger controls than a general office worker population. In engineering teams, the bigger risk may be code snippets, API keys, or architecture diagrams entering external AI services.

There is no universal standard for this yet, but current guidance suggests building policy around content sensitivity, not just application name. That means defining what can never be entered into external AI, what requires approved enterprise AI, and what may be used only inside controlled environments. Where organisations use agentic AI or tool-enabled assistants, the identity question becomes more serious: unmanaged AI usage can create untracked non-human activity that looks like a normal user session but behaves like an autonomous actor.

Useful next steps often include pilot discovery of browser-based AI usage, legal review of data transfer rules, and exception handling for sanctioned experimentation. For broader control mapping, teams may also align AI usage discovery with governance practices in the NIST control catalog and AI risk baselines from NIST AI Risk Management Framework.

Related resources from NHI Mgmt Group

• What is the difference between shadow AI and approved SaaS AI usage?
• What breaks when security teams only track approved and unapproved AI apps?
• What breaks when organisations cannot see shadow AI usage?
• What breaks when organisations rely on surveys or spreadsheets to track AI and MCP usage?