Shadow AI is outpacing enterprise controls and SOC visibility

At a glance

What this is: Shadow AI is the unsanctioned use of AI tools for work, and Panther argues it is already creating visibility and control gaps that traditional shadow IT controls do not cover.

Why it matters: IAM, SOC, and AI governance teams need a way to see personal-account use, OAuth grants, and agent activity before sensitive data and delegated access escape normal oversight.

By the numbers:

• About 45% of employees are regular AI users on corporate devices.
• 67% of those users are accessing AI platforms through personal accounts your security team can't see.
• 97% of organizations that experienced an AI-related security incident lacked proper AI access controls, and 63% had no AI governance policies at all.

Context

Shadow AI is a governance problem because work is now flowing through AI systems that were never brought under the same approval, logging, and access controls as sanctioned enterprise tools. The issue is not only unsanctioned software use. It is the combination of identity blind spots, delegated access, and data movement into systems that can retain, reuse, or reshape content outside normal oversight.

For identity and security teams, the hard part is that shadow AI rarely looks like a single malicious action. It can begin with a personal account, an OAuth grant, an extension, or an API key, then spread into telemetry sources that sit in different teams and different tools. That makes early discovery and cross-source correlation more important than reactive blocking.

The article treats shadow AI as a current operational condition, not a future risk, and that is consistent with what many enterprise environments are already seeing.

Key questions

Q: What breaks when shadow AI is not part of the asset inventory?

A: When shadow AI is absent from inventory, security teams cannot apply policy, logging, access review, or remediation to the workload. That means the service may process sensitive data and expose credentials without ever entering the governance process, which turns discovery into a control boundary, not just a reporting issue.

Q: Why do personal AI accounts create so much risk in enterprise environments?

A: Personal accounts bypass enterprise identity controls, so security teams lose visibility into who authorised access, what scopes were granted, and whether the session can be revoked. They also separate the data trail from the user’s corporate identity, which makes investigation, containment, and audit evidence much harder.

Q: How do organisations know if shadow AI detection is working?

A: Detection is working when alerts are tied to real identities, duplicate noise is reduced, high-risk events reach the right owners, and executives can see consistent reporting. The control should produce auditable evidence, not just notifications. If the programme cannot support governance decisions, it is still only visibility.

Q: How should organisations govern autonomous AI agent actions separately from human sessions?

A: Treat the agent as a governed execution identity with its own permissions, logs, and guardrails. Human authentication does not prove the agent should be able to call tools or modify systems. Governance has to distinguish who started the workflow from what the agent is authorised to do at runtime.

Technical breakdown

How shadow AI enters through identity and authorization paths

Shadow AI is not just a browser habit. It becomes a security issue when employees use personal AI accounts, authorize third-party apps with broad OAuth scopes, or connect AI tools to SaaS data stores and developer environments. Those paths create access outside the enterprise control plane, which means the organisation may never see the original consent or the downstream data movement. In practice, the authentication event and the data-use event are separated. That breaks the usual assumption that approved network access equals approved use. For identity teams, the problem is authorization drift, where a valid token or consent grant becomes an unmanaged channel into enterprise data.

Practical implication: trace AI exposure back to identity events, not just traffic destinations, and treat OAuth grants as part of access governance.

Why local telemetry misses browser extensions and AI copilots

Browser extensions, IDE plug-ins, and embedded copilots sit close to the user and often below the line of sight of proxy-only monitoring. Some activity never leaves the endpoint in a form the network stack can easily classify, while other activity looks like ordinary HTTPS traffic to whitelisted AI domains. That means the SOC can see a destination but not the context, or it can see a process but not the data being sent. When AI tooling is embedded into development or productivity workflows, the risk is not only shadow IT. It is identity-linked execution inside trusted endpoints, where secrets, source code, and internal documents can be exposed through normal user actions.

Practical implication: combine endpoint, proxy, and identity telemetry so extension and copilot use cannot hide inside approved device activity.

What autonomous AI agents change about the control model

AI agents are different from ordinary apps because they can request credentials, act across multiple systems, and take multi-step actions without human approval at each step. That makes them an identity and privilege problem as much as a data problem. If an agent has its own credentials, the risk is not only that it can see data. It can also chain actions, pivot between services, and leave fewer human-visible cues than a user-driven session. Traditional controls built around static users and fixed approval paths do not map cleanly to this behaviour. The control point moves toward issuance, scope, and runtime oversight rather than later review.

Practical implication: govern agent credentials as non-human identities with explicit scope, short lifetime, and monitored action boundaries.

