Agentic red-team tools can be hijacked by their own targets

What is this?

On June 23, 2026, Dario Pasquini and colleagues at Cracken (with a contributor from Lviv Polytechnic National University) published Red-Teaming the Agentic Red-Team (arXiv:2606.24496). It is the first in-depth security analysis of the tools that many practitioners now use to automate offensive security: agentic penetration-testing and red-team systems that drive reconnaissance, exploitation and post-exploitation with little or no human involvement.

The uncomfortable finding is that these tools are themselves poorly defended. Across 12 widely used systems — including CAI, RedAmon, PentestAgent, DarkMoon, PentAGI, AIRecon, PentestGPT, METATRON, nebula, xalgorix, Artemis and STRIX — the authors show that an adversary who controls the target of an operation can turn the tables: exfiltrate the operator’s LLM API keys, plant a persistent foothold, and ultimately compromise the operator’s own machine, even when the agent runs inside a sandboxed container. This is a class-of-vulnerability writeup, not a payload drop.

How it works

The manipulation starts where the agent least expects it: in the output of the very systems it is attacking. An offensive agent feeds command results, scraped pages and service banners back into its LLM as context. A target that returns crafted content can steer the agent’s reasoning — not through an explicit “ignore previous instructions” string, but through contextual deception and reward hacking. The paper describes a prompt-injection-free manipulation that drives near-deterministic code execution on the agent’s worker even with frontier models such as Claude Opus 4.8, GPT-5.5 and Gemini 3.1 Pro, borrowing ideas from antivirus-evasion to disguise the malicious behavior as a legitimate step toward the agent’s goal.

The authors abstract the escalation into a full kill chain tailored to these tools: initial LLM manipulation, code execution on the worker, lateral movement, persistence, guardrail bypass, sandbox escape, and finally host compromise. Two recurring architectural weaknesses do most of the damage. First, weak filesystem isolation: many tools share a writable directory (a bind mount or Docker volume) between the low-trust worker and the higher-trust orchestrator, so an attacker who runs code in the worker can trojanize live source files the orchestrator later loads — hard persistence and a path to lateral movement. Second, weak network isolation and over-broad channels: orchestration APIs meant only for the UI are reachable from the worker, and orchestrator code that parses worker output is exposed to classic injection bugs — shell metacharacters, template escapes, unsafe deserialization — that convert a data channel into remote code execution.

Why it matters

Offensive-security agents run with unusually dangerous privileges: broad network reach, valuable API keys, and the operator’s implicit trust. They also, by design, spend their whole life ingesting attacker-controlled data. That is the lethal trifecta taken to its logical extreme, and it means the sandbox around the worker is not the security boundary people assume — the paper shows host compromise is reachable regardless of sandboxing in most tools tested. For anyone deploying these systems against real adversaries — including red teams, MSSPs and, increasingly, defenders emulating threats — a booby-trapped target is no longer hypothetical. The same prompt-injection-to-RCE pathway seen in general agent frameworks applies here, with the twist that the attacker already owns the environment the agent is told to attack.

Defenses

The paper’s core lesson is architectural: stop assuming the LLM will reliably refuse malice, and enforce a hard privilege boundary in the harness instead. Treat every byte the worker produces as untrusted input that must be scrutinized before it reaches the orchestrator. Concretely, the authors recommend keeping the orchestrator and worker in separate OS/containers and network segments, exposing only the minimal ports needed; avoiding shared filesystem mounts entirely and moving artifacts through a single, narrowly scoped, auditable channel (with human-approval or content-inspection gates) rather than a shared directory; and keeping the orchestration layer tool-free, delegating all command execution to the worker so a compromised worker cannot pivot upward. Harden the command-response channel against injection the same way you would any parser handling hostile input, and rebuild worker containers for each operation so persistence cannot survive. Least privilege — not optimistic trust in model alignment — is the load-bearing principle. These controls echo the broader point that sandbox escapes in code-executing agents are a systems problem, not a model problem.

Status

Red-Teaming the Agentic Red-Team is a research disclosure (arXiv:2606.24496, posted June 23, 2026) covering 12 named tools; the authors summarize per-tool attacker capabilities and propose a reference secure architecture rather than releasing weaponized exploits. There is no single CVE — the contribution is a shared design-flaw taxonomy and a defensive blueprint. Teams running any agentic offensive-security tooling should audit their deployment against the paper’s kill chain now: verify worker/orchestrator isolation, remove shared mounts, and confirm that a hostile target cannot reach anything beyond a disposable worker sandbox.