Shadow AI and shadow IT expose a third-party risk gap

At a glance

What this is: Shadow IT and shadow AI are framed as invisible third parties whose real risk comes from unsanctioned access to data that conventional TPRM never inventories.

Why it matters: IAM, PAM, NHI, and third-party risk teams need discovery mechanisms that start from actual usage and data movement, because review processes cannot govern what they never see.

Context

Shadow IT and shadow AI are governance problems before they are tool problems. Unsanctioned SaaS apps and AI services can touch sensitive data, sit outside procurement, and never enter the normal third-party review path, so the control failure is visibility rather than questionnaire quality.

In identity and access terms, these tools behave like unmanaged third parties with latent permissions and weak oversight. The article is strongest when it shows that discovery must move from vendor registers to real data flows, because that is where unsanctioned access becomes visible.

Key questions

Q: What is the difference between shadow IT and shadow AI?

A: Shadow IT is the use of unapproved software, while shadow AI is the use of unapproved or unmanaged generative AI services and embedded copilots. Shadow AI is harder to govern because it often hides inside sanctioned SaaS tools and can move data into external model systems without obvious signs.

Q: Why do shadow AI tools create more risk than sanctioned SaaS apps?

A: Shadow AI bypasses procurement, security review, and entitlement design, so it often enters with broad access and no clear accountability. Even when the tool is well intended, the absence of an owner and review cadence means the organisation cannot reliably enforce data handling, access control, or revocation.

Q: What are the signs that shadow app governance is failing in an organization?

A: The clearest signs are employees logging into unauthorized SaaS tools, app usage appearing outside sanctioned IT review, and teams lacking a reliable list of active applications. If access decisions cannot be enforced or even observed consistently, the organization is losing control of SaaS sprawl. That usually means visibility, ownership, and access enforcement are all lagging behind adoption.

Q: How should security teams govern shadow AI without slowing adoption?

A: Start with continuous discovery, then classify tools by data access, system connectivity, and provider trust. Use policy thresholds that allow low-risk use cases quickly while forcing review, restriction, or blocking for tools that can reach sensitive systems. The control objective is to make safe adoption fast and unsafe adoption expensive.

Technical breakdown

Why questionnaire-first TPRM misses shadow IT and shadow AI

Traditional third-party risk management assumes a vendor is known before it is assessed. That works for sanctioned suppliers, but shadow IT and shadow AI break the model because they are adopted outside procurement, often through free tiers, personal logins, or browser-based use. A questionnaire cannot reduce risk when the tool is absent from the inventory. The operational problem is not assessment depth, but discovery completeness. Real governance starts by identifying where data is actually flowing, then deciding whether the tool should be sanctioned, restricted, or blocked.

Practical implication: Shift discovery upstream to real usage telemetry before asking for vendor attestations or security questionnaires.

Why data-flow discovery is the right control plane

Data-flow discovery treats the movement of sensitive data as the source of truth. Instead of asking who was approved, it asks which tools are actually receiving customer records, source code, or other sensitive content, and who is using them. That matters because shadow AI can ingest data into third-party models in ways users cannot see, while shadow SaaS can silently create a persistent access path. The control objective becomes inventory, triage, and governance from observed activity, not from self-reported adoption.

Practical implication: Use data-centric discovery to rank shadow tools by the sensitivity of the data they touch.

How shadow AI changes third-party risk boundaries

Shadow AI collapses the line between third-party risk and AI governance. An AI note-taker, chatbot, or coding assistant is not just an application choice. It is a third party that may receive prompts, files, and context that were never intended for external processing. That creates a governance gap around delegated data exposure, especially when employees paste in customer or code content without review. The key shift is that risk now sits in the interaction between user behaviour, data sensitivity, and unmanaged external processing.

Practical implication: Treat shadow AI as both a third-party risk and a data governance issue, not as a standalone productivity exception.

Threat narrative

Attacker objective: The attacker objective is to gain durable access to sensitive enterprise data through an unmanaged third party that security teams never formally assessed.

