Shadow AI’s Real Threat Is Access Control

The first wave of enterprise AI concern was straightforward. It was simply employees pasting sensitive data into public AI tools. Security teams responded with usage policies, domain blocks, and data loss prevention rules. That response made sense at the time.

It doesn’t fit the problem anymore.

Shadow AI has shifted from a data leakage concern to an access control problem. The threat isn’t about what employees type into AI tools. It’s about which AI agents are running inside the organization, what enterprise systems they’re connected to, and what actions they’re authorized,or not, to take.

From passive tools to active actors

Employees and business units are building AI agents at a pace most security teams can’t keep track of. Custom assistants, coding agents, workflow automations, and agentic applications are being created across departments with some in sanctioned platforms, but many through browser extensions, SaaS-native features, developer tools, MCP servers, endpoint-based agents, and custom scripts. Many start as quick experiments. Some become embedded in critical business processes within days.

The risk profile of these agents is fundamentally different from traditional shadow IT. An unsanctioned SaaS application is a destination for data. An AI agent is an actor that can call APIs, use stored credentials, retrieve records, modify configurations, trigger downstream workflows, and take actions in production systems, often without a human explicitly authorizing each step.

An employee pasting a customer record into a public AI tool is a data leakage incident. A custom AI agent connected to Salesforce, Snowflake, GitHub, Gong, and Slack is an access control incident waiting to happen. It could expose data, but it could also perform read, write, and delete actions on that data. It may also run on service accounts with permissions nobody audited and stay active six months after the employee who built it changed roles or left the company. New research from Token Security and the Cloud Security Alliance maps exactly how widespread this exposure has become. 

Why existing controls don’t reach it

Most enterprise security controls were designed for human identities and deterministic workloads. IAM policies, DLP rules, and network monitoring assume predictable behavior and defined access paths. AI agents break those assumptions.

An agent tasked with resolving a failed deployment might read logs, query monitoring systems, modify infrastructure configurations, open tickets, trigger automation pipelines, and notify engineering teams, all in sequence, all using the same inherited credentials. To avoid breaking workflows, developers grant broad permissions upfront. Those permissions accumulate. Agents inherit creator-level privileges, temporary access becomes permanent, and security and identity teams lose visibility into what those identities are actually doing.

Blocking public AI domains doesn’t reach any of this. By the time an agent has…