Shadow AI is already causing security incidents

At a glance

What this is: This is a survey-led analysis showing that shadow AI is already producing security incidents, with unauthorized tool connections and weak access governance as the central issues.

Why it matters: It matters because AI tool governance now sits inside IAM, NHI, and cloud access control decisions, not just policy documents, and practitioners need visibility before OAuth or API grants become standing access.

By the numbers:

• 46% of organisations had an employee connect an unauthorized AI tool directly to corporate systems, according to DNSFilter.
• 20.1% said that connection caused a security incident, according to DNSFilter.

Context

Shadow AI is an access-control problem as much as an AI governance problem. Once an unapproved tool receives OAuth, API, or account-level access to corporate systems, it can read, move, and retain data outside normal review workflows, which makes the security boundary the moment of authorisation rather than the moment of use.

DNSFilter's survey data suggests that most organisations have already crossed from theoretical policy debate into operational exposure. The practical issue is that approval, inventory, and detection processes are not keeping pace with how quickly employees can connect AI tools, especially where the tool looks like an ordinary SaaS integration or browser extension.

Key questions

Q: What breaks when shadow AI agents appear on corporate endpoints without oversight?

A: The break point is governance visibility. Endpoint agents can inherit non-human identities, API keys, OAuth apps, and cloud credentials outside approved lifecycle control, so access exists before security teams can inventory, review, or certify it. The result is unmanaged reach into SaaS and cloud systems, not just an unmanaged application on a laptop.

Q: Why does shadow AI create more risk when organisations try to prohibit it?

A: Prohibition often shifts usage underground, which reduces visibility and weakens logging, data control, and accountability. Once employees move to hidden tools, the organisation loses the ability to see which identities are active or what information is being exposed. That makes the risk harder to detect and more expensive to remediate.

Q: What are the signs that rogue AI governance is failing?

A: Look for unapproved tools, unknown OAuth grants, users pasting sensitive content into external services, and AI-enabled workflows that security cannot inventory or revoke. If the organisation cannot say which tools can access which data, governance is already lagging the actual exposure surface.

Q: What should organisations do when AI systems have more access than they need?

A: They should reduce privileges before broad deployment and verify each tool, data set, and SaaS connection against the task the AI actually performs. Excess access turns a model error into an enterprise incident. The safest posture is least privilege with explicit review of every delegated capability.

Technical breakdown

Why OAuth and API grants turn shadow AI into standing access

Shadow AI becomes materially risky when an AI tool is granted OAuth or API access, because the grant is not just a one-time action. It authorises the tool to act under the user or service account's permissions until it is revoked, which makes it function like a non-human identity with inherited access. That shifts the problem from prompt misuse to access governance: the tool can read mail, files, code, or records without each individual action being separately approved. In practice, the identity of the tool matters as much as the behaviour it performs.

Practical implication: treat every AI integration request as an identity and privilege event, not a convenience setting.

Why policy fails without visibility at connection time

An AI policy only works if the organisation can see when a tool is being attached to a system. The article shows that many teams rely on user reporting or notice the issue only after access is already live, which means enforcement happens after the exposure window opens. That is a classic governance failure: policy documents describe what should happen, while authorisation controls determine what actually happens. For shadow AI, the relevant control point is the connection event, not the later incident review.

Practical implication: move enforcement to the approval and connection layer, where the access decision is made.

Why shadow AI often disappears inside tool sprawl

Shadow AI rarely arrives as a clearly labelled rogue system. It blends into existing SaaS, browser, and automation inventory, especially where employees already use multiple AI tools and some are embedded in approved applications. That makes discovery difficult because the surface is fragmented across personal accounts, sanctioned apps, OAuth grants, and ad hoc browser extensions. The governance challenge is therefore not only blocking unknown tools, but maintaining an accurate inventory of what AI-connected access paths already exist and who approved them.

Practical implication: inventory AI-connected access paths the same way you inventory service accounts and third-party integrations.

Threat narrative

