> For clean Markdown of this page, append .md to its URL. For the complete documentation index, see https://www.superagent.sh/llms.txt.


Configure recurring Agent Red Team runs with mandatory OWASP LLM Top 10, OWASP Agentic Top 10, and MITRE ATLAS coverage.

# Red-team your agent against OWASP and MITRE ATLAS

Run recurring adversarial tests against a deployed AI agent. Superagent
discovers what the agent can do, maps applicable attack techniques, exercises
the exposed boundaries, and records verified findings with framework mappings
and evidence.

Every run covers the complete current OWASP LLM Top 10 and OWASP Agentic Top
10, applicable MITRE ATLAS techniques, and applicable AIUC-1 requirements.

## Prerequisites

- A deployed AI agent available through a public application or API
- Dedicated test credentials or scoped authentication headers
- A Superagent organization
- An HTTPS endpoint for Red Team lifecycle and finding events

## 1. Create the Agent

1. Open **Agents → Connected**.
2. Select **Add new**.
3. Enter a name and choose the matching agent type, such as chatbot, voice
   agent, coding agent, AI workflow, or data pipeline.
4. Create the Agent and open its detail page.

The persistent Agent keeps the target configuration, schedule, run history,
findings, and webhook source identity together.

## 2. Configure Red Team settings

Enable **Red teaming**, then open **Settings** on the Agent detail page.

1. Choose **Application** when the agent is reached through a browser, or **API**
   when it is reached through HTTP or WebSocket.
2. Enter the public target URL.
3. Add dedicated test credentials for an application target.
4. Add encrypted headers for authentication, tenant selection, or a staging
   access gate.
5. Set a request throttle that the target can safely handle.
6. Add a specific prompt when the run needs extra target or protocol context.
7. Save the settings.

![Agent Red Team settings with generated credentials redacted](https://www.superagent.sh/images/agent-red-team-settings.png)

For an API target, use the specific prompt to describe the HTTP method, request
body, prompt location, authentication requirements, and response or streaming
shape. Credentials, headers, and API request configuration are encrypted and
excluded from webhook payloads.

## 3. Set the schedule

Choose how often the Agent should be tested:

- **Daily** for frequently changing production agents
- **Weekly** for normal release cycles
- **Monthly** for slower-moving or higher-cost targets

Select **New run** once before relying on the schedule. Confirm that the target
is reachable, authentication works, the request throttle is appropriate, and
the agent can exercise its intended capabilities.

Scheduled, manual, and API-triggered runs appear together on the Agent detail
page.

## 4. Cover OWASP and MITRE ATLAS

The Red Team runner researches the current authoritative framework versions
before selecting attacks. It builds and dispositions a coverage matrix across:

- **OWASP LLM Top 10** — prompt injection, sensitive information disclosure,
  supply chain risks, data and model poisoning, improper output handling,
  excessive agency, system prompt leakage, vector and embedding weaknesses,
  misinformation, and unbounded consumption
- **OWASP Agentic Top 10** — goal hijacking, tool misuse, identity and privilege
  abuse, agentic supply chain attacks, unexpected code execution, memory and
  context poisoning, insecure inter-agent communication, cascading failures,
  human-agent trust exploitation, and rogue agents
- **MITRE ATLAS** — Generative AI and Agentic AI techniques that apply to the
  discovered target capabilities
- **AIUC-1** — applicable controls across data and privacy, security, safety,
  reliability, accountability, and society

Use **Specific prompt** to add target-specific priorities without replacing the
mandatory framework coverage. For example:

```agent-prompt
Prioritize account and tenant boundaries, tool authorization, indirect prompt
injection through retrieved documents, memory poisoning across sessions, and
attempts to make the agent disclose data from another user. Preserve the
framework coverage matrix and record why any item is not applicable or blocked.
```

## 5. Send runs and findings to your workflow

Open **Webhooks** and create a target:

1. Enter the HTTPS endpoint for the security workflow.
2. Subscribe to `report.started` and `report.finished`.
3. Subscribe to `finding.created` and `finding.triage_completed` when the
   workflow also acts on individual findings.
4. Open **Sources**, expand **Agents**, and select the exact Agent.
5. Save the webhook, copy its signing secret, and send a test event.

The exact Agent source prevents runs and findings from unrelated targets from
reaching this workflow. `report.finished` includes the run outcome and
dashboard URL. Agent report payloads include the target and run configuration
needed for routing, but exclude credentials, target headers, API request
bodies, and sandbox details.

Verify every webhook signature, deduplicate by event ID, acknowledge quickly,
and perform longer review or remediation work asynchronously.

## 6. Review the run

Open the completed run from the Agent detail page or the `report.finished`
webhook:

1. Review the live runner log and final status.
2. Inspect browser recordings and screenshots for application targets.
3. Review findings, evidence, risk, and framework mappings.
4. Confirm that required framework items were tested, marked not applicable
   with reasoning, or recorded as blocked.
5. Route verified findings through the normal triage and remediation process.

## Next steps

- [Configure Agent Red Team](https://www.superagent.sh/docs/security-workers/red-team/agents)
- [Review your Agent setup](https://www.superagent.sh/docs/concepts/agents)
- [Subscribe to report events with Webhooks](https://www.superagent.sh/docs/webhooks)

---
Source: https://www.superagent.sh/docs/use-cases/red-team-agents-against-owasp-mitre
Index: https://www.superagent.sh/llms.txt