Threat narrative

Attacker objective: The objective is to obtain or influence enterprise data and decisions through AI access paths that sit outside normal monitoring and approval.

1. Entry occurs when employees use personal accounts, unsanctioned AI apps, browser extensions, or AI agents outside approved channels.
2. Credential and authorization abuse follows when OAuth grants, API keys, or embedded access let the tool reach enterprise data and services.
3. Impact appears as data exposure, policy violations, and higher breach cost when sensitive content is processed outside governed controls.

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.
• Samsung ChatGPT leak 2023: Samsung staff pasted chip source code and meeting notes into ChatGPT weeks after it was allowed, leading Samsung to restrict generative AI tools.

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 an identity governance problem, not only a shadow IT problem. The article shows that the material risk is no longer just unsanctioned software use. It is the combination of personal accounts, delegated OAuth consent, and unmanaged AI agents operating outside normal approval paths. Practitioners should treat identity-linked AI usage as a governance domain in its own right, with explicit inventory, approval, and review controls.

Identity blind spots are the real control gap behind shadow AI. Network blocking alone cannot distinguish a sanctioned enterprise AI session from a personal account or a delegated integration. That means the governing question is not whether AI traffic exists, but whether the enterprise can tie usage back to a trusted identity, an approved purpose, and a monitored scope. Practitioners should close the gap by correlating identity provider logs, OAuth grants, and endpoint activity.

AI agents sharpen the NHI governance problem because their access can be operational, not episodic. A human user can be reviewed after the fact, but an agent can request, use, and discard privilege inside one task flow. That makes conventional access review weaker unless the enterprise governs agent identity at issuance time. Practitioners should treat autonomous AI access as a non-human identity lifecycle problem, not a user behaviour issue.

Shadow AI creates governance debt when organisations ban tools instead of mapping use cases. Blanket prohibition pushes activity into personal accounts and unmanaged channels, which reduces observability and increases downstream incident cost. The more durable model is controlled enablement with AI governance, inventory, and access review. Practitioners should assume the demand will persist and design for visibility, not denial alone.

Shadow AI exposure should be measured as a control maturity issue, not just a user policy issue. The article's figures point to a broad failure of access governance and policy coverage, not a handful of isolated exceptions. That means the programme question is whether the enterprise can actually see, approve, and revoke AI use at scale. Practitioners should align shadow AI controls with NIST AI RMF governance and operational oversight expectations.

From our research library:

• Organisations with high levels of shadow AI faced an average of $670,000 in additional breach costs compared with those with little or none, according to IBM's 2025 Cost of a Data Breach Report.

What this signals

Shadow AI exposure is now a telemetry problem as much as a policy problem. Security teams need identity provider, DNS, proxy, SaaS, and endpoint evidence in the same detection workflow or they will keep missing the join between who used the tool and what data moved through it.

AI agents change the operating assumption behind access reviews. Review processes assume privilege is visible long enough to be certified, but agent-driven actions can request, use, and release access inside a single task. That means governance has to shift toward issuance-time control and runtime traceability.

Discovery has to be continuous because sanctioned and unsanctioned AI usage blur together. The same domains and providers may carry approved enterprise use and personal-account use, so control design has to separate identity, device, and authorization context before any blocking decision is made.

For practitioners

• Map AI usage to identity events Correlate AI endpoints, OAuth grants, and identity provider audit logs so personal accounts and delegated access are visible in the same workflow.
• Inventory sanctioned and unsanctioned AI access Build an inventory of approved AI tools, browser extensions, API integrations, and local copilots, then flag anything outside the approved list.
• Treat AI integrations as governed access paths Require approval, scope review, and periodic recertification for AI app authorizations that can reach mail, files, code, or internal knowledge systems.
• Monitor endpoint activity for local AI tooling Use endpoint telemetry to detect copilots, plug-ins, and installed extensions that bypass network-only controls and can access sensitive work data.
• Adopt short-lived, scoped agent credentials For autonomous AI agents, assign the minimum necessary scope and a defined lifetime, with logging that supports traceability after each task completes.

Key takeaways

• Shadow AI is creating a control gap because employees are using personal accounts, OAuth grants, extensions, and agents outside normal enterprise oversight.
• The article ties that gap to material business impact, including higher breach costs and weak access governance in organisations that already experienced AI incidents.
• The practical answer is not blanket blocking alone but continuous discovery, identity-linked telemetry, and governed approval paths for both human users and AI agents.

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.
• 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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps security and identity practitioners build the governance model needed for AI agents, workloads, and service access.