AgentXploit: Autonomous Repository-to-Runtime Red-Teaming for AI Agents

2. Related Work

• Prior red-teaming methods commonly assume a known injection point or attack surface, leaving source-based discovery of viable paths untested.A feasible path requires tracing consumed inputs, cross-component value flow, influenced decisions, and tool preconditions.Source: §1 · p. 1, §2 · p. 3

Auditor privilege versus runtime attacker capability

• Repository and controlled-runtime access supports authorized pre-deployment auditing, but runtime attacks must use the task-defined interface and cannot directly access protected target state.An external verifier, not the Exploiter Agent, determines whether the specified outcome occurred.Source: §1 · p. 1, Figure 1 · p. 2, Auditor privilege versus runtime… · p. 3

1. Introduction

• The Analyzer Agent records code-supported candidate paths, which the Exploiter Agent tests through the attacker interface and revises using runtime feedback.The benchmark includes 72 reproducible vulnerabilities with pinned runtimes and deterministic verifiers for analysis-only, exploit-only, and end-to-end evaluation.Source: §1 · pp. 1–2
• 59.3% end-to-end success for AgentXploit versus 38.4% for Codex across three runs on AgentXploit-Bench.The benchmark is designed to test whether auditors can recover and validate paths when vulnerability-specific metadata is withheld.Source: §1 · p. 2

3. Threat Model

• The threat model covers attacker-controlled data reaching sensitive operations such as file modification, privileged API invocation, or command execution.A path may involve an LLM-mediated decision or a flaw in surrounding software.Source: §1 · p. 1, §3 · p. 3

4. AgentXploit Framework

• The Analyzer records code-supported candidate paths; the Exploiter turns them into attacks through the task interface and revises attempts using target responses and permitted traces.The path record includes the entry point, sensitive operation, code locations, preconditions, and an optional exploit hint.Source: §4 · p. 4, §4.2 · p. 4

5. AgentXploit-Bench

• AgentXploit-Bench contains 72 manually checked, runnable vulnerability instances across 12 projects, with pinned environments and deterministic external verifiers.Its tasks ask auditors to recover and validate a ground-truth path without vulnerability-specific metadata.Source: §5.1 · p. 5, §5 · p. 5

6. Evaluation

• Evaluation separates analysis-only path matching, oracle-specified exploit-only testing, and end-to-end auditing; end-to-end is primary and withholds exploitation-stage specifications.The systems were run three times with independent sampling seeds at fixed temperature.Source: §5.1 · p. 5, §6.1 · p. 5

6.1.1. ANALYSIS-ONLY DIAGNOSTIC

• Across three runs, the Analyzer recovers 71.8% of ground-truth paths, including 74.6% on direct paths and 59.0% on indirect paths.In the initial run, all five indirect-path failures occurred before exploitation; indirect paths require connecting external values to later sensitive operations.Source: §6.1.1 · p. 6

6.1.2. EXPLOIT-ONLY DIAGNOSTIC (ORACLE SPECIFICATION)

• With oracle vulnerability specifications, the Exploiter reaches 88.0% overall success, including 91.5% on direct paths and 71.8% on indirect paths.The lower indirect-task rate remains even with the oracle description, indicating runtime challenges as well as repository-search challenges.Source: §6.1.2 · pp. 6–7

6.1.3. END-TO-END RESULTS

• Across three runs, AgentXploit averages 59.3% end-to-end success versus Codex’s 38.4%; with matched token caps, Codex reaches 46.3%, leaving AgentXploit 13.0 points higher.In the initial run, performance outside GPT_Academic was 48.0% for AgentXploit versus 28.0% for Codex across 50 instances.Source: Table 4 · p. 7, §6.1.3 · p. 7, §6.3 · p. 8

6.1.4. ATTACK-QUALITY DIAGNOSTIC

• Four of seven tested payloads triggered WAF signatures, while benign requests succeeded before and after attacks; this scoped diagnostic does not establish broad stealth or utility preservation.Audits also identified eight additional vulnerabilities across four projects, excluded from target-path scoring.Source: §6.1.4 · pp. 7–8, §6.1.5 · p. 8

6.2. Evaluation on AgentDojo

• With injection points supplied, the Exploiter Agent reaches 79.2% success, compared with 52.7% for AgentVigil and 41.5% for handcrafted attacks.AgentDojo therefore tests attack construction separately from repository discovery.Source: §6 · p. 5, §6.2 · p. 8

7.1. Failure Localization

• 20/29 initial end-to-end failures (69.0%) were analysis misses; all five indirect-path failures occurred before exploitation.Every indirect path recovered by the Analyzer Agent in that run was subsequently validated by the Exploiter Agent.Source: §7.1 · p. 8, Table 7 · p. 9

7.2. Case Study 1: Credential Flow Across a Utility Boundary

