Shadow AI data leaks expose the limits of traditional DLP

At a glance

What this is: This is an analysis of how Shadow AI and GenAI tools create data leakage paths that conventional security tooling struggles to observe or control.

Why it matters: It matters because IAM, PAM, and data security teams now have to govern AI-linked access, OAuth permissions, and prompt-based data exposure as part of the same control plane.

👉 Read Strac's analysis of Shadow AI data leaks and GenAI protection

Context

Shadow AI creates a governance problem, not just a data loss problem. Employees can paste sensitive information into GenAI tools, connect those tools to SaaS systems, and move data through browser-based interactions that were never designed for conventional DLP inspection. In practice, that means identity, access, and data controls all become part of the same exposure surface.

The primary failure is not that AI tools exist, but that organisations often cannot see which tools are connected, what permissions they hold, or which prompts are carrying sensitive data. That intersection with IAM and NHI governance is real because many AI tools operate through OAuth grants, service integrations, and other delegated access patterns. This is now a typical enterprise pattern, not an edge case.

Key questions

Q: How should security teams govern shadow AI without blocking business productivity?

A: Start by identifying the identities and credentials behind AI use, then classify each one by data sensitivity, connected systems, and business purpose. Governance works best when organisations control the access path rather than banning the tool outright. That means inventory, approval, monitoring, and revocation all need to follow the same identity path.

Q: Why do AI systems create identity risk as well as model risk?

A: Because AI systems rarely act alone. They depend on service accounts, API tokens, cloud permissions, and data access paths, which means a model can behave safely while its identity layer is over-privileged. Treating AI risk as only a model problem misses the access surface where misuse and lateral movement usually begin.

Q: What do organisations get wrong about DLP for AI use cases?

A: They assume keyword matching can distinguish legitimate work from sensitive exfiltration. In practice, AI prompts are contextual, so the same text may be safe in one workflow and dangerous in another. Teams need policy that evaluates intent, destination, and action, not just strings.

Q: Who is accountable when shadow AI uses corporate credentials to process sensitive data?

A: Accountability sits with the identity owners, the platform owners, and the governance function that approved the underlying access. If a service account or OAuth app can reach regulated data and an AI feature uses that path, the organisation is responsible for the resulting exposure and audit trail.

Technical breakdown

Why browser-based GenAI activity bypasses traditional DLP

Traditional DLP was built around email, downloads, file transfers, and network inspection. Shadow AI breaks that model because the sensitive content often moves through copy-paste, web forms, and browser sessions rather than through a file object or a blocked attachment. Once a prompt reaches a public model, the enterprise loses visibility into what was shared and how it may be reused. The control gap is therefore both technical and governance-driven: the organisation does not just need detection, it needs policy enforcement at the point of interaction.

Practical implication: extend DLP to browser and prompt-level inspection, not just mail and file channels.

OAuth-connected AI tools turn data exposure into delegated access risk

Many AI tools do not expose data in isolation. They connect to Google Drive, Slack, Salesforce, GitHub, and other systems using OAuth permissions or SaaS integrations, then aggregate information across those systems in response to a prompt. That creates a delegated-access problem where the AI tool inherits the privileges of the user or application grant. From an identity perspective, the issue is not only the prompt content but the standing access behind the integration.

Practical implication: review OAuth grants and app scopes as part of AI data protection, not as a separate admin task.

Shadow AI changes the boundary between identity governance and data governance

AI assistants, copilots, and research tools increasingly sit inside normal work patterns, which means identity controls and data controls can no longer operate in separate silos. A user who is authorised to access data is not automatically authorised to export it into an external model through a prompt. That distinction matters because access entitlement does not equal safe disclosure. The governance requirement is to understand both the identity of the user and the effective data path created by the tool.

Practical implication: define policy for data use in AI tools the same way you define policy for privileged access and offboarding.

Threat narrative

Attacker objective: The attacker objective is to extract sensitive business data through ordinary-looking AI interactions without triggering the controls built for file theft or malware.

1. Entry occurs when an employee uses an unapproved AI tool or connects an approved one to internal systems through OAuth or browser integration.
2. Escalation happens when the tool can retrieve data from multiple SaaS sources and combine it into a single prompt response that exceeds the intended data boundary.
3. Impact follows when sensitive content such as customer lists, source code, or internal strategy is copied, shared, or retained outside the organisation's control.

NHI Mgmt Group analysis

Shadow AI is becoming a data governance issue before it becomes an AI governance issue. The first practical failure is visibility, because most organisations cannot inventory the tools employees use or the permissions those tools inherit. That aligns with the broader NHI problem of unmanaged delegated access. Practitioners should treat AI app discovery and prompt governance as part of the same control objective.

Prompt-level leakage creates a new class of data exfiltration that traditional DLP was never built to classify. A copied paragraph can contain customer records, source code, or internal strategy even when no file leaves the environment. This is a policy enforcement gap, not just a detection gap. Teams need controls that understand browser sessions, SaaS context, and sensitive content before it reaches the model.

Delegated AI access is a form of identity sprawl. Once an AI tool connects to email, files, or collaboration systems, the enterprise has created another persistent identity path that needs lifecycle control, scope review, and revocation. This is where IAM and NHI governance intersect directly with GenAI risk. Practitioners should review AI integrations as identity assets, not as convenience features.

Real-time data protection will matter more than post-event investigation in Shadow AI programmes. The article's core lesson is that once data is pasted into a prompt, incident response is already behind the event. That changes the security model from after-the-fact logging to inline prevention and redaction. Teams that cannot enforce controls at the moment of disclosure will keep discovering leaks too late.

Shadow AI exposure will force organisations to formalise acceptable-use boundaries for external models. Many programmes still assume that authorised users can decide how data is transformed once access is granted. That assumption is no longer safe. The practitioner conclusion is straightforward: AI adoption needs explicit data-use policy, scoped access, and continuous review of connected apps.

What this signals

Shadow AI will push security teams toward a combined identity and data control model. The practical signal for programmes is that AI app discovery, OAuth review, and sensitive-data policy enforcement now need to be managed together, not as separate tracks. Where available, reference the NIST Cybersecurity Framework 2.0 to anchor govern and protect functions around AI-connected data paths.

AI data leakage is increasingly a lifecycle problem. If an AI integration can be approved in minutes but remain connected for months, the organisation has created a long-lived identity exposure surface. That is why lifecycle review and revocation discipline matter as much as detection. The AI controls that hold up in practice are the ones that can revoke access as quickly as they grant it.

For practitioners

• Implement browser-level prompt inspection Inspect prompts and file uploads in the browser so sensitive data can be detected before it reaches external AI models. This is the only way to cover copy-paste and web-based interactions that do not produce traditional file-transfer signals.
• Audit OAuth permissions for AI-connected apps Inventory every AI app that connects to email, files, CRM, or collaboration platforms through OAuth. Remove over-broad scopes, revoke stale connections, and require approval for new integrations that can read or synthesize internal data.
• Classify sensitive content for GenAI policy enforcement Tag customer data, source code, internal strategy, and regulated records so prompt controls can block or redact them in real time. Classification is what makes automated enforcement possible at scale.
• Treat AI integrations as identity assets Track AI tools with the same lifecycle discipline used for service accounts and third-party access. Define owners, review cadence, and revocation procedures for every connection that can reach internal systems.

Key takeaways

• Shadow AI exposes sensitive information through normal user behaviour, which makes the problem easy to miss and hard to contain.
• The central governance gap is delegated access through AI-connected apps, not just prompt content or model choice.
• Programmes that combine browser inspection, OAuth review, and data classification will have a better chance of controlling GenAI leakage at the source.

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.
• GenAI DLP: GenAI DLP applies data-loss prevention controls to prompts, uploads, and outputs in AI tools. It treats interactions with LLM-based systems as data transfer events, which allows teams to detect, block, or warn when regulated content or secrets are being shared.
• 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.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.

What's in the full article

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

• How its Shadow AI detection methods identify unmanaged tools across browser and SaaS environments
• Which prompt inspection and redaction workflows it uses to stop sensitive data before model submission
• How it scores risk across connected AI apps so teams can prioritise the highest-exposure integrations
• The specific visibility indicators it uses to show which users are interacting with GenAI tools most often

👉 The full Strac article covers Shadow AI discovery, prompt monitoring, and real-time prevention workflows.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity controls to broader security and data protection programmes.