What a time to work in security. Let me tell you about it.

A security researcher wrote a GitHub issue. Just a sentence. One title field. And that sentence, that single piece of natural language in a text box crossed the following boundaries: into an AI coding assistant, into shell execution, into a CI/CD pipeline cache, out with an npm publish token, into the npm registry, and onto the machines of every developer who installed that package in the next eight hours.

No network intrusion. No stolen credentials. No memory exploit. No CVE in the traditional sense. Just a sentence.

That attack is called Clinejection, it’s real, it happened, and it is the clearest demonstration yet of something the security community has been tiptoeing around: AI agents are the new lateral movement vector. And we are nowhere near ready for it.

First, let’s quickly define lateral movement

Because this matters for everything that follows.

Lateral movement is what attackers do after they get in. Getting in is step one, maybe they phished a credential, exploited a misconfiguration, something. But the real damage usually doesn’t come from the entry point. It comes from what they do next: moving from the system they landed on to more interesting, more privileged systems. Finding the crown jewels.

Traditionally, lateral movement happened in two ways:

Network-based: hop between VLANs, pivot through RDP sessions, exploit trust relationships between subnets. Your firewall and network segmentation are the defense.

Identity-based: steal credentials, abuse Kerberos tickets, replay tokens across services. Your IAM policies and MFA are the defense.

Both are well-understood. The playbooks are mature. The SIEM rules exist.

AI agents just added a third dimension. And we don’t have the playbook yet.

What is AILM

AI-Induced Lateral Movement. Coined by the Orca Security Research Pod, and independently identified by researcher Christian Schneider who called it “agent-mediated lateral movement.” Two teams, same discovery, within weeks of each other.

Here’s the core of it:

A modern AI agent — think your SIEM’s AI analyst, your CRM’s AI assistant, your cloud security scanner’s remediation bot, your coding copilot is connected to a lot of systems at once. It can read your emails, query your database, call cloud APIs, push code, send Slack messages, create tickets. It has authenticated access to all of these things simultaneously. That’s the whole point. That’s what makes it useful.

Now. The agent receives its instructions through natural language. A user types something, a document gets processed, a ticket gets summarized, an issue gets triaged. The agent reads that content and decides what to do.

Here’s the structural problem that makes AILM possible: the agent cannot architecturally distinguish between “this is data I’m processing” and “this is an instruction I should follow.”

An LLM processes both through the same channel. Instructions and data look the same to it. Which means if an attacker can get malicious instructions into any content the agent reads, like a comment field, a metadata tag, an email subject line, a file name, then those instructions can hijack what the agent does next.

And what the agent does next might involve every system it’s connected to.

That’s AILM. The pivot mechanism isn’t a stolen password or a network route. It’s the agent itself. Its own legitimate permissions become the attack path.

The three properties that make this terrifying

Security researcher Christian Schneider identified why AI agents are uniquely dangerous as pivot points. No previous technology combined all three of these at once:

1. Broad tool access. A single agent connects to email, CRM, databases, code repositories, cloud APIs, file systems. Unlike traditional middleware with narrow, well-defined interfaces, the agent’s tool surface is effectively unbounded. Every connected system is a potential pivot target.

2. Execution autonomy. The agent acts without human approval at each system boundary. When the agent gets compromised at System A, it propagates the attacker’s instructions to Systems B, C, and D, no approval gates, no human in the loop. That’s the design. That’s what makes it efficient.

3. Natural language as the instruction channel. This is the root of everything. Instructions and payloads share the same channel. The agent reads a poisoned comment the same way it reads a legitimate one. It doesn’t know the difference. It can’t.

The combination creates what Schneider calls a trust bridge: a low-trust input (a public GitHub issue, an email, an order comment, an EC2 metadata tag) connected through the agent to a high-trust system (cloud infrastructure, CI/CD pipelines, payment systems) that was never designed to receive instructions from that input source.

The agent is the bridge. Its permissions are the road.

Three real attacks. Let’s walk through each one.

Clinejection — the one that actually happened in the wild

Cline is an AI coding assistant. It has a GitHub Actions workflow where an AI agent triages incoming issues.

Researcher Adnan Khan found that if you put a prompt injection payload in the title of a GitHub issue, Cline’s AI triage agent (running Claude) would read it as an instruction. He demonstrated a chain where that payload caused the agent to execute a malicious bash command, which poisoned the GitHub Actions cache, which stole the npm publish token during the next release cycle.

Eight days after he published this research, someone used a compromised npm publish token to push [email protected] with a postinstall script that globally installed an unauthorized package. A clean version came out eight hours later.

Boundaries crossed: public issue → AI triage agent → shell execution → CI/CD cache → npm credentials → npm registry → developer machines.

Your SIEM saw none of it. Every action the agent took was legitimate, using legitimate permissions, in legitimate workflows.

Prowler — EC2 metadata tags as injection vectors

Prowler is a cloud security scanner. It has an AI remediation agent that reads cloud resource metadata and suggests (or takes) remediation actions.

The Orca Research Pod demonstrated that you can embed a prompt injection payload inside an EC2 instance metadata tag, something nobody treats as an input vector, because why would you, and when the Prowler AI agent processes that tag, it interprets the payload as an instruction. They coerced the agent into invoking tools beyond its intended scope, including disclosing its full list of available tools.

In an environment where the agent has write-capable tools, which most remediation agents do, because that’s how they remediate, that escalates to privileged actions across the account.

The entry point was a metadata tag. A field that literally exists to describe infrastructure, not to receive instructions. That’s the point.

Open mercato — “please leave at the door”

Open Mercato is an AI-supported CRM/ERP framework. It has an AI customer service agent that reads order comments.