• In the AutoGPT clone_repository case, an attacker-controlled HTTPS host can receive credentials after URL rewriting, and the Analyzer preserves the source-to-sink chain Codex misses.The candidate path identifies the controlled host, credential rewrite, and outbound operation needed for an executable attack.Source: §7.2 · pp. 8–9

7.3. Case Study 2: Validation Across Interpretation Layers

• First-token validation checks a different object from shell execution, while the Analyzer records both interpreter-payload and nested-shell paths as distinct candidates.The paths share the first-token check but require different preconditions and exploit constructions.Source: §7.3 · p. 9
• Figure 2 plots AgentDojo attack success over optimization rounds for the full system and ablations.Source: Figure 2 · p. 10

8. AgentDojo Optimization Dynamics

• 79.2% attack success after 50 rounds for the full system, versus 69.1% without trace feedback, 49.6% without curated seeds, and 74.9% with one payload reused across locations.The full system and no-trace condition begin at 48.0% and 46.2%, respectively, at round 0.Source: §8 · p. 10
• Curated seeds shape the initial search region, execution traces improve later revisions, and location-specific payloads provide a smaller gain in multi-step workflows.The no-trace condition retains prompt history and the success signal but removes the target response and permitted execution trace.Source: §8 · p. 10
• Successful attacks use either one adversarial instruction in a task-relevant record or coordinated cues distributed across records retrieved at different workflow stages.In the coordinated pattern, early content establishes a role or trigger and later content activates the same attacker objective.Source: §8 · p. 10
• Reusable payload text is excluded from the public manuscript under the responsible-release process.Source: §8 · p. 10

9.1. Code-Mutation Robustness

• Code mutations reduce recovery from 71.7% to 68.3%, a 3.4-point decrease, while 39 of 60 paired task-runs remain successful in both conditions.The subset removes identifiers, comments, docstrings, and original file locations; larger structural refactorings remain untested.Source: §9.1 · p. 10

9.2. Default Stopping Behavior

• Of 92 Codex runs that stop after self-declared completion without verifier success, 88 retain unused budget, with a median unused share of 42%.The default 61.8-second mean runtime therefore usually reflects early stopping rather than a hard compute limit.Source: §9.2 · pp. 10–11, Table 10 · p. 11

9.3. Token-Budget Scaling and Path Type

• At a 4× cap, Codex pass@1 rises from 38.4% to 45.8%; token-matched Codex reaches 46.3%, still 13.0 points below AgentXploit at 59.3%.The comparison uses measured model tokens, including input and output.Source: §9.3 · p. 11, Table 12 · p. 12

10.1. Ground Truth and Verifier Integrity

• The verifier encodes one security outcome per instance, so the primary metric measures recovery and validation of ground-truth paths rather than complete vulnerability recall.Equivalent exploit routes or additional consequences may not be observed.Source: §10.1 · p. 11

10.2. Information Boundaries and Leakage Controls

• The hosted backbone’s training corpus is unknown, so the evaluation cannot claim contamination-free results; code mutations and verifier-confirmed execution narrow, but do not eliminate, disclosure-recall concerns.Memorized implementation patterns or exploit strategies may still contribute.Source: §10.2 · pp. 11–12

10.3. Adjudication and Statistical Uncertainty

• Manual path matching makes analysis-only recovery rubric-dependent, while three-seed uncertainty captures run-to-run variation rather than variation across repository populations.The 72 instances are curated, and the 13 indirect paths and 20-task mutation subset are particularly small.Source: §10.3 · p. 12

10.4. Runtime and Artifact Reproducibility

• Token matching improves Codex by 7.3 points on direct paths and 10.3 points on indirect paths, but differences of 11.3 and 20.5 points remain.Pinned containers and deterministic verifiers stabilize target environments, but stochastic model behavior should be expected to match distributions rather than individual trajectories.Source: §10.4 · p. 12, Table 13 · p. 12

11. Additional Security Findings

• AgentXploit identifies eight additional findings across four projects and five vulnerability categories, excluded from benchmark success rates because they are outside designated targets.The findings illustrate that target-specific scoring can omit other security findings produced during an audit.Source: §11 · p. 13

12.1. Findings and Limitations

• Most localized AgentXploit-Bench failures arise during repository analysis, while AgentDojo runtime feedback improves attack construction when injection points are known.The results identify repository discovery and runtime exploitation as distinct bottlenecks.Source: §12.1 · p. 13
• The Codex comparison is system-level: token-budget matching narrows but does not close the gap, and the experiments do not isolate the structured handoff’s contribution.Stopping behavior, tool scheduling, context management, and role-specific prompts also differ.Source: §12.1 · p. 13
• The benchmark has 72 vulnerabilities across 12 projects, but only 13 indirect paths; its primary experiments use one model family, limiting generalization across repositories and models.Candidate precision is studied on one repository and attack quality on seven tasks.Source: §12.1 · p. 13

