When a company installs an AI agent, the agent typically needs access to existing systems to be useful. It might connect to a customer database, your email system, a financial reporting tool, or all three. Each of those connections happens through a small software component called a server, and right now most organizations have no reliable count of how many of these components are running, who installed them, or whether they were reviewed for security risks before going live.
This is not a theoretical concern. The first documented case of a malicious tool of this type appeared in late 2025, operating for two weeks before anyone noticed, quietly copying email data to an attacker's address. A separate package with over 437,000 downloads was found to enable remote code execution when connected to an untrusted source. Research from Trend Micro counted 95 newly discovered vulnerabilities in these AI connection tools in 2025 alone, the vast majority appearing in a single year because the technology itself is only about 18 months old.
What makes this harder to manage than traditional software security is the nature of how AI agents operate. A conventional application does what it is programmed to do. An AI agent interprets instructions in natural language, decides which tools to use, and can chain actions across multiple systems without a human approving each step. If a malicious instruction is embedded in an incoming email or a document the agent processes, the agent may follow it without flagging anything unusual. Security researchers demonstrated this in 2025 against Microsoft's widely deployed enterprise AI tool, where a hidden prompt in content the agent was reading could trigger it to silently send files to an outside address.
The compliance exposure here is concrete and immediate. GDPR, SOX, and similar frameworks were not written with AI agents in mind, but regulators are applying them anyway. The most common gap is attribution: when an AI agent accesses sensitive data, the action is often logged under a generic system account rather than tied to the person who triggered it. That single gap means many current AI deployments cannot survive a standard audit, regardless of whether anything went wrong.
Cisco and AWS are now jointly releasing a tool designed to address the basic infrastructure problem: a central registry where every AI agent and every tool it connects to can be catalogued, automatically scanned for vulnerabilities, and logged for compliance purposes. When a new tool is registered, it gets scanned before it can be used. If a problem is found, the tool is automatically blocked and flagged for a human reviewer. The system also runs scheduled scans across the entire registry so that tools which were clean when installed can be rechecked as new threats are discovered.
What is notable about the approach is that Cisco is applying the same scanning logic it built for traditional software security to AI-specific threats: hidden instructions embedded in tool descriptions, code that leaks credentials, patterns that mimic legitimate behavior while exfiltrating data. These are not abstract risks. A working exploit involving Microsoft's AI platform received a severity score of 9.3 out of 10 after researchers demonstrated it in 2025.
Cisco has also expanded this security layer to cover all three major cloud platforms, AWS, Azure, and Google Cloud, which reflects a real operational reality. Most companies of any size are not running on a single cloud environment, and AI agents deployed across multiple environments without consistent governance rules create compounding blind spots.
The broader pattern here is that the AI agent market is replicating a mistake the software industry has made before. Early app stores, early open-source package registries, and early plugin marketplaces all expanded quickly without security infrastructure keeping pace, and all eventually produced significant incidents that forced the industry to catch up. The agent market is at that same early stage now, but the stakes are higher because these tools have direct access to production systems and can act without human confirmation.
For companies currently deploying or planning to deploy AI agents, the practical question is not whether security matters but whether governance infrastructure is being built alongside the tools themselves. The teams most exposed right now are those who have allowed individual departments to connect agents to internal systems without a central log of what exists and what it can access.