Shadow AI turns unreviewed vendor use into third-party risk

At a glance

What this is: Panorays argues that shadow AI becomes a third-party risk problem when unapproved tools handle enterprise data outside approved vendor review and retention controls.

Why it matters: IAM, NHI, and third-party risk teams need to treat AI usage as an access and data-governance issue, because the control boundary now extends beyond employees to vendors and their embedded AI dependencies.

By the numbers:

• unapproved AI tools figured in 43% of security incidents, more than double the share a year earlier

Context

Shadow AI is no longer just a policy enforcement problem inside the enterprise. When an unapproved AI tool receives customer data, proprietary code, or support tickets, it creates an unmanaged external data flow that sits outside normal vendor review, retention, and access controls.

The governance gap matters because the risk is not limited to direct employees. Third-party users, SaaS features, and downstream model providers can all move sensitive data into AI services that the buying organisation never assessed, which makes the issue relevant to IAM, NHI governance, and third-party risk programmes.

Key questions

Q: What is the failure mode when shadow AI is treated only as an employee policy issue?

A: The failure mode is that sensitive data leaves the organisation through unreviewed external services while governance teams look only at user behaviour. That misses supplier usage, embedded AI features, retention terms, and downstream model providers. Once the data is outside the approved inventory, standard policy enforcement cannot recover visibility or accountability.

Q: Why does shadow AI create third-party risk even when the supplier was already approved?

A: Approval at onboarding only covers the service that was reviewed at the time. If the supplier later adds copilots, browser tools, or model APIs, data can move into AI processing paths that were never assessed. The risk comes from hidden processing changes after approval, not from the original vendor relationship alone.

Q: What are the signs that an AI vendor is not being governed effectively?

A: Common warning signs include unclear data use terms, no visibility into what data the model consumes, weak answers on training rights or retention, and no process for ongoing review after launch. Another red flag is a growing shadow AI footprint, where employees adopt tools outside procurement. If the team cannot explain who uses the tool and how it behaves, governance is already behind.

Q: How should organisations govern AI usage when employees use unapproved tools?

A: Organisations should start with visibility, not enforcement. If teams cannot see which apps, agents, or workflows are being used, they cannot assess data exposure or apply meaningful controls. Once usage is mapped, policy can shift from blanket bans to context-based decisions that reflect sensitivity, role, and business purpose.

Technical breakdown

Why shadow AI becomes a third-party exposure

Shadow AI changes the trust model the moment enterprise data leaves an approved control plane and enters a tool no one inventory-reviewed. In practice, that can happen through browser assistants, public chatbots, embedded SaaS features, or a vendor employee pasting customer data into a model to speed up work. The governance problem is not only that the tool is unsanctioned, but that it creates a new processor, a new retention path, and a new access path without review. That is why standard acceptable-use policy language is too narrow: the real question is whether the organisation can name every external service that now receives its data.

Practical implication: discover and classify unapproved AI data flows as third-party relationships, not just policy violations.

How vendor AI features extend the data path

Vendor-shipped AI features can hide an additional dependency behind an already approved supplier. A CRM or support platform may expose summarisation, classification, or copilot functions that rely on a model provider the customer never contracted with directly. That means the organisation’s review covered the front-line supplier, but not necessarily the model operator, retention terms, or downstream access conditions. This is a supply chain issue as much as an AI issue, because the risk rides in through product updates and feature enablement rather than explicit procurement. Once the model relationship exists, it should be treated as part of the vendor’s processing chain and assessed accordingly.

Practical implication: require suppliers to disclose embedded AI dependencies and data-processing paths in contract and risk review.

Why AI governance has to reach beyond internal controls

Internal AI policy, training, and allow-listing matter, but they only cover what the organisation directly controls. The blind spot appears when the same behaviour happens inside a supplier environment or through a supplier’s own AI tooling, because that activity is invisible to standard employee-focused governance. From an identity and access perspective, the issue is that data now flows through relationships where access was granted for one service but reused for another purpose. That makes governance less about banning tools and more about knowing which external identities, services, and model paths can touch sensitive information.

Practical implication: extend AI governance to suppliers, including contract terms, disclosure obligations, and reassessment triggers.

Threat narrative

Attacker objective: The practical objective is to move sensitive enterprise data into an external AI service that the organisation cannot name, assess, or govern.

1. Entry occurs when a user, employee, or vendor worker pastes enterprise data into an unapproved AI tool or an embedded AI feature.
2. Credential or data access is then granted to a service that was never reviewed through normal onboarding or vendor assessment.
3. Escalation follows when that same tool becomes a repeat data sink, creating persistent exposure to content, prompts, and outputs outside the organisation’s inventory.
4. Impact is the loss of visibility and control over sensitive data stored or processed by an unknown AI service or downstream model provider.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is a third-party risk problem before it is a user-behaviour problem. The decisive issue is not whether someone broke policy, but that enterprise data entered an external service without vendor review, retention visibility, or access accountability. That shifts the governance burden from awareness training to third-party discovery, contract terms, and ongoing reassessment. Practitioner conclusion: treat unapproved AI use as unmanaged supplier exposure.

Embedded AI features create the new supply chain blind spot. Organisations often review the front-line SaaS provider and stop there, even when the product routes data to a separate model operator the buyer never sees. That is a governance gap in the processing chain, not merely a missing checkbox in procurement. Practitioner conclusion: require downstream AI dependency disclosure as part of vendor due diligence.

Third-party AI governance fails when it assumes approval equals containment. A supplier can be approved at onboarding and still begin processing data through browser tools, copilots, or model APIs that sit outside the original risk decision. This is why continuous vendor oversight matters more than one-time assessment. Practitioner conclusion: re-evaluate approved suppliers whenever AI functionality changes.

Unapproved AI use should be mapped to a named control concept: shadow AI data spillover. That concept captures the point where unsanctioned tooling, supplier behaviour, and hidden model dependencies combine to move sensitive data beyond the organisation’s control boundary. It is a governance failure in visibility, not just a policy failure in compliance. Practitioner conclusion: build control language around data spillover paths, not just prohibited tools.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Shadow AI data spillover: the real governance failure is the unreviewed transfer of sensitive data into external AI services that were never part of the approved vendor inventory. IAM and third-party risk teams should treat these flows as access pathways, not just misuse events.

The practical programme shift is toward continuous supplier discovery, disclosure of embedded model dependencies, and reassessment whenever AI features change. That aligns with the broader control logic behind vendor oversight and identity-aware access governance, where the question is always who can touch the data and under what terms.

For practitioners

• Expand third-party reviews for AI processing paths Update supplier assessments to ask whether customer, employee, or support data can be routed into public chatbots, embedded copilots, or external model APIs.
• Inventory supplier AI features and dependencies Require vendors to disclose browser extensions, summarisation tools, model providers, and any AI functionality added after onboarding.
• Reclassify shadow AI as data transfer risk Treat unapproved AI use as an external data flow problem, with retention, access, and disclosure questions in the review record.
• Add AI change triggers to contract monitoring Trigger reassessment when a supplier enables new AI features, changes model providers, or alters data handling terms.

Key takeaways

• Shadow AI becomes materially different once unapproved tools or embedded features start processing enterprise data outside the approved supplier inventory.
• The governance gap is visible in the scale of the issue, with 43% of security incidents involving unapproved AI tools and nearly seven in ten breached organisations lacking AI governance.
• The most effective control response is to extend third-party reviews, contract disclosure, and continuous monitoring to AI-enabled supplier processing paths.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Third-party AI risk: Third-party AI risk is the exposure created when external vendors embed AI into products, services, or workflows that an organisation relies on. The risk includes hidden model changes, unclear data handling, training use, and shifting control boundaries that can invalidate earlier assessments.
• Embedded Model Dependency: An embedded model dependency is a downstream AI service that a vendor uses to deliver a feature, even though the buyer does not contract with or inventory that provider directly. This matters because the real processing chain can extend beyond the reviewed supplier boundary.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance and machine identity security, the industry's only accredited NHI security programme. It helps practitioners connect identity control with the wider access risks created by AI-driven supplier workflows.