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

At a glance

What this is: This is an analysis of why unsanctioned SaaS and AI tools create a third-party risk problem that conventional review workflows miss.

Why it matters: It matters because IAM, data security, and third-party risk teams need a way to govern tools that access sensitive data without ever entering the normal vendor lifecycle.

👉 Read Strac's analysis of shadow IT and shadow AI as third-party risk

Context

Shadow IT and shadow AI become a governance problem when tools are adopted outside procurement, because they can still access corporate data, systems, and user workflows. The core failure is visibility, not intent: if a tool is unknown, it cannot be reviewed, classified, or governed through the normal third-party process. For identity teams, that means the boundary between sanctioned access and unmanaged access is increasingly defined by data flow rather than contract status.

The article sits at the intersection of third-party risk management, data security, and AI governance. It also has a genuine identity angle because many of these tools are accessed through user credentials, OAuth connections, or personal logins, which makes access oversight and lifecycle control part of the problem. That makes shadow AI especially relevant to NHI governance, where ephemeral tokens and unmanaged app consents can create persistent exposure without a formal owner.

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: How do security teams measure whether shadow-tool governance is working?

A: Look for discovery coverage, consent visibility, and remediation speed. If the organisation can identify unknown tools, map what data they touch, and remove or control risky access quickly, governance is functioning. If tools keep reappearing without ownership, the programme is still reactive.

Q: Who is accountable when a sanctioned AI tool causes a data breach?

A: Accountability should sit with the owner of the identity and permissions behind the tool, not only the team that approved the application. If a sanctioned AI workflow can reach sensitive data, the organisation must govern its access path, logging, and containment as rigorously as any other high-risk identity.

Technical breakdown

Why questionnaire-first TPRM misses shadow IT and shadow AI

Traditional TPRM starts with a vendor list, then sends questionnaires and collects attestations. That process works only when the organisation already knows the third party exists. Shadow IT and shadow AI break the model because they enter through personal sign-ups, free tiers, browser extensions, or embedded AI features, so they never reach the assessment queue. The control failure is upstream discovery, not downstream review. In practice, that means the risk is invisible until data leaves the environment.

Practical implication: replace list-based vendor intake with continuous discovery from usage, identity, and data-flow signals.

How data-layer discovery changes third-party governance

Data-layer discovery flips the control model from asking vendors what they do to observing what tools actually touch. That matters because sensitive data movement is a stronger indicator of exposure than procurement status. If a chatbot touches customer records, source code, or internal documents, it is functionally a governed third party even if no one formally approved it. This is where identity and data governance meet: access via OAuth, browser sessions, and API connections must be tied back to what data those permissions can reach.

Practical implication: classify tools by the data they access, then govern the permissions and identities that enable that access.

Shadow AI creates unmanaged model exposure and retained context risk

Shadow AI is riskier than conventional shadow IT because the data does not just sit in a SaaS tenant. Users may paste sensitive material into a model context, after which the organisation can lose control over how that content is stored, reused, or exposed through downstream prompts and integrations. The key technical issue is retained context, not just transmission. That makes redaction, token scoping, and application-level guardrails more relevant than blanket bans, especially where AI features are embedded into everyday workflows.

Practical implication: control sensitive input before it reaches AI tools and treat model context as a governed exposure surface.

Threat narrative

Attacker objective: The attacker objective is to exploit invisible third-party access paths to capture sensitive data or persist in trusted workflows without triggering normal security review.

1. Entry occurs when an employee adopts an unsanctioned SaaS app, AI assistant, browser extension, or personal-login workflow that bypasses procurement and review.
2. Credential or access abuse follows when the tool is connected through OAuth consent, reused passwords, API keys, or broad user permissions that were never scoped for formal oversight.
3. Impact occurs when the tool receives sensitive data, creates unreviewed third-party exposure, or becomes a path for data loss that the organisation cannot easily detect or reverse.

NHI Mgmt Group analysis

Shadow AI is now a third-party risk problem, not just an adoption problem. Unsanctioned AI tools can sit outside procurement while still handling sensitive data, which means the classical TPRM model fails at the discovery stage. Security teams that treat approval as the starting point are already behind the actual access path. The practitioner conclusion is simple: governance must begin where data moves, not where vendor paperwork begins.

Data-flow visibility is the decisive control boundary for unmanaged tools. A questionnaire can only assess a third party that is already known, but shadow tools are defined by their absence from the known set. That is why discovery from identity events, browser activity, and data movement is more durable than inventory-by-declaration. For identity programmes, this also means OAuth grants and personal logins need lifecycle governance, not just periodic review. Practitioners should align TPRM and IAM around observed access, not claimed ownership.

