The Sentence That Stole an npm Token: How AI Agents Became the Third Class of Lateral Movement
In February 2026, security researcher Adnan Khan wrote a GitHub issue title. It was a single sentence containing a prompt injection payload. That sentence caused an AI coding assistant's triage agent to execute a malicious bash command, poison a GitHub Actions cache, and steal an npm publish token. Eight days later, an unauthorized party used that token to publish a poisoned version of the cline npm package. Every developer who installed during the eight-hour window before detection got an unwanted payload.
No network intrusion. No credential theft. No memory exploit. No CVE in the traditional sense. 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. A SIEM trained on network anomalies and credential replay saw nothing this entire time.
This is not a one-off incident. It is the first documented case of a new attack class — agent-mediated lateral movement — and the security community is converging around a recognition that existing detection paradigms do not cover it.
The Third Class of Lateral Movement
For decades, lateral movement meant one of two things:
Network-based: an attacker exploits trust relationships between subnets, pivots through RDP sessions, moves laterally across VLANs. The defense playbook is mature: network segmentation, microsegmentation, east-west traffic monitoring.
Identity-based: stolen credentials, Kerberos ticket abuse, token replay across services. The defense playbook is also mature: MFA, privileged access management, anomaly detection on authentication patterns.
AI agents introduce a third class that fits neither category. Agents move across systems not through network connections or credential replay, but through natural language instructions and legitimate tool invocations. The agent already has authenticated API connections to multiple systems as part of its normal operation. An attacker who compromises the agent's input does not need to steal credentials or exploit a network path. The agent's own legitimate permissions become the attack surface.
This distinction matters for defense design. In identity-based lateral movement, the attacker acquires identity material (tokens, tickets, secrets) and replays it across services. The behavior is anomalous — new device, new location, unusual access pattern — and detection engineering is built around identifying that anomaly.
In agent-mediated lateral movement, the attacker never touches the credentials. They subvert the decision layer that already wields legitimate identities, injecting control flow through untrusted content. 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. Every individual step looks normal: the agent reads an issue (as it does hundreds of times per day), runs a command (as it does), publishes a package (as it does). The attack is invisible to behavioral baselines because it is behaviorally identical to legitimate operation.
The Trust Bridge: How Agents Connect Untrusted Inputs to Privileged Systems
What makes agents uniquely dangerous as pivot points? No previous technology combined all three of these properties:
Broad tool access. A single agent connects to email, CRM, databases, code repositories, cloud APIs, and file systems — a tool surface that is effectively unbounded. Each connected system is a potential pivot target.
Execution autonomy. The agent acts without human approval at each system boundary. When a vulnerability is exploited in System A, the agent propagates the attacker's instructions to Systems B, C, and D without anyone reviewing the action.
Natural language as the instruction-data channel. This is the root of the problem. Instructions and malicious payloads share the same channel — the agent literally cannot distinguish trusted instructions from untrusted data at an architectural level. The Cloud Security Alliance's Agentic Trust Framework calls this the collapsed "instruction boundary."
The combination creates a trust bridge: a low-trust input surface (a public GitHub issue, an email body, 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.
The Attack Chains: Real-World and Demonstrated
Clinejection: GitHub Issue → npm Compromise
The original demonstration: a crafted GitHub issue with prompt injection in the title triggered Cline's AI triage agent. 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 disclosure, an unauthorized party published cline@2.3.0 with a postinstall script that globally installed an unauthorized package.
Count the boundaries crossed: public GitHub issue → AI triage agent → shell execution → CI/CD cache state → npm publish credentials → npm registry → developer machines. Seven trust boundaries. One sentence.
Cloud Infrastructure Tags → Privileged Account Actions
Orca Security researchers demonstrated the same structural pattern against Prowler, a cloud security scanner. Prompt injection was embedded in EC2 instance metadata tags — a field rarely treated as an input vector. The AI remediation agent processed the tags as instructions and was coerced into invoking tools beyond its intended scope. In environments with write-capable tools, the same pattern can escalate to privileged actions across the account.
Order Comments → Backend System Compromise
In a separate attack hypothesis against Open Mercato — an AI-supportive CRM/ERP framework — an order comment field meant for "please leave at the door" carried injected instructions to an AI customer service agent. The agent processed the comment and was steered toward backend access it should not have exercised. A business data field became an instruction carrier for an agent with backend privileges.
In every case, 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.
Toxic Combinations: When Individual Tool Permissions Compound
What makes the trust bridge especially dangerous is that the individual pieces often look harmless in isolation. Pillar Security calls this pattern toxic combinations — what happens when individually safe tool permissions combine through an agent to create dangerous input-output paths. Simon Willison calls it the "lethal trifecta": sensitive data, untrusted inputs, and outbound communication in the same agent context.
An agent that reads GitHub issues, runs shell commands, and publishes packages is not obviously dangerous if you review each tool in isolation. Reading issues is necessary for triage. Running commands is necessary for CI/CD. Publishing packages is the desired output. The combination — an untrusted input channel bridged through command execution to a privileged output channel — is what creates the trust bridge. And traditional permission models, including RBAC, are structurally unable to detect this combination because they evaluate permissions statically, not in the context of specific input-output flows.
The Defense Framework: Breaking the Trust Bridge
Defending against agent-mediated lateral movement requires architectural changes to how agents are deployed, not just better monitoring of what they do.
1. Treat Agents as Trust Boundaries, Not Trusted Processes
Every agent that spans multiple systems is a trust boundary — not a trusted process operating inside the boundary. This means applying zero-trust principles to agent deployments: authenticate every tool invocation independently, authorize at the tool level rather than the agent level, and enforce least privilege at runtime rather than at configuration time.
2. Agent-Specific Identity with Scoped Credentials
Agents should not inherit user credentials or use shared service accounts. Each agent gets its own identity, and that identity receives credentials scoped to the specific tools and operations required for the current task — issued at task invocation and expired when the task ends. An agent with a GitHub issue reader identity cannot publish npm packages, regardless of what any injected instruction says, because the identity does not carry that permission.
Facio (the HITL-first agent runtime) enforces this at the platform level: every tool invocation passes through policy evaluation before execution. The agent cannot access a tool it should not have — not because a guardrail might catch it, but because the runtime never provisions the credential.
3. Taint Tracking Across the Instruction-Data Boundary
The Cloud Security Alliance's Agentic Trust Framework recommends content taint tracking: marking content from untrusted sources (public GitHub issues, emails, Slack messages, EC2 metadata) as untrusted, and preventing agents from acting on that content without validation. The implementation is non-trivial but the principle is sound: if an instruction originated from an untrusted source, it should not be treated as an instruction.
4. Agent Segmentation and Isolation
Just as network segmentation limits the blast radius of a network compromise, agent segmentation limits the blast radius of an agent compromise. An agent that processes public GitHub issues should not be the same agent that publishes npm packages. The trust bridge is broken not by detecting the attack, but by making it architecturally impossible — the input-side agent and the output-side agent are different identities with different permissions.
5. Human Review at System Boundaries
When an agent crosses a system boundary — from reading an issue to modifying CI/CD state, from processing an order comment to accessing backend infrastructure — that boundary crossing should require human review. Not for every action, but for every new type of transition. Placet.io (the HITL inbox and messenger) delivers these structured approval requests to the right reviewers, creating an audit record of every permission boundary crossing.
6. Runtime Anomaly Detection, Not Pattern Matching
Traditional SIEM detection looks for known patterns: unusual network connections, credential replay, privilege escalation calls. Agent-mediated lateral movement produces none of these. Runtime anomaly detection for agents requires a different signal set: tool invocation sequences that include untrusted inputs, tools called with parameters originating from external data fields, and unexpected system boundary crossings — specifically, a tool invocation from a source system (issue reader) followed by a tool invocation in a target system (package publisher) where the target system tool invocation's parameters contain data from the source system.
The Bottom Line
Agent-mediated lateral movement is not a theoretical concern. It is a demonstrated attack class with a confirmed real-world incident. The defense playbooks for network-based and identity-based lateral movement do not apply because the attack mechanism — natural language instruction injection into an autonomous agent — produces no signals those playbooks are designed to detect.
Cisco's 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. The gap between deployment ambition and security readiness is where agent-mediated lateral movement thrives.
The organizations that will avoid being the next Clinejection incident are not the ones with better SIEM rules. They are the ones that treat agents as trust boundaries, enforce agent-specific identity and tool-level credential scoping, implement segmentation between input-side and output-side agents, and apply human review at system boundary crossings.
The alternative is discovering a trust bridge only after someone has already crossed it.
Further reading: