What breaks when Shadow AI is handled only as a procurement issue?

Why This Matters for Security Teams

When shadow ai is treated only as a procurement problem, the control point arrives too late. The real risk is not just whether a tool was bought, but whether employees have already granted OAuth access, installed browser extensions, or connected SaaS data before anyone reviewed the supplier. That creates a live identity and data exposure problem, not a purchase approval problem. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to identify and govern assets continuously, not only at contracting time.

NHI Management Group has documented how quickly hidden integrations can turn into exposure, including the Vercel Context.ai OAuth Supply Chain Breach, where access paths mattered more than procurement paperwork. The operational lesson is simple: if the browser, identity provider, and SaaS tenant are already connected, the security event has already happened, even if procurement never saw a request.

Security teams also miss the speed of secret exposure. In NHIMG research, The State of Secrets in AppSec found that the average estimated time to remediate a leaked secret is 27 days, which is far longer than the time it takes for an unsanctioned AI workflow to start handling sensitive content. In practice, many security teams encounter Shadow AI only after OAuth tokens, browser plug-ins, or shared prompts have already expanded access beyond what procurement approved.

How It Works in Practice

Procurement-only governance assumes the main decision is vendor selection. For Shadow AI, the decisive controls sit earlier and much closer to the user: browser sessions, identity grants, data permissions, and runtime usage. A user can sign into an AI tool with corporate SSO, approve broad scopes, paste sensitive material, and connect downstream services without any formal purchase ever occurring. That is why current guidance increasingly treats Shadow AI as a combined identity, data, and endpoint issue rather than a sourcing issue.

The practical response is to monitor and govern the access paths that make unsanctioned AI useful. That includes OAuth app inventories, browser extension controls, SaaS connected-app reviews, CASB or SSE visibility, and DLP policies that inspect prompts and file transfers. It also means classifying AI tools by the privileges they request, not just by whether they were approved by procurement. In a mature program, procurement becomes one input to risk review, while identity governance handles the actual exposure surface.

• Inventory AI usage from identity logs, browser telemetry, and SaaS admin consoles.
• Review OAuth consent scopes and revoke high-risk third-party access quickly.
• Restrict browser extensions and unsanctioned copilots that can read page content.
• Apply data-loss controls to prompts, uploads, and connector-based exports.
• Require security review for AI tools that request tokens, inbox access, or file-system access.

This is where the DeepSeek breach is instructive: once secrets and sensitive records are embedded in AI-adjacent workflows, the problem is no longer procurement discipline but containment, revocation, and remediation speed. These controls tend to break down in browser-first workforces with self-service SaaS onboarding because users can create durable access paths before the security team sees a vendor record.

Common Variations and Edge Cases

Tighter procurement control often increases operational friction, requiring organisations to balance speed of innovation against visibility and revocation. That tradeoff becomes sharper when teams use personal accounts, trial subscriptions, or embedded AI features inside already-approved SaaS products. In those cases, the vendor may be approved, but the AI feature or connector is not, which means procurement data is an incomplete signal.

There is no universal standard for Shadow AI classification yet. Some organisations treat it as software sprawl, others as data leakage, and others as identity abuse. Best practice is evolving toward an activity-based view: if the tool can see corporate data, authenticate with enterprise identity, or automate actions on behalf of a user, it belongs in governance even if no purchase exists. That approach aligns more closely with the NIST Cybersecurity Framework 2.0 than a classic vendor approval workflow.

One common edge case is “approved platform, unapproved capability.” Another is employee-managed AI through personal email and browser sync, where corporate controls are bypassed until a data incident exposes the path. In those situations, procurement cannot explain the exposure because the exposure was created by runtime consent and data movement, not by buying.

Related resources from NHI Mgmt Group

• Should organisations treat shadow AI as a security risk or an innovation issue?
• What breaks when AI identities are handled outside IAM?
• What breaks when shadow AI is not included in identity governance?
• What breaks when AI agent access decisions are handled in prompts?