1. Entry occurs when employees adopt unsanctioned SaaS or AI tools outside procurement and normal review paths.
2. Credential or data exposure follows when those tools receive customer data, source code, or other sensitive content through user-driven uploads and pasting.
3. Impact emerges when unmanaged third parties retain, process, or expand access to that data beyond the organisation's oversight boundary.

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.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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 now a third-party risk inventory problem, not just an AI policy problem. The article is strongest where it shows that unsanctioned tools bypass procurement and therefore bypass the controls that traditional TPRM relies on. If the tool is not in the vendor register, the questionnaire never happens and the review never starts. The practitioner conclusion is that visibility must come first, because governance cannot scale from an incomplete list.

Data-flow discovery is the missing control plane for shadow third parties. A vendor list tells you what has been approved; observed data movement tells you what is actually in use. That distinction matters for identity governance because access can be real even when approval is absent, especially in browser-based SaaS and AI services. The practical lesson is to anchor third-party risk decisions in live usage and data sensitivity, not in procurement artefacts.

Shadow AI creates governance debt by compressing adoption and exposure into the same user action. Pasting data into a chatbot or enabling an AI extension can create third-party exposure instantly, before any assessment or containment decision is possible. That changes the governance model from preventive onboarding to continuous discovery and triage. The practitioner implication is to make discovery continuous, because point-in-time approvals will always trail user behaviour.

Third-party risk and AI governance are converging at the data layer. The same unmanaged tool can be a supplier, an access path, and an AI processing boundary at once. That convergence means separate control owners will miss the full picture unless they share a common view of data exposure and tool usage. The field should therefore move toward a unified view of external access, with unmanaged AI treated as a first-class vendor risk.

Shadow third-party exposure is a governance blind spot, not an exception process failure. Teams often assume the issue is that employees bypass policy, but the deeper failure is that the control architecture only sees approved vendors. That is why unmanaged SaaS and AI are so resilient as risks. The practitioner takeaway is to design for discovery of the unknown first, then apply policy.

From our research library:

• 63% of organisations surveyed lacked AI governance policies to manage AI or prevent shadow AI, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Shadow third-party discovery is now a programme requirement, not a monitoring enhancement. Teams that rely on procurement-driven inventories will continue to miss the tools that matter most, because the riskiest services are often the ones users adopt first. The operational shift is to build discovery around observed data movement, then route findings into vendor governance and access control.

Shadow AI widens the identity boundary around external processing. Once a user can paste sensitive data into a model or extension, the external service effectively becomes part of the data access path. That means identity, privacy, and third-party risk teams need a shared view of who or what is processing data outside the enterprise boundary.

Governance debt accumulates fastest where approval and use diverge. The more a tool can be adopted without procurement, the more likely it is to escape periodic review. Practitioners should expect this pattern to intensify as AI assistants and browser extensions become easier to deploy across the workforce.

For practitioners

• Implement continuous shadow-tool discovery Monitor SaaS, browser, endpoint, and cloud usage to identify unsanctioned tools from actual activity instead of periodic surveys.
• Triage tools by the data they touch Score each discovered tool by the sensitivity of data observed in transit, with customer PII and source code treated as highest priority.
• Convert useful shadow tools into managed vendors Promote approved tools into the formal vendor review path so they receive contract, security, and AI governance coverage.
• Redact sensitive data before external AI use Apply controls that strip or mask sensitive content before prompts, uploads, or browser-based AI interactions reach third-party models.

Key takeaways

• Shadow IT and shadow AI are third parties in practice, but they evade traditional onboarding and therefore escape the controls that depend on a known vendor list.
• The core failure is discovery, not questionnaire quality, because unmanaged tools can already be touching sensitive data before anyone in security knows they exist.
• Continuous data-flow monitoring, triage by sensitivity, and formal review for useful tools are the controls most likely to close the gap.

Key terms

• Shadow IT: Shadow IT is the use of applications or services outside formal enterprise approval or visibility. In SaaS environments, it often includes department-purchased tools and unsanctioned integrations that create hidden identity, data, and access paths the security team cannot readily govern.
• 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 risk management: Third-party risk management is the process of identifying, assessing, monitoring, and reducing risk introduced by external vendors and service providers. In identity terms, it governs who outside the organisation can reach systems or data, how that access is approved, and when it must be removed.
• Data-Flow Discovery: Data-flow discovery is the practice of identifying which tools, services, and systems are actually moving or processing sensitive data. It is more reliable than static inventories when users adopt tools outside procurement, because it surfaces real access rather than assumed approval.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners connect access governance to the wider control model their programmes depend on.