Agentic Red-Team Tools Flaws Let Hackers Steal API Keys, Escape Sandboxes, and ...

Agentic red-team tools designed for autonomous offensive security operations are themselves vulnerable, allowing attackers to steal API keys, weaponize the agents, escape sandboxes, and fully compromise the hosts that run them.

A new academic study by Arxiv presents the first in-depth security analysis of 12 widely used agentic offensive security systems, concluding that most systemic design flaws that attackers can reliably exploit from the very targets they are testing.

These agentic red-team platforms consist of three major components: an orchestrator that manages the agent’s loop, memory, skills, guardrails, and persistence; one or more worker nodes (typically Kali Linux containers) that execute raw shell commands and offensive tools; and a front-end interface for human operators, which can be accessed via CLI, TUI, or a web interface.

The orchestrator often stores sensitive assets, such as LLM ( large language model ) API keys and cross-session logs, while the workers directly interact with external targets and networks.

Instead of classic prompt injection attacks, the researchers introduce “agent-phishing,” a manipulation technique that does not rely on prompt injection and is specifically tailored for agentic red teams.

They stage realistic artifacts, such as a password vault utility (pwcrypt), a database restore helper, or a configuration unpacker, on a honeypot target, making them appear as critical components necessary to complete the penetration test.

When the agent engages with the honeypot, it discovers these artifacts, downloads them to its own infrastructure, inspects them, and ultimately executes them, believing this is the correct way to progress in the engagement.

The payloads are not overtly malicious; rather, they embed carefully engineered vulnerabilities. For example, in the case of pwcrypt, a crafted vault file triggers an out-of-bounds write to a metadata buffer, potentially overwriting a function pointer table.

This leads to an integrity-check callback that ultimately calls the system() function with arguments controlled by the attacker.

From the agent’s perspective, running the tool on the vault cleanly decrypts a password and then exits; however, the reverse shell or arbitrary command execution occurs as a silent side effect of parsing, and there are no obvious indicators of malware in the binary itself.

Both static and dynamic analysis focused on traditional signatures that only identify an implementation bug, not explicit malicious intent.

Using an automated testbed that replicates the agents’ prompts and tool interfaces, the authors demonstrate that this technique is scalable.

Across ten agentic red-team tools and six advanced LLMs, including Claude Opus 4.8 , GPT-5.5, and Gemini 3.1 Pro, agent-phishing payloads achieve remote code execution (RCE) inside the worker environment in 97.8% of completed runs.

Failures occur only when model-level safety mechanisms refuse to perform penetration testing altogether; once a test begins, the agent almost always finds, downloads, and executes the staged payload after inspection.

Once worker RCE is achieved, the paper outlines a tailored kill chain for escalation. Stage one involves compromising the worker; stage two focuses on privilege escalation from the worker to the orchestrator, which can occur via incomplete filesystem isolation (shared writable volumes exposing orchestrator code or configurations) or weak network isolation (workers having host networking or access to unauthenticated internal APIs).

Stage three addresses persistence, either through “hard” methods (trojanizing source code or configurations that survive container resets) or “soft” methods (poisoning long-lived inputs like skills and episodic memory, which can reinfect future sessions).

Stage four involves sandbox escape, often enabled by overly permissive container capabilities like –privileged, CAP_NET_RAW, or mounted Docker sockets. Stage five culminates in full host compromise.

Critically, existing guardrails are shown to be ineffective once the worker is compromised. Policies are enforced at the orchestrator level, for instance, blocking Nmap traffic to .gov domains.

However, they do not monitor or restrict the workers’ actual OS-level behavior. An attacker with a shell on a worker can generate arbitrary network traffic and execute commands outside the guardrails’ visibility, enabling unbounded agent weaponization and covert abuse of the victim’s infrastructure.

To mitigate these risks, the authors argue that security architectures should treat the LLM-controlled worker as untrusted and focus on minimizing its blast radius.

They recommend maintaining strict worker-orchestrator separation, keeping secrets out of workers, enforcing robust OS-level guardrails via an external egress proxy, avoiding tool execution on the orchestrator, and using least-privileged, scoped workers, with high-capability tools running only through narrow, hardened APIs.

Divya is a Senior Journalist at GBhackers covering Cyber Attacks, Threats, Breaches, Vulnerabilities and other happenings in the cyber world.

A critical unauthenticated remote code execution (RCE) vulnerability in Langflow, tracked as CVE-2026-33017, is being…

The curl project has announced the release of version 8.21.0, marking its 275th release and…

A concise but sophisticated phishing campaign that targeted AWS console users by abusing Cloudflare-hosted domains…

Google has released Chrome version 149.0.7827.196/197 for Windows and macOS, and version 149.0.7827.196 for Linux.…

The binary tracked as macOS.Gaslight as a Rust-based macOS implant and infostealer whose most novel…

A newly disclosed vulnerability in the Microsoft Windows Recovery Environment (WinRE) could allow attackers to…