superagent_

// use cases

Red-team your agent against OWASP and MITRE ATLAS

[ view markdown ]

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

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

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:

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