Read on if your organization deploys AI agents that connect to multiple systems — the lateral movement risk they introduce isn't just theoretical.
A third class of lateral movement
In February 2026, a security researcher disclosed how a single GitHub issue title – just a sentence with a prompt injection payload – could compromise an AI coding assistant’s entire CI/CD pipeline. Eight days later, an unauthorized party used exactly that to compromise an npm publish token to push a poisoned package update; every developer who installed during the eight-hour window before detection got an unwanted payload (details below). The attacker never touched a single target machine directly. The bridge between a public comment field and a privileged software supply chain was an AI agent doing exactly what it was designed to do: read issues, run commands, publish packages. Your SIEM wouldn’t have flagged any of it.
For decades, lateral movement meant one of two things. Network-based: an attacker hops between VLANs, pivots through RDP sessions, exploits trust relationships between subnets. Identity-based: stolen credentials, Kerberos ticket abuse, token replay across services. Both are well-understood, and the defense playbooks for both are mature.
AI agents introduce something different. They move across systems not through network connections or credential replay, but through natural language instructions and tool invocations. The agent doesn’t need network access to the target system – it already has authenticated API connections to multiple systems as part of its normal operation. An attacker who compromises the agent’s input doesn’t need to steal credentials or exploit a network path. The agent’s own legitimate permissions become the attack surface.
The obvious pushback: isn’t this just identity-based lateral movement? The agent has credentials, it uses authenticated APIs – that’s credential abuse, not a new category. The distinction matters. In identity-based movement, the attacker acquires identity material (tokens, tickets, secrets) and replays it across services. In agent-mediated movement, the attacker never touches the credentials. They subvert the decision layer that already wields legitimate identities, injecting control flow through untrusted content. The pivot is a confused-deputy attack – the agent acts on behalf of the attacker using its own ambient authority, not because the attacker stole anything, but because the agent was persuaded. That’s a fundamentally different defensive problem.
I’m calling this agent-mediated lateral movement – a third class of pivot that sits alongside the network and identity dimensions. Orca Security independently coined “AI Lateral Movement” to describe the same phenomenon, and their research provides compelling proof-of-concept evidence. But the structural pattern is broader than any single vendor’s framing: the Promptware Kill Chain analysis (Brodt et al.) shows how prompt injection has evolved into a multistep, malware-like process that enables lateral movement across agentic AI systems and connected resources. Something fundamental changed.
The numbers suggest this isn’t an edge case. The Cisco State of AI Security 2026 report found that 83% of organizations plan to deploy agentic AI, but only 29% feel ready to secure those deployments. That gap between deployment ambition and security readiness is where agent-mediated lateral movement thrives.
How agents become bridges
What makes agents uniquely dangerous as pivot points? No previous technology combined all three of these properties:
The combination creates what I think of as a trust bridge: a low-trust input surface (a public GitHub issue, an email, a Slack message) is connected through the agent to a high-trust system (CI/CD pipelines, cloud infrastructure, payment systems) that was never designed to receive instructions from that input source. The agent is the bridge, and its legitimate permissions are the road.
Terminology
Three terms recur throughout this post, and they’re worth pinning down here because the rest of the argument depends on them.
Attack chains: incident and demonstrations
This isn’t theoretical. The Clinejection supply chain compromise is a confirmed real-world incident. The other two cases that follow are staged security research demonstrations – but they show the same structural pattern generalizing across platforms: low-trust input, AI agent as pivot, high-trust action across a system boundary.
Clinejection: GitHub issue to npm compromise
Security researcher Adnan Khan discovered a vulnerability chain in the Cline AI coding assistant’s GitHub Actions workflow. The demonstrated attack chain: a crafted issue with prompt injection in the title triggered Cline’s AI triage agent (Claude). The agent executed a malicious bash command, which poisoned the GitHub Actions cache. The cached payload stole the npm publish token during the next release cycle.
Eight days after public disclosure, an unauthorized party used a compromised npm publish token (GHSA-9ppg-jx86-fqw7) to publish cline@2.3.0. The only modification: a postinstall script that globally installed an unauthorized package. A corrected version (2.4.0) was published roughly eight hours later. Only the CLI was affected – the VS Code extension and JetBrains plugin were not compromised. Public information confirms the token compromise and the unauthorized publish; whether the attacker executed every step of the demonstrated injection chain is not established in the advisory, but very likely.
Count the boundaries crossed: a public GitHub issue to an AI triage agent, to shell execution, to CI/CD cache state, to npm publish credentials, to the npm registry, and ultimately to developer machines. The agent bridged an untrusted comment field and a privileged software supply chain. No network intrusion. No memory exploit. Just a sentence in an issue title.
Agent-mediated lateral movement in cloud and e-commerce
Security researchers have demonstrated agent-mediated lateral movement (which they call “AI Lateral Movement”) across two platforms:
Here’s what gets me about both demonstrations: traditional security controls saw nothing. No network anomalies, no credential theft, no privilege escalation events in the logs. The agent used its own legitimate permissions at every step. If you’ve spent any time tuning SIEM rules for lateral movement detection, you’ll appreciate how completely this bypasses the playbook.
MCP as the literal bridge mechanism
The Cisco State of AI Security 2026 report documented attack scenarios where malicious GitHub issues with hidden instructions were processed by agents via Model Context Protocol (MCP) servers, leading to private repository data exfiltration. Cisco’s framing is direct: the “connective tissue” of the AI ecosystem has created “a vast and often unmonitored attack surface.”
I covered MCP-specific attack vectors in depth in my MCP security architecture post. What this post adds is the broader pattern: MCP is one bridge mechanism, but the agent-as-pivot problem exists regardless of the specific protocol. If you’re evaluating MCP servers for your agent stack right now, that post is the place to start.
Jake Williams (IANS Faculty) puts it bluntly: "[Model Context Protocol] will be the AI-related security issue of 2026" (IANS, February 2026).
Mapping to the five-zone lens
In my threat modeling post, I introduced a five-zone discovery lens for tracing attack paths through agentic systems. Every agent-as-pivot attack maps to this framework, and seeing the pattern helps explain why traditional security controls miss them:
The attack enters through Zone 1, hijacks Zone 2, executes through Zone 3, persists via Zone 4, and propagates through Zone 5. Traditional security tools typically monitor within a single zone. Agent-mediated lateral movement crosses all five.
Notice the pattern across every case: the attacker did not breach the network perimeter or exploit a software vulnerability. Instead, they injected instructions into an AI-powered workflow. The agent’s own legitimate permissions were the entire attack surface. That changes how you defend.
Framework convergence
What convinced me this is a real structural shift, not just a collection of incidents, is the framework convergence. Six independent organizations arrived at the same conclusion from different angles:
The terminology converges across independent sources: Cisco warns that the “connective tissue” linking agents, models, and enterprise systems is an unmonitored attack surface. F5 and others describe the security challenge of securing AI-driven integrations and runtime pathways that didn’t exist before. When multiple research groups and industry players independently describe the same structural phenomenon with parallel metaphors, it underscores that this isn’t just theoretical.
The security paradox
There’s an irony here that’s worth sitting with. Security AI agents – the ones designed to monitor, detect, and respond – require access to SIEM data, vulnerability scans, threat intelligence, identity stores, and network topology. If compromised, an attacker doesn’t just get data access. They get a complete map of what you can detect, what you can’t, where your blind spots are, and how you respond. The agent designed to protect the infrastructure becomes, if compromised, the most valuable pivot point in the entire environment.
Every post in this series has focused on business AI agents – coding assistants, customer service bots, enterprise automation. But the same structural vulnerabilities apply to security agents, with higher-value data access and broader system visibility. If you’re deploying AI into your SOC, this isn’t a “nice to consider.” It’s the highest-stakes version of the trust bridge problem.
Treating agents as trust boundaries
So how do you defend against a pivot that uses legitimate permissions, generates no network anomalies, and crosses systems through natural language? Not by watching for the attack – by that point it looks identical to normal agent behavior. The answer, I think, comes from treating every agent as a trust boundary – not just a tool, but an entity that requires the same scrutiny as a privileged user or a network perimeter.
The Agentic Trust Framework (Josh Woodruff, CSA, February 2, 2026) structures this around five questions:
What to do about it
If you take one thing from this post, let it be this: agents are trust boundaries. Treat them like you would treat a privileged user account or a network perimeter, not like a productivity tool.
Start by mapping your agent bridges. For every deployed agent, identify which systems it connects and which of those connections cross trust boundaries. If an agent reads from an untrusted source and writes to a privileged system, you have a trust bridge that needs controls.
Then break the toxic combinations. Segment agent tool access so that no single agent spans a low-trust input and a high-trust output. This is network segmentation thinking applied to tool access. Use OWASP AIVSS to score each agent deployment: its Agentic AI Risk Score layers amplification factors (autonomy, tool access, multi-agent interactions) on top of CVSS base scores, giving you a single number to prioritize the deployments with the widest bridge spans.
Traditional SIEM rules won’t catch an agent using its own legitimate permissions to pivot across systems – there are no anomalous network connections or failed logins to trigger alerts. You need behavioral baselines specific to agent activity. At minimum, log five things per agent action: input provenance (source system and trust label), tool invocation (tool name, arguments, result size), policy decision (allowed or blocked, with reason), human approval events (when required), and cross-system side effects (any write actions). Alert when the pattern shifts, not when a rule fires. If your cloud security agent suddenly starts querying HR data it has never touched before, that deviation is your detection signal. This directly aligns with MITRE ATLAS mitigations around restricting tool invocation on untrusted data and requiring human-in-the-loop for high-risk agent actions.
Finally, prepare for the supply chain scenario. The Cisco State of AI Security 2026 report warns of a “SolarWinds of AI” – a mass compromise through a widely used AI library or foundation model. Your agent inventory and kill-switch capability determine how quickly you can respond. Audit your agent dependencies the way you audit npm packages: pin versions, review changelogs, and maintain a revocation path for each major integration.
Treat your agents as trust boundaries, not just productivity tools. Unscoped agents don’t automate work—they automate compromise.