Shadow AI creates an unmanaged context-retention problem that existing access controls do not model well. The data is not merely transferred to another service. It can be retained in prompts, embeddings, logs, or downstream workflows where the organisation has limited visibility. Shadow context retention: the silent persistence of sensitive data inside AI interactions after the original user action ends. This is a governance gap across AI security, DLP, and identity oversight, and it requires practitioners to control input, permissions, and auditability together.

Identity governance must expand from account control to application-consent control. Many shadow tools arrive through user-approved connections rather than centrally provisioned accounts, so access reviews alone miss the real exposure. OAuth visibility, token lifecycle, and app-scoped permissions become the new control plane for unsanctioned tools. The practitioner conclusion is to treat delegated access as part of identity governance, not a separate shadow IT problem.

The market is moving toward continuous exposure discovery rather than periodic vendor review. That shift is visible wherever organisations are forced to reconcile procurement, data governance, and AI usage in the same workflow. Traditional TPRM is still necessary, but it is no longer sufficient for cloud and AI ecosystems where tools can appear instantly and disappear just as fast. Practitioners should expect governance programmes to converge on live discovery, risk scoring, and automated sanctioning decisions.

What this signals

Shadow AI pushes third-party governance toward a continuous discovery model, because the main failure is no longer review quality but the inability to see what has been adopted in the first place. For identity teams, that means OAuth grants, personal logins, and delegated app access should be treated as part of the governance surface, not just a convenience layer.

Shadow context retention: the real challenge is not simply that employees use unsanctioned AI, but that sensitive data can persist inside prompts, logs, or downstream integrations beyond the original user action. Practitioners should pair discovery with inline redaction, consent review, and token lifecycle control, using OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 as governance anchors.

The practical implication for security programmes is that TPRM, IAM, and DLP can no longer operate as separate workstreams when AI tools are adopted ad hoc. Teams need a shared inventory of connected apps, a common risk score based on data sensitivity, and a fast path to sanction, restrict, or remove high-exposure tools before they become embedded in daily workflows.

For practitioners

• Implement continuous discovery of unsanctioned tools Monitor SaaS, browser, endpoint, and cloud usage to find tools that touch sensitive data before they appear in vendor registers. Prioritise tools with customer data, source code, or regulated records.
• Triage shadow tools by data sensitivity Separate low-risk collaboration tools from tools touching PII, payment data, secrets, or internal IP. Use the data type, not the popularity of the app, as the first risk filter.
• Govern OAuth and delegated access as identity risk Review app consents, token scopes, and third-party connectors alongside human and non-human identity controls. Revoke broad or unused grants and require lifecycle ownership for every connected app.
• Redact sensitive data before AI submission Apply DLP or inline redaction so users can use AI tools without exposing full records, credentials, or confidential documents. Make redaction the default for high-risk content classes.
• Re-scan shadow tools on a continuous cycle Assume shadow IT and shadow AI will reappear as employees adopt new tools, extensions, and models. Schedule recurring discovery and remediation so governance does not depend on one-time cleanup.

Key takeaways

• Shadow AI and shadow IT create a third-party risk gap because they can access sensitive data without ever entering the normal vendor review process.
• The strongest signal in this article is visibility failure, not questionnaire failure, and that is why data-flow discovery matters more than procurement lists.
• Practitioners should govern delegated access, redact sensitive inputs, and continuously rescan for unmanaged tools if they want control to keep pace with adoption.

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.
• 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.
• Data-Layer Discovery: Data-layer discovery is the practice of finding and classifying tools by observing actual data movement rather than relying on vendor lists or self-declarations. It is especially useful for shadow IT and shadow AI because it reveals what the tool touches, who uses it, and how sensitive the exposure is.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

What's in the full article

Strac's full article covers the operational detail this post intentionally leaves for the source:

• How its data-layer discovery identifies shadow IT and shadow AI from real usage patterns rather than vendor declarations
• How the risk scoring logic distinguishes customer PII, source code, and lower-risk collaboration data
• How to promote a discovered tool into a managed vendor with review, assessment, and document collection
• How the same detection engine supports GenAI and MCP data security workflows

👉 The full Strac article covers discovery methods, data-layer triage, and the governance workflow for unmanaged tools.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader governance problems created by shadow access and unmanaged applications.