What is the difference between shadow AI and approved SaaS AI usage?

Shadow AI is AI use that the organisation has not inventoried, sanctioned, or controlled, while approved SaaS AI usage has been reviewed, policy-bound, and assigned an accountable owner. The difference is not just preference. It is whether identity, data, and retention controls exist before the AI can touch corporate information.

Why This Matters for Security Teams

shadow ai and approved SaaS AI usage can look similar from the outside because both may involve employees pasting prompts, uploading files, or calling an LLM through a browser. The security difference is control plane visibility. Approved use has an inventoried service, an owner, policy, and data handling rules. Shadow AI bypasses those guardrails, which means the organisation may not know what data left the perimeter, what retention applies, or which identity was used.

That distinction matters because AI services often absorb secrets, customer data, or internal context faster than teams expect. NHIMG research on the State of Secrets in AppSec shows that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases. That concern is not abstract when tools are unsanctioned. It is also why guidance from the NIST Cybersecurity Framework 2.0 still starts with asset visibility, governance, and protective controls before trusting a digital service.

In practice, many security teams discover shadow AI only after sensitive material has already been exposed through a prompt, plugin, or unmanaged browser session, rather than through intentional review.

How It Works in Practice

Approved SaaS AI usage should be treated like any other business service that can process corporate data. The organisation defines who may use it, what data classes are allowed, whether prompts are logged, where outputs may be stored, and how retention works. The key is not simply approval. It is the presence of accountable ownership, identity binding, and enforceable policy.

Shadow AI fails this test because it has no reliable inventory entry, no documented processor controls, and no assurance that tokens, uploads, or prompts are protected by corporate terms. That is where breach patterns become relevant. The Salesloft OAuth token breach illustrates how quickly externally reachable access paths can be abused once credentials are in play, while the DeepSeek breach shows how exposed datasets and embedded secrets can create a much larger blast radius than the original mistake suggests.

Operationally, teams should distinguish between:

• sanctioned SaaS AI with SSO, logging, DPA review, and data minimisation rules
• unsanctioned browser AI use with no approved tenant, no retention review, and no data classification enforcement
• embedded AI features inside approved SaaS products, which still need a review of data flows and model training terms
• AI tools used by contractors or business units that may have their own identity and retention settings

The decision point is whether the organisation can prove who used the service, what data entered it, and how long that data persists. Current guidance suggests aligning this control set with zero trust and identity governance principles, and mapping service onboarding to the NIST Cybersecurity Framework 2.0 and service-provider due diligence. These controls tend to break down when users can reach consumer AI tools from unmanaged devices because policy cannot reliably inspect or restrict the session.

Common Variations and Edge Cases

Tighter AI approval often increases friction for employees, so organisations have to balance speed against control. That tradeoff is real, especially when business teams adopt new tools faster than security can review them. Best practice is evolving here, and there is no universal standard for every AI use case yet.

Some edge cases blur the line between shadow and approved usage. A sanctioned SaaS AI product can still become a risk if a user enables a personal account, uploads confidential files outside the approved tenant, or installs a plugin that forwards prompts elsewhere. Likewise, a tool may be approved for generic drafting but not for regulated data, source code, or customer records. Approved status is therefore conditional, not absolute.

Another common gap is assuming that browser controls alone solve the problem. They do not. If a user can copy data into a personal account, use an unmanaged extension, or route work through a private subscription, the organisation still loses governance. For that reason, teams often pair SaaS review with user education and DLP, but policy must remain the primary control.

For deeper context on how credential misuse and hidden access paths lead to AI exposure, see NHIMG analysis of the BeyondTrust API key breach and the Snowflake breach. Those incidents reinforce the same lesson: if identity and retention are not controlled up front, “approved” usage can still behave like shadow AI in practice.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?