RedTeam
RedTeam is a separate application in this repository (redteam/). It has
its own UI, its own API, and its own database. It does not share Cortega
Core sessions or routes, and it is not part of the Core release package.
Install and deploy it on its own. See deploy/redteam/.
The console pages LLM RedTeam and MCP RedTeam are AI Bench inside Core. Those pages send sample suites through your own gateway. This application is the other one. It assesses an AI system Cortega does not operate: a model endpoint, a chatbot, an MCP server, or an agent.
What you work with
| Screen | What it holds |
|---|---|
| Overview | The workspace summary |
| Targets | The systems under assessment, each with its own connection, identity, and history |
| Assessments | Plans: objective, attacker capabilities, turn budget, attempt budget |
| Attack campaigns | A run against one target, with per-turn evidence |
| Findings | Review of results. Automatic finding creation is not in this build, so the page stays empty until a reviewer records one |
| Attack library | Scenario packs, including drafting a scenario from a plain-language description |
| Reports | Compare two runs |
| Driving models | The attacker, judge, and sandbox models that drive a campaign |
| Users & access | Sign-in, roles, and SSO for the security team |
| Audit log | Administrative changes |
Saving a target does not send traffic to it. Saving an assessment does not start an attack.
Targets
A target is one of:
- an external model endpoint (OpenAI-compatible Chat Completions URL, model id, and its own credential)
- a chatbot or agent
- an MCP endpoint
- a sandbox model
Each target keeps its own identity, credentials, campaign history, and evidence. Target credentials are stored encrypted and are not returned by the API. Target sign-in is separate from the operator's RedTeam sign-in. A target can be anonymous, use a bearer token, reuse a session cookie, or log in with a same-origin JSON username and password. Each attempt logs in on its own.
External targets are allowed only when their origin is listed in
REDTEAM_ALLOWED_TARGET_ORIGINS.
Driving models
A campaign uses three model roles. Each role is an OpenAI-compatible base URL, an API key, and a model id.
| Role | What it does |
|---|---|
| Attacker | Writes each attack message and adapts to the reply |
| Judge | Scores language-only outcomes. A judge result is a candidate, not a confirmed action |
| Sandbox | Plays the application in the built-in sandbox scenarios |
One endpoint and one model can drive every role
(REDTEAM_MODEL_BASE_URL, REDTEAM_MODEL_API_KEY, REDTEAM_MODEL). A
role can override those with REDTEAM_ATTACKER_*, REDTEAM_JUDGE_*, or
REDTEAM_SANDBOX_*.
The request is a normal Chat Completions call. The model field is the
only field the router can key off. When the base URL is AI Border Gateway,
set model to the tag that gateway team is configured to route, and set
the key to a gateway key for that team. Provider choice, failover, and
guardrails then run in AI Border Gateway. The models under test are
separate target records. They do not use the driving-model keys.
Scenarios
Scenario packs live in redteam/scenarios/. A scenario names one
strategy: crescendo, pair, many-shot, single-shot, scripted-dialogue,
memory-injection, mcp-probe, or tool-abuse. The Attack library can draft
a pack from a description. You review it and approve or reject it before
it can run.
A run records the scenario version and hash, the strategy, and the engine version. Replay resends a recorded crescendo or pair attempt against another target, with no new attacker-model call, so you can check whether a fix held.
Evidence
A model-judged success is a candidate. A pre-seeded canary marker in a target reply can confirm disclosure. A sandbox violation means a simulated action crossed the configured boundary. MCP probes make one read-only tool call. HTTP 401 or 403 is an observed denial. Errors, cancellation, and an inconclusive judge are not counted as a defense.
Access
One organization per deployment. Roles are Admin, Operator, Reviewer, and Viewer, enforced on the server. SSO is generic OIDC. Roles are assigned in RedTeam. They are not taken from identity-provider claims.
Password sign-in is also available. The first administrator is created at startup when none is configured.