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 credentials to enterprise systems, the boundary has already been crossed. Automated remediation of non-human identities is where that gap gets closed.
What a real shadow AI inventory looks like
Discovering shadow AI requires looking across the environments where agents actually live, such as AI platforms, SaaS apps with built-in automation, cloud accounts, developer tools, endpoints, and identity providers. Here are six questions to define whether security teams have real control.
- Where are agents being created or installed? This includes obvious AI platforms but also coding assistants, SaaS-native agent features, local developer tools, and internal applications that have quietly added AI capabilities.
- Who owns each agent, and who can use it? Without ownership, there’s no accountability. An agent built for a three-person finance team that gets shared across the organization carries a very different risk profile than one scoped to a single user.
- What resources and services is the agent connected to? An agent can appear harmless at the platform level while holding connections to sensitive databases or production systems through credentials that were granted informally and never reviewed.
- What identities and secrets does it use? Agents authenticate through service accounts, API keys, OAuth tokens, cloud IAM roles, and long-lived secrets. Each credential type carries different risks.
- What is the agent’s intent and what has it actually done? Configuration alone doesn’t show whether an agent is reading data, writing records, or accessing systems outside its intended scope. Understanding intent and behavioral context is required to prioritize response.
- Is the agent still active? Token Security’s Agentic Pulse data found that 65.4% of agentic chatbots have never been used since creation, but their credentials remain active. Dormant agents with live access are a persistent and underappreciated exposure.
The maturity curve to ensure agentic AI security
Most organizations are at the beginning of this and have little to no agent inventory. The next step is to gain partial visibility to know which agents exist, even without full context. After that they need enrichment and context to understand intent and map ownership, access, and credentials to each agent. The next step is to apply enforcement with automated controls that remediate excessive permissions, notify owners of inactive agents, and flag new agents connecting to sensitive systems.
The goal isn’t 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 to provide a path for teams to deploy agents with automated controls running continuously in the background.
This requires treating AI agents the same way you’d treat any other identity in the enterprise with continuous discovery, defined ownership, scoped access, and lifecycle management from creation through decommissioning.
The shadow AI question has changed. It’s no longer: what data are employees putting into AI? It’s now: which agents are operating in our environment and what did we give them access to? Those are different questions. The second one is the one that defines an organization’s exposure and risk. If you’re working through that inventory now, it’s worth seeing how others are approaching it.
