ai-red-team

name	ai-red-team
description	Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.

ai-red-team

The AI-susceptibility producer of the security-testing pack (D5, opt-in). It probes your own authorized AI application or model for weaknesses — prompt injection, jailbreak, data exfiltration, tool/function abuse — and writes a REDTEAM-FINDINGS.md: each susceptibility reproduced against the system and paired with a concrete hardening. The output is a hardening report over an asset you own, never a reusable jailbreak/bypass artifact. Authorization plus ownership is the blocking precondition — no owned scope, no red-team.

Findings verify by Audit (is each susceptibility real, reproduced, and paired with a hardening?). A pre-execution test plan degrades to Review; the verifier never fabricates a "resistant / clean" for a probe that did not run.

What this does / does not do

Does: confirm authorization + ownership first (blocking); scope the owned AI target + the attack classes + the success criteria; probe within scope; reproduce each susceptibility; pair each with a hardening (input/output filter, tool-permission tightening, system-prompt change, guardrail); write REDTEAM-FINDINGS.md; write a receipt. Does not: probe a model it does not own or is not authorized for, report an unreproduced susceptibility as real, emit a reusable jailbreak/injection payload or a bypass library, exfiltrate real data, or claim resistance for an unrun probe.

When NOT to use

• No confirmed authorization + ownership of the AI system — that is blocking; stop and get it, do not probe.
• The request is static code analysis — that is sast-scan; or testing a conventional app surface — that is product-pentest. This sub_target probes an AI system's behavior.
• The ask is a portable jailbreak, a refusal-suppression library, or a reusable injection payload — refuse; the ai + security gates reject it regardless of framing. The output is hardening, not a weapon.
• The work is auditing controls/design rather than probing behavior — that is security-review.

Reference Routing

Situation	Reference
Thin inputs / no target / jailbreak-library ask	rules/cold-start.md
Per-sub_target must-declares · overlay · vocabulary	../acceptance/sub-targets.md · ../acceptance/overlay.md · ../vocabulary.md
Sibling sub_targets (owned source / running app)	sast-scan · product-pentest

Inputs

• The owned AI app/model + the authorization/ownership evidence (system, boundary, sign-off).
• The attack classes in scope (injection, jailbreak, exfil, tool-abuse) + the success criteria for each.
• The security-testing pack (../vocabulary.md, ../acceptance/) + state/intake.json.

How to do it

1. Authorization + ownership (blocking). Confirm the requester owns/controls the AI system and has authorized the red-team — system, boundary, sign-off, evidence. Without it, stop and record the gap; no owned scope, no probe.
2. Scope the target + classes + success criteria. Which AI app/model, which attack classes (injection, jailbreak, exfil, tool-abuse), and what counts as a successful probe for each. State what is out of scope.
3. Probe within scope. Exercise each attack class against the owned system. Use synthetic/marked data for exfil tests — never real user data or live secrets.
4. Reproduce each susceptibility. A one-off is a candidate; reproduce it before it is a finding. An unreproduced probe is a hypothesis, recorded separately, not a susceptibility.
5. Pair each with a hardening. Every susceptibility gets a concrete defense — input/output filter, tool permission tightening, a system-prompt or guardrail change — and a remediation owner. Defense ends at the hardening, not the discovery.
6. Keep the output defensive. The report describes susceptibility + hardening; it does not ship a working, reusable jailbreak/injection payload. Redact any sensitive probe artifact.
7. Write REDTEAM-FINDINGS.md — reproduced susceptibilities + hardenings + coverage vs the planned classes.

Gate (before marking complete)

• Authorization + ownership confirmed and recorded (blocking) — no owned scope, no red-team.
• Target + attack classes + success criteria scoped; exfil tests used synthetic/marked data only.
• Every reported susceptibility was reproduced; unreproduced probes listed as hypotheses.
• Each susceptibility is paired with a concrete hardening + a remediation owner.
• No real data exfiltrated; sensitive probe artifacts redacted (security gate).
• The output is a hardening report — no reusable jailbreak/injection/bypass artifact (ai gate); an unrun probe is recorded as deferred, never as "resistant".

A gate failure is fixed before lock, not waived — these mirror the authorization/ai/security gates.

Output

• REDTEAM-FINDINGS.md at the product root (or security-test/REDTEAM-FINDINGS.md if that dir exists) — persistence: Spec-Anchored. Authorized target + classes + success criteria · susceptibilities (reproduced) paired with hardenings + owner · coverage · unreproduced hypotheses (separate).
• receipt (<workspace>/receipts/ai-red-team-receipt-<ts>.json): base schema + sub_target, authorization_confirmed, target, attack_classes, susceptibilities_count, hardenings_count, run_status, findings_path, gate_checks. persistence: Spec-Anchored.

Completion Criteria

Done when: authorization + ownership were confirmed (blocking), the owned AI system was probed across the scoped classes (or the absence recorded as deferred), every reported susceptibility was reproduced and paired with a hardening + owner, no real data was exfiltrated, and a receipt records the gate checks — the deliverable is a hardening report.

Not done if: any probe ran without confirmed authorization/ownership; an unreproduced probe is reported as a susceptibility; a susceptibility lacks a hardening; a reusable jailbreak/injection artifact was produced; real data was exfiltrated; or an unrun probe is reported as "resistant".

Next step: remediation owners apply the hardenings; a re-probe confirms the susceptibility is closed. sast-scan covers owned source; product-pentest covers a conventional app surface.

Related Skills

• sast-scan / product-pentest: sibling security-testing sub_targets — static over owned source / a running app's surface. ai-red-team probes an AI system's behavior.
• security-review: audits controls + design, including AI controls. ai-red-team actively probes behavior; the review reasons about the guardrails around it.
• verifier: Audits the susceptibilities (real / reproduced / hardened) and honors a deferred probe — it never fabricates a resistant result for an unrun red-team.