The security team never needs to interact with the AI agent. The attacker gets full access to the production S3 bucket through John’s AWS credentials. In this case, three moderate findings, each of which alone is unlikely to be prioritized for immediate remediation, when chained together create a critical attack path. The attacker exploited the Tomcat server vulnerability in March 2025, escalated privileges through Active Directory misconfiguration, and used stored AWS CLI keys to read sensitive data from S3. The AI agent was never directly attacked. Instead, the attacker went through the underlying infrastructure to compromise it.
Why This Keeps Happening
There are a few reasons this pattern of attack keeps repeating across enterprises.
First, AI security conversations focus almost exclusively on the AI layer. Teams invest heavily in detecting prompt injection attacks and preventing model tampering and data leakage. These are real threats. However, they represent only a fraction of the total attack surface. The AI layer sits on top of traditional infrastructure: Active Directory, cloud IAM, web servers, databases, and stored credentials. Attackers who can’t get in through the AI itself simply go around it, exploiting weaknesses in the underlying systems the AI depends on.
Second, security teams often lack visibility into how AI agents connect to the rest of the environment. AI deployments frequently happen quickly, sometimes without full security review. Agents are granted broad permissions to function, and the resulting web of connections – between cloud services, identity providers, data stores, and API keys – grows fast. Security teams frequently have no complete map of what an agent can access, what credentials it relies on, or what the blast radius looks like if those credentials are stolen.
Third, existing infrastructure weaknesses are deprioritized when they exist outside the AI stack. In the example above, each of the three findings taken individually would likely not be treated as urgent. An unpatched web server here, a misconfigured AD permission there, a developer with more cloud access than necessary. Each one is moderate on its own. But when you look at them as a connected path rather than individual issues, the picture changes completely. The problem is that most security tools evaluate risks in isolation, not as attack paths.
What Security Teams Should Do
Protecting AI agents requires looking beyond the AI itself. Here are concrete steps security teams can take, starting with the most impactful.
1. Map every dependency your AI agents rely on. You cannot protect what you cannot see. Start by inventorying every cloud service, IAM role, stored credential, and data store your AI agents connect to. Understand the full chain of trust – from the agent, through its permissions, down to the underlying infrastructure. Without this map, you’re securing the AI layer on top of a blind spot.
2. Apply strict least privilege to AI agent permissions. The data is clear: organizations where AI systems are over-privileged suffer incidents at a rate of 76%, versus 17% for those enforcing least privilege. Audit what your agents can actually access and remove permissions they don’t need. Pay special attention to production data stores and sensitive credentials.
3. Identify and fix infrastructure-level attack paths, not just individual vulnerabilities. The attack described above didn’t depend on a single catastrophic flaw. It worked because three moderate issues lined up in sequence. Security teams need tools and processes that surface these connected attack paths – chaining together cloud IAM misconfigurations, unpatched servers, and Active Directory weaknesses – before an attacker does it for you.
4. Include AI agent environments in your regular attack surface management. Traditional vulnerability scanning and pen testing often miss the unique risks AI deployments introduce. Make sure your regular security assessments cover the full environment your agents operate in, not just the AI components themselves.
5. Treat stored credentials as high-value targets. The AWS CLI keys on John’s workstation were the linchpin of the entire attack. Rotate stored credentials frequently, use temporary credentials wherever possible, and restrict when and where credentials can be used from.
AI agents are powerful tools, but their security is only as strong as the infrastructure beneath them. The path of least resistance for an attacker isn’t always a direct assault – sometimes it’s simply walking through an open door that was never connected to the AI in the first place.
