Earlier this month, I spoke at the Gartner Security & Risk Management Summit about a blind spot many security systems still haven’t addressed – how attackers circumvent AI security systems by using legacy infrastructure to hijack AI agents.
AI adoption is moving faster than security systems can account for. About 71% of organizations are exploring AI agents across their business systems, and 31% have already moved them into production workflows.
For this reason, organizations are officially pouring resources to secure AI workloads against model poisoning, rapid injection, data leakage, and other emerging threats. Yet this focus misses everything below the AI layer. Because an unpublished server, poorly configured worklist permission, or cached information on a developer’s machine is an exposure that gives attackers direct access to everything your AI agents depend on – databases, cloud storage, Lambda functions, SaaS integrations, and connecting data.
This means that scary characters don’t really need to attack your AI directly – they just need access to what it connects to. In this article, I’ll go over how legacy infrastructure is becoming an avenue of attack for AI agent environments and how security teams can prevent those avenues.
AI Agents Use What They Inherited
Despite their novelty and power, in some ways AI agents work like other assets in your environment. It authenticates with existing identity providers, stores data in existing cloud buckets, executes operations with existing Lambda functions, and gains permissions from existing IAM roles. All of these dependencies carry whatever security liability the organization had before AI deployment began.
In addition, many organizations are not specific to combine that debt. In accordance with Infosecurity Magazine, 70% of organizations offer their own AI systems More privileged access to someone in the same role. Not surprisingly, this comes with a painful price tag. Organizations with over-privileged AI reported an incident rate of 76%, compared to only 17% for those using less privileges.
All of those connections – identity providers, cloud buckets, Lambda functions, IAM roles – work with the infrastructure your teams have managed for years: Active Directory, cloud IAM, service accounts, databases. Yet none were designed with AI agents in mind, and most of them were delivered long before the first agent went into production. The result is that an attacker who finds his way in through any of those layers doesn’t need to touch the AI. The agent’s own permissions do the work for themselves.
CVE from 2025 How to Ban an AI Agent in 2026
The diagram below shows the architecture of a typical business AI agent. A successful customer team uses AI-powered Co-Pilot – hosted on AWS Bedrock – to query customer data sent from Salesforce to an S3 bucket. Co-Pilot performs tasks with Lambda functions and integrates with business applications. John, the developer, builds and maintains the agent. Users across the organization interact with it every day.
Now here’s what happens when an attacker finds a way in. The following diagram shows how to attack my simulated group in a real business environment. None of these revelations are strange – they exist, with some integration, in many corporate networks right now. What makes them dangerous is the way they connect. Here’s how the attack began, stage by stage.
- Phase 1: The S3 bucket becomes a valuable resource. To feed CSM Co-Pilot, the team exported Salesforce data to an S3 bucket. That submission turned the bucket into a high-value target holding sensitive customer records. Many users across the AWS account got very broad read access to production S3 buckets – including John, a Co-Pilot developer, who never needed access to production data. In itself, this is a simple permissions misconfiguration.
- Stage 2: Unstacked server on the perimeter. The external facing server uses Apache Tomcat. That server was exposed to CVE-2025-24813 – a remote code execution flaw that was disclosed in March 2025 and added to CISA’s Known Exploited Vulnerabilities catalog the same month. It was not even patched. Because the server resides on-premises and is integrated with Active Directory, an attacker exploiting the vulnerability can dump cached information from the server’s memory and compromise a user’s AD account. In isolation, this is a known vulnerability on a single server – bad, but not critical.
- Stage 3: Malfunctioning of Functional Texts enables joint movement. That vulnerable AD account can abuse the Resource-based Constrained Delegation flaw to impersonate John and access his workstation. John uses the AWS CLI to manage Co-Pilot cloud services, and behind the scenes, the CLI stores AWS access keys on his machine. The attacker harvests those keys. In isolation, this is an AD permissions issue – one of thousands that many sites handle.
- Now connect the three sections. An attacker exploits CVE-2025-24813 on the perimeter, dumps data, bypasses AD to John’s workstation, harvests his AWS access keys, and reads all the records in the production S3 bucket – the same bucket that feeds the Co-Pilot database. The Co-Pilot agent is now vulnerable. The attacker controls what it reads, what it trusts, and what it sends back to users. No part of the AI stack is directly attacked. Three moderate findings – overprivileged cloud key, unpublished web server, AD misconfiguration – became one key attack method.
What To Do With It
The attack method I just described crosses four layers: network, identity, cloud, and AI. Most security systems test each of those layers independently, and exposure to each may already be known. The EASM tool flags the Tomcat server. The AD security tool catches the wrong delegation. The CSPM tool finds S3 access with multiple possibilities. Each reports a moderate discovery that may not be fixed due to low priority but together it is a serious problem: the vulnerability of Tomcat in the cycle chains with AD into the cloud credentials of developers and ends in the AI agent database.
Closing these gaps starts with an exposure management approach that treats AI agent dependencies (databases, storage buckets, Lambda functions, etc) as critical assets themselves. From there, map it backwards: what ownership relationships, permissions, and infrastructure connect to those assets, and which of these connections hold actionable exposure in the context of your environment? When you calculate the full path, choke points appear – places where a single adjustment will block multiple routes to your AI assets.
If your exposure management platform can track that full path — from the legacy server through AD and cloud infrastructure to the AI agent’s knowledge base — you can fix exposures before an attacker can hook you. If it can’t, no amount of guardrails in the AI layer will stop it.
The Bottom Line
Agent AI adoption is accelerating across all business departments. And every new agent you install connects to an already exposed infrastructure. That means the attack surface meets every deployment.
The question for security leaders is not whether your AI layer is secure. That environment where those agents operate – including your bread-and-butter legacy infrastructure – gives attackers a way to hijack them.
Because attackers don’t need new techniques to compromise AI agents. They just need the old – and a place that allows them to use the old to exploit the new.
Note: This article is carefully written and contributed to our audience by Zur Ulianitzky, SVP Product and Security Research, XM Cyber.
