Abstract,close up of Mainboard Electronic computer background. (artificial intelligence, ai) Credit: Canva TL;DRReco’s State of Agent Security 2026 report found that 80% of AI tools in its telemetry operated without IT oversight, with SMBs averaging 414 unsanctioned AI tools per 1,000 employees. IBM found shadow AI added $670K to breach costs. The article explains how companies should triage: map what each agent can reach, find who still owns it, watch for orphaned agents that outlive their creators, and prioritize agents touching customer data, code, and production systems. Companies are discovering AI agents connected to email, customer data, and code without IT oversight.
Finding them is only the beginning. For most of the past decade, the list of software a company ran was, at least in theory, one that somebody in IT could find. Today, however, AI is making that increasingly difficult. A marketing manager can switch on an AI feature inside software the company already pays for.
A developer can connect an assistant to an internal knowledge base. Someone else can add an AI meeting tool or browser extension and click “Allow” when it asks for access to their files or calendar. Nobody necessarily thinks they are introducing a new piece of enterprise software. There is no procurement meeting or lengthy security review.
Sometimes all it takes is an OAuth consent screen. Then the security team goes looking. “The first scan often finds AI inside places the organization does not think of as part of its AI program,” Ofer Klein, cofounder and CEO of Reco, a company that secures agents for enterprises, said in an interview. That includes “browser extensions, meeting tools, productivity suites, CRM workflows, support tools, developer environments, and app-to-app integrations.” Reco’s latest The State of Agent Security 2026 report gives some sense of the scale. Four in five AI tools observed in its telemetry operated without IT oversight.
At small and midsize companies, it found an average of 414 unsanctioned AI tools for every 1,000 employees. While discovering them solves one problem, it also creates another. What do you do with 400 AI tools you didn’t know existed? Start with what the agent can actually reach The obvious response would be to start shutting things down.
But in practice, that could create a different mess. Some of those tools may already be doing useful work. One might prepare account updates for salespeople. Another summarizes support tickets.
A developer may rely on an assistant connected to a code repository. Ofer Klein, cofounder and CEO of Reco — Credit: Reco Klein says the first surprise for security teams is often not the number of AI tools employees have introduced, but how deeply some are connected to the business. “A tool that looks like a harmless assistant may have permission to read email, summarize files, access customer records, connect to ticketing systems or interact with source-code repositories,” he said. There is evidence that these unmanaged tools are already showing up in real-world breaches. IBM’s 2025 Cost of a Data Breach report, which studied 600 breached organizations across 17 industries, found that one in five had experienced a breach involving shadow AI.
Organizations with high levels of shadow AI also recorded breach costs averaging $670,000 more than those with little or none. So instead of treating every unknown AI tool equally, the first priority becomes understanding its reach. An assistant connected only to public information presents a very different problem from an agent that can access customer records, financial systems or production code. Then find out who still owns it Here is where things get particularly messy.
An employee connects an agent for a three-month project, the project ends and six months later, the employee moves to another department. The loophole, however, is that the agent is still there. Klein says Reco commonly finds these “orphaned agents” when entering a customer environment for the first time. An agent may have arrived through someone’s OAuth grant, API key or service account, and its access can survive changes elsewhere in the organization.
He explained that the company’s normal process for handling departing employees might work exactly as designed, while integrations and delegated access created by that employee receive far less attention. This is becoming a broader identity problem, with several other reports suggesting that companies are struggling with the same issue as AI agents multiply. For example, Okta’s Businesses at Work 2026 report found that 78% of organizations see controlling access and permissions for non-human identities as a major concern, but only 10% have a strategy for governing them. That includes the service accounts and other machine identities AI agents increasingly use to access company systems and data.
This leaves security teams with a fairly basic problem. Someone needs to know why an agent is there, what it can access and whether it still needs to be running. When nobody does, an agent set up for a three-month project can quietly become a permanent part of the company. The dangerous agent may look perfectly normal There is a temptation to imagine agent security failures as dramatic events.
An autonomous system suddenly goes rogue, does something obviously malicious and sets off alarms across the security team. But Klein believes the reality can be much less exciting. An assistant brought in to summarize support tickets might gradually be connected to other systems, or a workflow might start pulling records that were never part of its original job. In other cases, an agent may send information to the wrong channel or simply keep running long after the person who set it up has moved on.
Klein says these problems are often discovered almost by accident. Someone notices an unexpected output, a security review turns up unusual app activity, or an auditor asks who owns a particular agent and nobody is quite sure. By then, it may have been operating that way for weeks or months because, from the outside, much of what it was doing looked like ordinary application activity. This is why simply finding an agent is not enough.
Teams also need to know why it is there, who is responsible for it and what it is supposed to be doing. Finding everything is only the first morning According to Klein, companies tend to stall after discovery for three reasons. Nobody knows who owns some agents. Security can see that a tool exists without understanding everything it can access.
And when something looks risky, the available response can feel painfully binary: leave it alone or shut it down. A more practical triage starts with the systems a company would least like to lose control of. Agents touching customer information, source code, financial workflows, production systems or external communications go to the front of the queue. From there, teams can identify an owner, examine permissions, remove access the agent no longer needs and decide when it should be reviewed again.
That approach also accepts something companies may eventually have little choice but to accept: employees are going to use AI. Trying to catalogue every approved AI application will not tell a security team what is actually happening if employees can activate new capabilities inside existing software or connect agents to company systems themselves. The morning after discovering 400 unknown agents, then, the job isn’t to find a giant red button and turn them all off. It’s figuring out which ones have the keys to the building.
Contributed article. Not produced by the TNW newsroom and does not reflect the editorial stance of TNW.
