Generative AI, copilots and autonomous agents have moved into the enterprise faster than almost any technology before them. A developer wires a large language model into a build pipeline. A marketing team adopts a copilot embedded in a SaaS tool they already pay for. A business analyst signs up for an agent platform with a corporate email address and a free trial, no procurement ticket required. None of this looks like a rogue deployment from the inside. It looks like progress. And that is precisely what makes it hard to see.
Security teams have spent the better part of two decades learning to live with shadow IT: the unsanctioned software, devices, and cloud services that show up in an environment without going through a security review. The response matured into a discipline, discovery tools, access reviews, data loss prevention, built around a reasonably stable assumption: an unsanctioned asset mostly stores, transmits, or displays data. A person still has to act on it.
Shadow AI breaks that assumption. An unsanctioned model or agent does not just hold data, it can reason over it, combine it with other data it was never explicitly given, and in a growing number of deployments, take action on its own: querying a database, calling an internal API, drafting and sending a message, modifying a record. The thing security teams could not see has, in many cases, also been handed the ability to do something about what it finds.
Three forces are driving adoption ahead of visibility. The first is sheer accessibility: a capable model is a browser tab away, and an agent framework can be wired into an existing workflow in an afternoon, with no infrastructure team involved. The second is composability: modern agent tooling is explicitly designed to call other tools, retrieve from other data sources, and in some architectures, spin up or coordinate with other agents, so a single sanctioned deployment can quietly grow dependencies nobody mapped on day one. The third is organizational pressure: teams are rewarded for shipping AI-enabled features quickly, and a security review that takes weeks is, in practice, a review that gets skipped.
The result is an attack surface that looks structurally different from the one most security programs were built to monitor. A traditional asset has a fairly fixed set of things it can do. An AI agent’s capability is often defined by whatever credentials, plugins, or tool integrations it has been granted, and that set can expand over time without a corresponding change-management record. A single over-permissioned agent, compromised or simply misconfigured, does not just leak data from one place. It can act as a pivot point across every system it was ever connected to.
Sensitive data flow is the sharper, more immediate version of the same problem. Employees routinely paste proprietary code, customer records, or confidential strategy documents into public AI interfaces to get a faster answer, often with no visibility into where that data is processed, whether it is retained, or which jurisdiction it now sits in. Multiply that by autonomous agents that retrieve and synthesize information across internal systems on their own initiative, and the question of where sensitive data ends up stops being something a person decides case by case. It becomes an emergent property of a system nobody fully mapped.
This is why “are we using AI” is no longer a useful question for a security program to ask. Nearly every organization already is, in forms both sanctioned and not. The more useful questions are structural: what AI systems exist across the environment, sanctioned and unsanctioned alike? What data and systems can each one actually reach? What does each one depend on, upstream models, third-party APIs, data pipelines, other agents? And critically, what actions is each one actually capable of taking, not just what it was intended to do, but what its granted permissions technically allow?
Answering those questions requires treating AI systems as a first-class asset category, not an exception to be handled separately from the rest of the security program. That means continuous discovery rather than a point-in-time survey, since new agents and integrations appear faster than any quarterly review cycle can track. It means mapping dependencies and permissions with the same rigor applied to any other privileged system, rather than assuming a model is lower-risk because it does not look like traditional infrastructure. And it means governance that spans security, legal, data protection, and the business units actually deploying these tools, because no single team has full visibility into how AI is being adopted on its own.
AI is not going to slow down to let governance catch up. It is going to keep embedding itself deeper into how work gets done, often through the exact paths that are hardest to monitor: personal accounts, embedded features, agent-to-agent handoffs. The organizations that manage this transition well will not be the ones that ban AI tools outright, an approach that rarely survives contact with a workforce determined to use them anyway. They will be the ones that can answer, with confidence and in real time, a deceptively simple question: what is this system capable of doing, and do we actually know it is doing that right now? Until security teams can answer that question continuously, AI will keep expanding the attack surface faster than anyone is able to defend it.