The initial wave of enterprise AI concerns focused on employees inadvertently pasting sensitive data into public AI tools. Security teams responded with policies, domain blocks, and data loss prevention (**DLP**) rules. While effective then, this approach is now largely outdated. Today, **Shadow AI** presents itself as an access control problem. The core threat isn't just about what employees input into AI tools, but rather which AI agents are operating within the organization, their connections to enterprise systems, and the actions they are authorized (or unauthorized) to perform. ## From Passive Tools to Active Actors Employees and business units are rapidly developing AI agents – custom assistants, coding agents, workflow automations, and agentic applications. These are emerging across departments, sometimes within sanctioned platforms, but often through browser extensions, **SaaS**-native features, developer tools, **MCP** servers, endpoint-based agents, and custom scripts. Many begin as quick experiments, yet some quickly become embedded in critical business processes. The risk profile of these agents fundamentally differs from traditional **Shadow IT**. An unsanctioned SaaS application is a data destination; an AI agent is an actor. It can call **APIs**, use stored credentials, retrieve records, modify configurations, trigger downstream workflows, and take actions in production systems, often without explicit human authorization for each step. Consider the difference: 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. Such an agent could not only expose data but also perform read, write, and delete actions. It might run on service accounts with unaudited permissions and remain active long after its creator has moved roles or left the company. Recent research from **Token Security** and the **Cloud Security Alliance** highlights the widespread nature of this exposure. ## Why Existing Controls Fall Short Most enterprise security controls are designed for human identities and deterministic workloads. **Identity and Access Management (IAM)** policies, DLP rules, and network monitoring assume predictable behavior and defined access paths. AI agents disrupt these assumptions. An agent tasked with resolving a failed deployment, for instance, might read logs, query monitoring systems, modify infrastructure configurations, open tickets, trigger automation pipelines, and notify engineering teams—all in sequence, using the same inherited credentials. To avoid workflow disruptions, developers often grant broad permissions upfront. These permissions accumulate, agents inherit creator-level privileges, temporary access becomes permanent, and security teams lose visibility into the agents' actual activities. Simply blocking public AI domains is insufficient. By the time an agent possesses credentials to enterprise systems, the security perimeter has already been breached. Automated remediation of non-human identities is crucial for closing this gap. ## What a Real Shadow AI Inventory Looks Like Discovering **Shadow AI** necessitates examining environments where agents reside: AI platforms, SaaS applications with built-in automation, cloud accounts, developer tools, endpoints, and identity providers. Security teams need to ask critical questions to establish real control: 1. **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 integrated AI capabilities. 2. **Who owns each agent, and who can use it?** Without clear ownership, accountability is absent. An agent built for a small team but shared widely carries a vastly different risk profile than one scoped to a single user. 3. **What resources and services is the agent connected to?** An agent might appear harmless at the platform level but hold connections to sensitive databases or production systems via informally granted and unreviewed credentials. 4. **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 introduces distinct risks. 5. **What is the agent’s intent and what has it actually done?** Configuration alone doesn't reveal whether an agent is merely reading data, writing records, or accessing systems beyond its intended scope. Understanding both intent and behavioral context is essential for prioritizing responses. 6. **Is the agent still active?** Token Security's **Agentic Pulse** data indicates that 65.4% of agentic chatbots have never been used since creation, yet their credentials remain active. Dormant agents with live access represent a persistent and often underestimated exposure. ## The Maturity Curve for Agentic AI Security Most organizations are just beginning to build an agent inventory, often with limited visibility. The next step involves gaining partial visibility to identify existing agents, even without full context. Subsequently, enrichment and context are needed to understand intent, map ownership, access, and credentials to each agent. The final stage involves applying enforcement through automated controls that remediate excessive permissions, notify owners of inactive agents, and flag new agents connecting to sensitive systems. The ultimate goal is not to obstruct AI adoption. Teams face genuine pressure to leverage these tools, and many productivity gains are legitimate. If security becomes a hard blocker, usage will simply move further underground and become invisible. The better outcome is governed enablement, providing a secure path for teams to deploy agents with continuous, automated controls running in the background. This requires treating AI agents as any other identity within the enterprise, demanding continuous discovery, defined ownership, scoped access, and full lifecycle management from creation to decommissioning. The question of **Shadow AI** has evolved. It's no longer: *what data are employees putting into AI?* It's now: *which agents are operating in our environment and what access have we granted them?* The latter question is what truly defines an organization's exposure and risk. For those navigating this inventory challenge, exploring current approaches is highly recommended.