Shadow AI is now an access control problem, CSA and Token Security say

For most of the last two years, enterprise AI security conversations have centered on one fear. An employee pastes a customer record, a piece of source code, or a sensitive prompt into ChatGPT, and the data ends up somewhere it shouldn't. That fear was real. The response, in the form of usage policies, browser DLP rules, and public AI domain blocks, made sense at the time.

According to a joint research report from the Cloud Security Alliance and Token Security, that response is no longer aimed at the right problem. Shadow AI has shifted from a data leakage concern to an access control problem. The threat is no longer what employees type into AI tools. The threat is which AI agents are running inside the organization, which enterprise systems they are connected to, and what actions they are authorized, or not authorized, to take.

The new report, titled "Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises," draws on a survey of 418 IT and security professionals. It paints a picture of an enterprise environment where AI agents are being built and deployed faster than security teams can catalog them, and where the access patterns those agents inherit look very little like the patterns that traditional identity and access management systems were designed to handle.

The Hacker News summarized the underlying report on June 19, 2026, in an article titled "Forget Data Leakage: Shadow AI's Real Threat Is Access Control." The article is a direct read on the gap between how fast agents are being built inside companies and how slowly the access governance model is catching up.

The shift from data leakage to access control

The shift from a data problem to an access problem is a meaningful one. The previous mental model treated AI tools as destinations for data, and the security job was to keep sensitive data from reaching those destinations. The new mental model treats AI agents as actors inside the enterprise. They are software identities 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 individual step. The boundary the agent can reach is the access boundary, not the data destination boundary.

Employees and business units are building these agents at a pace most security teams cannot keep up with. The list of where these agents live is long, and most of the items on it are not under the direct control of the central security team. Custom assistants, coding agents, workflow automations, and full agentic applications are being created across departments. Some live in sanctioned platforms. Many run 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. None of them wait for a security review.

The risk profile is fundamentally different from traditional shadow IT. An unsanctioned SaaS application is a destination for data. An AI agent is an actor that can take action on data. The same 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.

What shadow agents actually inherit

That inheritance is the part that breaks most existing security controls. Most enterprise security controls were designed for human identities and deterministic workloads. IAM policies, DLP rules, and network monitoring all assume predictable behavior and well-defined access paths. AI agents break those assumptions in two ways at once. The access they are granted tends to be broad, because developers want to avoid breaking workflows by hitting narrow permission boundaries. The behavior they exhibit is non-deterministic, because the model can pick tools and sequences in ways the original author did not enumerate.

The combination produces a situation that security teams have not had a category for until now. 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.

The Token Security and CSA report frames the practical response as a six-question inventory exercise rather than a tool deployment. Discovering shadow AI requires looking across the environments where agents actually live, including AI platforms, SaaS apps with built-in automation, cloud accounts, developer tools, endpoints, and identity providers. The questions it recommends security teams work through are designed to expose where the gaps are between what is happening and what the security team thinks is happening.

The progression the report describes is also useful. Most organizations are at the beginning of this and have little to no agent inventory at all. The first goal is partial visibility, knowing which agents exist, even without full context. The second goal is enrichment and context, understanding intent and mapping ownership, access, and credentials to each agent. The third goal is enforcement, with automated controls that remediate excessive permissions, notify owners of inactive agents, and flag new agents connecting to sensitive systems.

Treating agents as first-class access identities

The framing the report lands on is worth quoting. The goal is not to block AI adoption. Teams are under real pressure to use these tools, and many of the productivity gains are legitimate. If security becomes a hard blocker, usage moves further underground and unseen. The better outcome is governed enablement, providing a path for teams to deploy agents with automated controls running continuously in the background.

That means treating AI agents the same way you would treat any other identity in the enterprise, with continuous discovery, defined ownership, scoped access, and lifecycle management from creation through decommissioning. The vocabulary the report uses is non-human identity, or NHI, and the work is largely the same shape as the work that has been done on service accounts and machine identities over the last five years, applied to a new class of identity that is more autonomous and less predictable. The new Cisco deal to acquire WideField Security for AI agent identity is the latest signal that the major platform vendors are starting to read the same map.

For security teams, the practical implication is that the conversation about AI governance has to shift from a data conversation to an identity conversation. Tools that scan prompts and documents for sensitive content will not catch the access pattern problem. Tools that map identities, credentials, and permissions will. The two conversations have to happen together, and the second one is now the more important one.

For product teams building agent platforms, the implication is that the controls have to be designed in from the start. Agent builders should expect that every agent they ship will be evaluated by a security team against an inventory of identity, ownership, scope, and lifecycle controls. The agents that ship without those hooks will be the ones that get flagged, blocked, or quietly removed from the inventory by security teams a quarter after launch. The agents that ship with them will be the ones that get sanctioned and scaled.

For executives, the implication is that the access control problem is not a future problem. It is a current problem. The CSA and Token Security report and The Hacker News writeup make clear that AI agent-related security incidents are already widespread in enterprises that have built up significant agent usage, and that most of those enterprises are still at the beginning of having visibility into the access patterns their agents carry. The window to put governance in place before the next wave of agent deployment is now, and the governance will only get harder to retrofit after the agents are in production.

The clear-eyed version of the message is this. Shadow AI in 2026 is not the same problem shadow AI was in 2024. The data leakage framing made sense when the dominant risk was an employee pasting a record into a public tool. The dominant risk now is the autonomous agent that already has credentials, already has scope, and already has an action it can take. The security industry spent two years building defenses for the first problem. The second problem is here, the report is the first serious data point on it, and the work to close the gap starts with treating every AI agent the enterprise builds as a non-human identity that needs an owner, a scope, a lifecycle, and an audit trail.

For organizations standing up enterprise AI programs that include agent deployment at scale, the practical starting point is the Enterprise AI Governance Checklist for 2026, which covers the non-human identity controls, ownership mapping, and lifecycle management that the new shadow AI access model requires.