Attacker objective: The objective is persistent, low-friction access to corporate data through an unapproved AI integration that looks ordinary to users and hidden to IT.

1. Entry occurs when an employee connects an unauthorized AI tool to corporate systems through OAuth, API access, or a personal account.
2. Credential or token abuse follows because the tool inherits the user's access scope and can operate without each action being individually reviewed.
3. Impact appears when the tool reads, stores, or moves corporate data and the organisation discovers the exposure only after an incident or user report.

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.

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 an identity governance problem before it is an AI policy problem. The article shows that the first security decision happens when a tool receives OAuth or API access, not when the model generates output. That means the real control boundary is entitlement issuance, approval, and revocation, which places shadow AI squarely inside IAM and NHI governance. Practitioners should treat AI tool onboarding as an access lifecycle event, not a usage preference.

A policy without connection-time visibility creates a false sense of control. DNSFilter's figures point to a gap between written rules and enforcement at the moment users grant access. If the organisation cannot see or block the connection before standing access exists, policy becomes an after-the-fact audit artefact. The practical conclusion is that visibility and enforcement must sit at the point of grant.

Standing AI access behaves like an unmanaged non-human identity. Once granted, the tool can continue operating under delegated permissions even when the original user is not actively supervising it. That makes the risk pattern similar to long-lived service account exposure, except the entry path is often consumer-like and invisible to security teams. The governance failure is not merely shadow usage, but unattended delegation.

Shadow AI is also a discovery problem that traditional inventories miss. Tools show up as browser extensions, embedded SaaS features, or one-click integrations, which means normal application registers and procurement lists undercount the real surface. Discovery has to move closer to the network and access layer so that unauthorised AI connectivity is visible before it becomes a breach scenario.

Visibility deficits now define the AI control debate. Organisations that can only react to user reports are effectively accepting delayed detection as a design choice. For identity and security teams, the priority is to reframe AI governance around access provenance, approved integrations, and revocation speed. If those controls are absent, the organisation is governing intent rather than actual access.

From our research library:

• Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Shadow AI now behaves like an unmanaged access channel, not just an unapproved productivity habit. Once an AI tool can reach corporate systems through OAuth or API scope, the governance question becomes who owns the entitlement lifecycle and how quickly it can be revoked. Teams that cannot answer that question are already running blind on non-human access.

Access visibility must move earlier than the incident window. A 20-percentage-point increase in security incidents among organisations that rely heavily on static credentials is a reminder that fixed access paths carry measurable risk, and delegated AI access is no different in principle.

Shadow AI also sharpens the boundary between policy and enforcement. The article's central lesson is that written approval rules do little if users can create real access before review. Security programmes should therefore pair AI governance with identity controls, network discovery, and revocation workflows that work at connection time.

For practitioners

• Implement connection-time approval for AI tools Require explicit approval before any AI tool receives OAuth, API, or account-level access to corporate systems. Make the approval workflow part of identity governance so that delegated access cannot be self-granted without review.
• Inventory all AI-connected access paths Build a live inventory of browser extensions, embedded SaaS AI features, personal-account chatbots, and third-party integrations that can reach mail, files, or code repositories. Reconcile that inventory against actual grants, not just procurement records.
• Monitor the first DNS connection for unapproved tools Use DNS-layer telemetry to flag new AI domains and agent endpoints as soon as they resolve, because that is often the earliest observable sign of an unsanctioned connection.
• Revoke standing access when AI use is no longer required Remove tokens and integrations that are no longer actively needed, and treat revocation as part of the same lifecycle as approval. Long-lived delegated access is the condition that turns casual use into durable exposure.

Key takeaways

• Shadow AI becomes a real security issue when it receives delegated access to corporate systems, because the resulting permissions can outlive the moment of approval.
• The survey data shows that incidents are already occurring, which means governance gaps are no longer hypothetical in AI adoption programmes.
• The practical control failure is visibility at grant time, so teams need approval and revocation workflows that operate before access becomes standing access.

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.
• 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.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the wider security programme they run.