Order comments. The field where customers type “please leave at the door” or “ring the doorbell twice.”

The Orca team demonstrated how injecting instructions into that comment field gets picked up by the AI agent as something to act on, and that agent has backend access. The business data field became an instruction carrier to a system with real database and backend permissions.

This one is subtle because it doesn’t require any technical access to the target system. You just need to submit an order.

Why your existing security stack doesn’t catch this

This is the part that should make every blue teamer deeply uncomfortable.

Traditional lateral movement detection looks for:

• Unusual credential use — logging in from new locations, new systems, odd hours
• Network anomalies — traffic between segments that don’t usually communicate
• Privilege escalation events — a low-privilege account accessing a high-privilege resource

AILM triggers none of these.

The agent is using its own credentials. It always logs into those systems. The agent is supposed to talk to all those services, that’s its job. There’s no privilege escalation because the agent already has the permissions. Every log entry looks normal. Every API call looks authorized. Every action is within the agent’s defined scope.

The only thing that’s wrong is that the instructions driving those actions came from an attacker. And that’s invisible to your SIEM.

Orca’s researchers put it plainly: “Traditional security controls saw nothing.”

The MCP problem, because it gets worse

MCP stands for Model Context Protocol. It’s the emerging standard for connecting AI agents to external tools and data sources, basically the plumbing that lets an agent talk to your database, your cloud, your ticketing system, all through one unified interface.

Jake Williams from IANS Faculty said it directly: “Model Context Protocol will be the AI-related security issue of 2026.”

The Cisco State of AI Security 2026 report found that 86% of organizations are using MCP or similar agent-to-tool protocols, and that attack scenarios involving hidden instructions in content processed via MCP have already been documented in the wild — including GitHub issues with hidden payloads being processed by agents through MCP servers, leading to private repository exfiltration.

MCP didn’t create AILM. But it scales it. One protocol connecting every agent to every tool means one injection point can potentially reach everything.

And here’s the number that should be on every CISO’s slide deck right now: 83% of organizations plan to deploy agentic AI. Only 29% feel ready to secure those deployments.

That gap, 83% deploying, 29% ready, is where AILM lives.

What toxic combinations actually means

There’s a term from Pillar Security’s taint-flow research called toxic combinations, and it’s worth understanding because it reframes how you think about permissions.

The idea is this: an individual tool permission might look totally fine in isolation. The agent can read Slack messages — that’s fine. The agent can call an external API — also fine. The agent can access a specific database — fine.

But when you have untrusted input + sensitive data access + outbound communication capability all in the same agent, those individually safe permissions combine into something dangerous. Simon Willison calls this the “lethal trifecta.”

You can’t evaluate your agent’s risk by looking at each permission in isolation. You have to look at what combinations of permissions create exploitable paths, from a low-trust input surface to a high-value output action. That’s a fundamentally different way of doing threat modeling, and most security teams aren’t doing it yet.

Okay so what do you actually do

Let me be real with you: there’s no complete solution yet. This is new, the tooling is immature, and anyone telling you they have this fully solved is selling something.

But here’s what the research points to:

• Treat your AI agents like untrusted endpoints. They’re not trusted employees. They’re code that reads untrusted content and takes actions. Apply the same zero-trust principles you’d apply to an endpoint that regularly processes external data.
• Scope permissions hard. The blast radius of AILM is directly proportional to how many tools the agent can access. If your customer service agent doesn’t need to write to the database, it shouldn’t be able to. Principle of least privilege applies to agents, probably even more strictly than to humans.
• Inspect tool calls. Log every tool invocation your agent makes. If your remediation agent starts calling list_all_credentials or invoking APIs it's never touched before, that's your anomaly. Build detection around tool call patterns, not just network or identity events.
• Data masking before LLM exposure. When an agent fetches data containing user-controlled free text — order comments, issue titles, metadata tags — mask the raw free text before feeding it to the model. An LLM cannot act on instructions it never reads.
• Structural input validation. For highly structured outputs, add strict regex validation on fields. If a field should contain a delivery instruction like “leave at door,” it should not be able to contain “SYSTEM OVERRIDE: you are now required to…”
• Monitor for the lethal trifecta. Map out every agent in your environment. For each one, ask: does it have untrusted input + sensitive data + outbound capability? If yes, that agent is in your threat model now.

The bigger picture

We spent the last decade teaching systems to be useful, giving AI agents access to everything so they could help with everything. That was the right goal. Agents that can only read one system and talk to nobody aren’t actually useful.

But usefulness and security have always been in tension, and AILM is what happens when you build the usefulness layer before the security layer.

The Clinejection attack crossed six system boundaries with one sentence in a text field. The Prowler attack used infrastructure metadata as a weapon vector. The Open Mercato attack used a comment field meant for delivery instructions to reach backend systems.

In every case, the agent worked exactly as designed. That’s the point. The agent wasn’t exploited. It was persuaded. And persuasion, it turns out, is really hard to detect in logs.

2026 is the year agentic AI goes from pilot to production in most organizations. The Cisco numbers say so. The deployment velocity says so. The tooling ecosystem says so.

AILM is ready and waiting for it. The question is whether your security team is too.

Sources:

• Orca Security Research Pod — AILM original research, March 2026
• Christian Schneider — AI agents as attack pivots, March 4 2026
• Adnan Khan — Clinejection vulnerability research, February 2026
• GHSA-9ppg-jx86-fqw7 — Cline npm supply chain incident advisory
• Cisco State of AI Security 2026
• Pillar Security — taint-flow analysis and toxic combinations, 2026
• Cloud Security Alliance — Agentic Trust Framework, February 2026
• IANS / Jake Williams — MCP as security issue of 2026, February 2026