By Rajesh Beri | May 2, 2026
The Cloud Security Alliance and Token Security dropped a survey on April 28 with the kind of title that should be making CISOs reach for the contract folder: Autonomous but Not Controlled. The headline number is the one most security teams hoped they would never have to face. In the last twelve months, 82% of organizations discovered at least one AI agent or autonomous workflow that security or IT did not previously know about. Not a chatbot a marketing manager set up. An agent — something with credentials, permissions, and the ability to take action across systems — running in production without governance sign-off.
The follow-up number is worse. 65% of those organizations experienced an AI agent security incident in the past year. Of the incidents reported, 100% had real business impact, with data exposure as the most common outcome. This is no longer a "shadow IT, let's write a policy" problem. It is a control plane gap, it is being exploited, and it is showing up on incident reports.
For Rajesh Beri's audience — enterprise AI leaders, CIOs, CISOs, and the AI engineering teams that have to actually live with the consequences — this is the report that finally puts hard numbers on what most of us have been seeing in the field for two quarters. Here is what Autonomous but Not Controlled actually says, what the parallel Pentera AI Security Exposure Survey 2026 found, and the concrete five-step playbook to close the gap before the next quarterly board review.
The Visibility Paradox
The first thing the CSA / Token Security report exposes is a comfortable lie that many security teams have been telling themselves and their boards. 68% of organizations report high visibility into AI agents and autonomous workflows. Meanwhile, 82% of those same organizations discovered an agent they did not know existed. Both numbers are true. Both come from the same survey population. The gap between them is the entire problem.
What the report calls the "visibility paradox" — and what every CISO who has lived through a shadow IT crisis already recognizes — is the difference between operational awareness and assurance-grade control. Operational awareness means a security team can name the agents they have approved and watch them in a dashboard. Assurance-grade control means the security team can say with confidence that no other agents exist, that none have escalated permissions, and that none are taking actions outside documented boundaries. Almost no enterprise is at assurance-grade today. The Pentera AI Security Exposure Survey 2026, published the same week, makes that explicit: zero CISOs surveyed reported full visibility with no shadow AI. One-third said they had good visibility but assumed shadow AI was likely present. Two-thirds said they had limited visibility and that shadow AI was a known issue. Nobody is fully covered. Anybody who claims to be is either lying or has not looked.
The visibility gap matters because the threat surface has changed shape. A shadow SaaS app circa 2018 was a piece of unmanaged software handling data. A shadow AI agent in 2026 is something else: it has credentials, it executes multi-step actions, it can chain tools, it can write to databases, it can trigger workflows in downstream systems, and it can be invoked by other agents. Treating an unknown agent as a "shadow tool" is a category error. The right mental model is closer to an unauthorized service account with autonomous decision-making attached.
Where the Shadow Agents Actually Live
The report breaks down where unknown agents are showing up in enterprise environments. The four most common locations match what AI engineering teams have been saying for the last year:
Internal automation and scripting environments. Engineers wire up an agent against the company OpenAI key, or a self-hosted Llama, to handle a workflow that used to be a cron job. It works. They tell nobody. It accumulates permissions over six months because each new use case requires another secret. By the time the security team finds it, the agent has access to production data and a non-trivial blast radius.
LLM platforms with custom tools and assistants. Every major model provider — OpenAI, Anthropic, Google, Microsoft — now ships a way for individual users to attach custom tools to a chat assistant. A finance director adds a tool that queries the data warehouse. A product manager adds a tool that posts to Jira. Neither configuration shows up in the central agent registry because there is no central agent registry that captures them.
SaaS tools with built-in agent automation. Salesforce Agentforce, ServiceNow autonomous workflows, Zendesk AI, HubSpot Breeze, Microsoft Copilot Studio — each of these allows a business user to spin up an agent inside the tool without involving security. The vendor surface area has exploded over the last twelve months. The audit surface has not kept up.
Developer-created workflows. Cursor, Cline, GitHub Copilot agents, internal MCP servers, Claude Code projects — every modern developer environment now ships with agent capability that can act against connected services. Most enterprises do not yet have a model for treating "the agents my developers built into their dev loop" as a governance event. They should.
The unifying pattern: agents are being created in surfaces where the creation event itself is not currently treated as something that requires security review. That is the underlying defect. Treat AI agent creation as a governance event across all platforms. That is the report's first recommendation, and it is the only one that fixes the root cause.
The Confidence Gap Will Bite You
The CSA / Token Security report has one finding that should sit on every executive's desk before the next AI strategy review: 82% of executives report confidence that their existing policies protect against unauthorized agent actions, while only 14.4% of organizations actually send agents to production with full security or IT approval.
Run that math. Roughly four out of five executives believe their policies cover them. Roughly one in seven agents actually go through the policy. The rest are deployed by business users, by developers, by integrators, by SaaS vendors flipping a feature flag — with no approval gate at all. The "policies" the executives are confident in are not being enforced at the point of agent creation. They are being applied retroactively, if at all.
This is the same dynamic that caused the cloud governance crisis a decade ago. CIOs were confident in their cloud policies. Engineers were spinning up AWS accounts on personal credit cards. The gap closed only when finance, identity, and procurement teams instrumented the actual creation surfaces — when CSPM tools showed up, when SCP guardrails became default, when SSO became mandatory for cloud consoles. The shadow AI agent problem will close the same way: not through policy memos, but through creation-event instrumentation on every surface that can spin up an agent.
What the Pentera Data Adds
The Pentera AI Security Exposure Survey 2026, also published in late April, surveyed CISOs specifically and adds the practitioner perspective on top of the CSA / Token Security industry view. Three numbers from the Pentera survey are worth memorizing.
67% of CISOs report limited visibility into where and how AI is operating across their environments. This is the topline statistic that should sit next to the 82% figure on every CISO's quarterly board slide. Two-thirds of the people responsible for the security of AI in their organization say they cannot see most of it.
50% identify lack of internal expertise as their top challenge. AI security is a discipline that did not exist as a job title two years ago. The talent pool of people who actually understand both reasoning models and traditional enterprise security is thin enough that most large enterprises cannot staff it from inside. This is why the consultancy market for AI security advisory has exploded — it is a skills arbitrage that will not close in 2026.
48% cite limited AI visibility as the second-biggest challenge, behind only the expertise gap. The two top problems are deeply linked. You cannot govern what you cannot see, and you cannot see it without people who know what to look for.
Dale Hoak, RegScale's CISO, captured the reality on the ground in the CSO Online coverage of the Pentera report: "The business was moving so fast in using AI, so initially we had some visibility gaps." Nitin Raina, Thoughtworks' Global CISO, named the structural driver: "The vendors we use are adding AI capabilities and sometimes we don't have entire visibility into that." That second quote is the one to underline. The fastest source of new shadow agents in 2026 is not your developers. It is your existing SaaS vendors flipping AI features on for users without notifying security.
What This Costs When It Goes Wrong
The cost data lines up with the visibility data. Recent industry numbers consistent with the CSA / Token Security report show 20% of organizations have suffered a confirmed shadow AI breach, with average incident costs running $670,000 above traditional incident costs. The cost premium comes from three places: the agent's blast radius is larger than a typical compromised account, the forensic timeline is harder to reconstruct because agent actions span multiple systems, and the regulatory disclosure surface is wider because nobody wrote down what data the agent was authorized to touch.
The Autonomous but Not Controlled report puts an accelerant under that trajectory. Autonomous agents are involved in roughly 1 in 8 AI breaches today, and the category is growing at 89% per year. If that trend line holds, autonomous agents become the single largest AI breach category inside the next eighteen months.
Two recent incidents anchor what this looks like in practice. The Vercel / Context AI breach on April 19, 2026 started with an OAuth token compromise at Context AI, an AI agent platform, and ended with Vercel customer data being offered for $2 million on BreachForums. The supply chain ran through an AI agent's credential surface. The incident reporters could not initially answer the question "what did the agent have access to" because nobody had documented the scope. Separately, Meta had an internal AI agent issue incorrect instructions that temporarily exposed sensitive internal data to employees who should not have had access. No external attacker. The agent itself was the failure mode. Both incidents are exactly the failure pattern the CSA report warns about: agents with access broader than their documented purpose, operating in surfaces nobody had instrumented for governance.
The Five-Step Playbook for AI and Security Leaders
The CSA / Token Security report ends with five recommendations. These map cleanly onto an actionable thirty-day program for any CIO or CISO whose AI security posture is currently in the 82%.
Step one: Treat AI agent creation as a governance event across every platform. Enumerate the surfaces in your environment that can create an agent: developer tools, SaaS apps, internal automation platforms, every LLM provider you have a contract with. For each one, identify the creation event and instrument it. This may require working with the SaaS vendor to enable audit logging on agent creation, deploying an agent registry, or — for internal tools — wiring the creation API into your IAM or service catalog.
Step two: Extend visibility into high-velocity development environments. Cursor, Cline, Copilot, internal MCP servers — the developer surface is the fastest-moving creation source and it is also the one most likely to be invisible to security. Get an inventory now. The Salesforce Agentforce and Microsoft Copilot Studio agents are easier to enumerate because they live inside an admin console. The developer-built ones are not.
Step three: Align discovery with formal lifecycle management. Discovery is a one-time event. Lifecycle management is an ongoing process. An agent that was approved in February with one set of permissions and now operates against a different set of systems in May is not the same agent. You need quarterly attestation of agent purpose, scope, owner, and permissions — and an automated way to deprovision agents whose owner has left or whose use case has ended.
Step four: Build governance assuming decentralized agent deployment. The mistake most enterprises are about to make is reorganizing their AI strategy around a central agent platform that "everyone will use" and assuming that closes the shadow problem. It will not. Agents will continue to be created in dozens of surfaces. The right architectural posture is federated discovery and centralized policy: assume agents will be created everywhere, instrument every surface, and apply consistent policy across all of them.
Step five: Close loops between visibility and decommissioning. The question "who owns this agent and what is its decommission criteria" should have an answer for every agent in production within ninety days. The answer is the difference between an enterprise that can say we run a controlled fleet and one that is just hoping the next breach lands somewhere else.
What Engineering Teams Should Do This Week
For the AI engineering teams that build and deploy these agents — the people who will actually have to implement the playbook above — three concrete actions before next sprint planning.
Stand up an agent registry, even a minimal one. A spreadsheet with agent name, owner, model, scope of permissions, target systems, and last-reviewed date is better than nothing. The CSA report's data is clear: most enterprises do not have this asset today. Building one in week one costs nothing and pays back the first time security asks "what agents do we have."
Instrument the creation event in your dev environments. If your team uses Cursor, Cline, or internal Claude Code projects to create agents that touch production systems, the creation step should generate a record. A pre-commit hook, an MCP server log, a CI gate — pick the surface and instrument it. The goal is to make agent creation in developer environments visible to security without slowing down developers.
Apply non-human identity discipline to every agent. Each agent should have a distinct service identity, narrow IAM scope, secret rotation, and an expiry date for the credentials. The vendors that built non-human identity platforms — Token Security, Astrix, Andromeda Security, Britive, GitGuardian's NHI line — exist for exactly this problem. If you do not already have one of these in your stack, the Autonomous but Not Controlled report just made the procurement case for you.
The numbers in this report are uncomfortable for a reason. AI agent adoption has run ahead of governance. The 82% who found unknown agents are the lucky ones — they at least went looking. The 18% who did not should not assume they have a clean fleet. They should assume they have not looked hard enough yet. The next eighteen months will reward the enterprises that close the gap on instrumentation, on identity, on lifecycle. They will be brutal to the ones that do not. Pick your posture now, before the next quarterly board review, because the breach data is going to keep getting worse before it gets better.
If you are an AI or security leader rebuilding your agent governance posture for the next twelve months, the cheapest move you can make this quarter is to stand up the registry and instrument the creation events. Everything else is downstream of seeing what you actually have. Start there.
