65.4% of agentic chatbots have never been used since creation, but their credentials remain active.
From data leakage incidents to access-control failures
Early enterprise anxiety about AI focused on employees pasting sensitive records into public tools. Security teams answered with usage policies, domain blocks, and data loss prevention rules. That response "made sense at the time," the source observes — but it no longer fits the problem.
Shadow AI has shifted from a data-leakage framing to an access-control problem. The core risk is not simply what a person types into a model; it is which AI agents are running inside the organization, what enterprise systems they are connected to, and what actions those agents can take. Unlike an unsanctioned SaaS application that passively stores data, an AI agent can act: calling APIs, using stored credentials, retrieving records, modifying configurations, triggering downstream workflows and taking actions in production systems.
The source names concrete integrations to underline the scale: a custom AI agent connected to Salesforce, Snowflake, GitHub, Gong, and Slack is “an access control incident waiting to happen.”
Why existing security controls don't reach agentic risk
Most controls were built 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, open tickets, trigger automation pipelines and notify engineering teams — all in sequence using the same inherited credentials. To avoid breaking workflows, developers often grant broad permissions up front. 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 does nothing once an agent has credentials to enterprise systems; by then, the boundary has already been crossed.
Where agents live and the six questions to find them
Discovering shadow AI requires looking where agents actually live: AI platforms, SaaS apps with built-in automation, cloud accounts, developer tools, endpoints and identity providers. The source lays out six diagnostic questions security teams should answer to build a usable inventory:
- Where are agents being created or installed? (Includes AI platforms, coding assistants, SaaS-native features, local developer tools, and internal apps with quietly added AI.)
- Who owns each agent, and who can use it? (Ownership equals accountability; shared agents widen risk.)
- What resources and services is the agent connected to? (Connections to sensitive databases or production systems can be hidden behind seemingly benign platforms.)
- What identities and secrets does it use? (Service accounts, API keys, OAuth tokens, cloud IAM roles and long-lived secrets all carry different risks.)
- What is the agent’s intent and what has it actually done? (Configuration is not behavior; intent and behavioral context are 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, yet credentials remain active — dormant agents with live access are a persistent exposure.)
The maturity curve: from discovery to governed enablement
Most organizations are at the beginning of this journey with little or no agent inventory. The source describes a practical maturity curve: first gain partial visibility to know which agents exist; next enrich that inventory to map ownership, access and credentials; then apply automated enforcement controls that remediate excessive permissions, notify owners of inactive agents and flag new agents connecting to sensitive systems.
The stated goal is not to block AI adoption but to provide governed enablement. If security becomes a hard blocker, usage moves further underground. A better outcome, the source argues, is to treat AI agents like any other enterprise identity: continuous discovery, defined ownership, scoped access and lifecycle management from creation through decommissioning, with automated controls running continuously in the background.
What this means for security teams, developers, and procurement leaders
- Security teams and technologists — Shift inventory and enforcement from human-only identities to include agent identities, and prioritize automated remediation for long-lived credentials and dormant agents.
- Developers and business units — Expect tighter ownership and lifecycle requirements for agents you build; broad upfront permissions that “avoid breaking workflows” will be questioned and, in some cases, revoked or scoped automatically.
- Procurement and IT leadership — Governed enablement, not outright bans, is the recommended approach: allow productivity gains while enforcing continuous controls and defined access paths for agentic tools.
The shadow AI question has changed. It is no longer primarily about what data employees put into AI; it is about which agents operate in the environment and what access was granted to them. That shift defines an organization’s exposure and risk — and it defines what security teams must inventory, enforce and continually manage.
