// security workers
Red Team
Scanners tell you about known CVEs. Red Team shows how an attacker could break what you built. Superagent runs adversarial campaigns against your real surface: black-box against public applications and installable packages, gray-box with repository context. Every finding ships with repro steps and the payload that worked, ranked by severity against your architecture rather than a generic checklist.
All reports live under Red team in the dashboard, in one list across every target type.
Pick a target
| Target | What it tests | Access needed |
|---|---|---|
| Repository | A GitHub codebase, scanned for vulnerabilities, unsafe patterns, and config issues | Superagent Security installed on the repo |
| Application | A live application, probed by browser-driven DAST | A public HTTP or HTTPS URL |
| Agent | A deployed AI agent tested for jailbreaks, policy gaps, and unsafe behavior | A description of the agent under test |
| Package | Installable software or a CLI, installed in a sandbox and adversarially tested | Installation instructions |
Start a Red Team run
Start from Red team → New report (/app/reports/new), pick a target type,
and fill in the details. The Red Team run proceeds asynchronously in an
isolated sandbox. Its red-team report stores status, evidence, findings, and
the final result.
You can also start repository, application, Agent, and Package runs from the Reports API or the MCP server. Both consume organization credits.
Follow the run
Red Team runs execute asynchronously in an isolated sandbox. Starting one returns immediately, and its red-team report detail page shows progress and results.
Three status fields tell you where a run stands:
| Field | Values |
|---|---|
| Report status | In progress, In review, Done, Failed |
| Sandbox status | Pending, Provisioning, Ready, Failed |
| Agent status | Pending, Installing, Running, Completed, Needs Review, Failed |
A healthy run moves from provisioning to running to In review, where results wait for your decision. Failures in provisioning or execution land on Failed with safe error context.
Repository runs can also trigger automatically on a GitHub release, a tag, or a schedule instead of manual creation.
Reviewing results
| Signal | Where to look |
|---|---|
| Overall status | Report detail header and the Red team list |
| Agent activity | The live event feed on the detail page |
| Findings | The report's findings section and the org-wide Findings queue |
| Evidence | Recordings and screenshots on application reports |
Application reports also show the browser session live while the agent works, and a recording afterwards. See Applications.
Rerun or automate
Application runs can be started again from the detail page. To wire the lifecycle into your own systems, subscribe to report.started and report.finished webhooks. report.finished fires once per report, with the outcome and a link back to the dashboard.
When a report fails
- Confirm the GitHub App still has access to the repository.
- Verify the repository exists and is selected in the app installation.
- For application reports, check that the target URL is public and your WAF allows the scanner.
- For agent reports, check that the description and type match the target you intend to test.
- See Troubleshooting.
From report to fix
Findings from repository and application reports land in the Findings queue with repro context. Automated triage verifies them, and confirmed findings can become fix PRs without leaving the queue.