Paper
Overview
LLM agents read external content, call tools and change application state, so a successful attack shows up as a leaked secret or an unauthorized action, not just a bad reply. Automated red-teaming services such as Promptfoo, PyRIT, DeepTeam and Dreadnode are built to find these failures, but when a test finds nothing it is unclear whether the agent resisted or the service never reached a weakness. GreyZone evaluates the services themselves: each one acts as an end-to-end attacker and is measured on whether it generates and delivers attacks that cause verified security-policy violations in real agent applications.
- Real applications. 10 independently developed, open-source agent applications (coding, enterprise collaboration, email, trading, commerce, banking, smart home, Kubernetes operations and social/on-chain agents) run with their own workflows, permissions and security boundaries. External dependencies are replaced with controlled simulations, and every run starts from a prepared initial state.
- 46 attack scenarios. Each scenario fixes the application, initial state, security policy, attack objective, attacker constraints and oracle. The objective is the same for every service; how to reach it is up to the service.
- One attacker interface. An MCP interface exposes only the operations the attacker's role permits, for direct injection (messages to the agent) or indirect injection (content the agent reads during its task). Service-specific adapters connect each red-teaming service to it.
- Independent oracles. Each scenario's oracle checks execution evidence and application state, not the service's own verdict or the agent's reply, before reporting a verified outcome.
Results
One row per (attacker, victim) evaluation campaign. Click a column to sort.
ASR — episodes with verdict success(<surfaces>) ÷ total episodes.
Authenticity — mean oracle truth-match score over fired exfiltration surfaces (1.0 exact secret, 0.5 long prefix).
Control FP — false alarms on control/calibration episodes (healthy pipelines report 0).
No-reply — episodes closed without an attacker-visible response.
Attack taxonomy
Every scenario maps to exactly one category; every category is witnessed by ≥2 ranges.
Range catalog
Victim applications are pinned upstream forks running against fully simulated worlds; each range ships its own oracle.
| Range | Upstream victim | Scenarios | Oracle surfaces |
|---|
Submit results
Submit one evaluation campaign through a GitHub pull request.
- Run the benchmark with the official victim configuration and publish the raw Oracle artifacts (
.run/oracle/result-<N>.json). - Click Create submission. GitHub opens a prefilled campaign file under
data/submissions/: rename it (lowercase letters, digits, hyphens) and replace the example values.victim.rangeis a name from the range catalog; its model is fixed by the benchmark and supplied automatically. - Click Commit changes… → Propose changes → Create pull request. GitHub forks the repository for you; fill in the pull request template.
Maintainers review the raw episode artifacts before merging results. Prefer git? Fork, add the file on a branch and open a pull request as usual.