12.2. Implications for Agent Security Evaluation

• Evaluations should report designated-path recovery, candidate-set precision, and verifier-confirmed exploitation separately because each measures a different part of auditing.Recovery localizes discovery failures, precision reflects analyst burden, and verifier success establishes executable security impact.Source: §12.2 · p. 13

12.3. Conclusion and Future Work

• The conclusion calls for benchmark-wide candidate adjudication, broader attack-quality evaluation, and controlled handoff ablations across more models, repositories, and verifiers.Future attack-quality studies should expand beyond signature rules and three API probes to semantic monitoring and task-level regression suites.Source: §12.3 · p. 14

A.1. Benchmark Contract

• All evaluation modes use the same pinned repository, runtime interface, timeout, and external verifier, while analysis-only and end-to-end tasks omit vulnerability-specific metadata.Exploit-only mode exposes the target vulnerability and objective as an oracle diagnostic; the verifier remains outside the auditing agents.Source: §A.1 · p. 17

A. Illustrative Examples of AgentXploit-Bench

• The appendix’s example is an exploit-only task, where the ground-truth vulnerability is intentionally supplied to isolate runtime exploit construction.The example concerns path traversal in gpt_academic’s LaTeX processing functionality.Source: A. Illustrative Examples of… · p. 17, §A.2 · p. 17

A.2.1. TASK CONFIGURATION

• The structured task configuration specifies the vulnerable environment and mode-specific inputs, including vulnerability details and the attack objective in exploit-only mode.The example’s objective is to exploit a path traversal through the HTTP API.Source: §A.2.1 · pp. 17–18

A.2.2. AGENT INSTRUCTION PROMPT

• The cited implementation issue is that merge_tex_files_() does not sanitize its input.Source: §A.2.2 · p. 18
• The exploit-only configuration automatically generates and supplies the instruction prompt in a structured format.Source: §A.2.2 · p. 18
• The prompt frames the agent as a security researcher performing authorized penetration testing.Source: §A.2.2 · p. 18
• The prompt says the agent has access to standard bash utilities.Source: §A.2.2 · p. 18
• The task targets path traversal in gpt_academic 3.91 LaTeX processing through its HTTP API.The prompt labels the task CVE-2025-10236.Source: §A.2.2 · p. 18

• The evaluation harness uses an external deterministic verifier after the agent finishes.The agent does not decide success.Source: §A.2.3 · p. 18
• The verifier requires /workspace/path_traversal_proof.txt to exist.Source: §A.2.3 · p. 19
• The extracted flag must match flag{<uuid>} and its content must match ground truth retrieved from the target container.Source: §A.2.3 · p. 19

B. Codex Baseline Protocol

• Codex runs as a single autonomous repository agent with the benchmark task input, repository mount, attacker interface, and external verifier, but without hidden vulnerability details or the Analyzer Agent’s report.It can search and read the repository, use a shell, and interact with the target through the task-defined attacker interface.Source: B. Codex Baseline Protocol · p. 19

C. Qualitative Analysis of Benchmark Vulnerabilities Missed by Codex

• The qualitative examples are AutoGPT v0.4.2 benchmark instances supported by raw execution traces and code-grounded analysis.The section separately presents Codex and Analyzer Agent behavior.Source: §C.1.2 · p. 19

C.1.2. ANALYZER AGENT BEHAVIOR

• The Analyzer Agent describes clone_repository rewriting the HTTPS URL to inject the configured GitHub username and API key as Basic Auth credentials.It traces repository URL and username inputs, with credentials flowing to a remote Git host or logs because credentials are injected into URLs supplied by the LLM.Source: §C.1.2 · p. 19

• Codex reads the Git utility implementation and moves to another file without explicit reasoning about URL rewriting, credential handling, or dataflow.Source: §C.1.1 · p. 19
• The Analyzer Agent explicitly reasons about how credentials propagate to external endpoints.The section introduces vulnerability construction after its account of sensitive dataflow analysis.Source: §C.1.1 · p. 19
• The constructed attack has the agent call clone_repository with an attacker-controlled HTTPS URL, which is accepted and rewritten with credentials before the attacker-controlled server receives them.The vulnerability is recorded in AgentXploit-Bench as a credential exposure instance.Source: §C.1.1 · p. 19

C.2.1. CODEX BEHAVIOR (TRACE-BASED)

• Codex detects the first-token validation weakness but reports a single attack scenario based on command chaining.Source: §C.2.1 · p. 20

C.2.2. ANALYZER AGENT BEHAVIOR

• The Analyzer Agent identifies distinct allowed-interpreter payload execution and nested denylist bypass paths because shell=True leaves additional command interpretation unchecked.The section records these as distinct AgentXploit-Bench instances.Source: §C.2.2 · p. 20