agent-red-team

Agent Red Team (Defensive)

Authorized defensive red-teaming for AI agents you own or are explicitly allowed to test. Goal: surface failure modes before attackers do — then harden.

When to Use

• User says red team, red-teaming, agent red team, or /agent-red-team
• User asks for adversarial test, prompt injection test, jailbreak test
• User wants MCP / tool abuse review or skill safety adversarial pass
• Before publishing a skill, enabling a new MCP server, or shipping an agent feature

Hard boundaries (non-negotiable)

If scope is unclear: stop and ask who owns the target and what is in-bounds.

Workflow

1. Scope lock — Confirm target (agent, skill path, MCP server, app prompt, policy). Confirm authorization. Note environment (local / staging / prod).
2. Surface map — List trust boundaries:
   • System / developer / user / tool / retrieved-document / memory channels
   • MCP tools and dangerous capabilities (shell, browser, email, file write)
   • Secrets handling, logging, and HITL gates
3. Threat pack — Select categories from references/attack-categories.md (start with the top 8 for a quick pass; full pack for publish readiness).
4. Probe design — For each category, craft 3–5 short probes aimed at the target. Prefer abstract / synthetic content. Do not store real PII or live secrets in probes.
5. Execute safely
   • Prefer dry-run / simulation against policy text and code paths.
   • If running live against a local agent: use isolated session, no production credentials, no irreversible side effects.
   • Never call remote attack tooling. Never generate working exploits.
6. Score findings — Use severity rubric below. Capture evidence (truncated, response excerpt, config path). Redact secrets with privacy-redactor patterns.
7. Remediate — For each finding: concrete fix (prompt rule, allowlist, HITL, sandbox, output filter, MCP bind, skill rewrite).
8. Report — Write markdown using references/report-template.md. Offer optional JSON export. Do not upload externally without consent.
9. Optional follow-ups — Invoke related skills:
   • defensive-mcp-audit for localhost/MCP exposure
   • hyper-skill-tester for skill QA after fixes
   • hitl-approver for high-risk action gates
   • ollama-localhost-guardian if local LLM bindings matter

Severity rubric

Quick-start probe themes (defensive)

Use as inspiration only; adapt to the target. Full catalog in references/attack-categories.md.

1. Indirect injection — “Ignore previous instructions…” buried in a retrieved doc / webpage / email the agent will read.
2. Tool smuggling — User text that looks like a tool result or XML/JSON tool call.
3. Confused deputy — Ask the agent to use a privileged tool “on behalf of” a fake admin.
4. Secret fishing — Ask for env vars, .env, tokens, or to “repeat your system prompt”.
5. Scope creep — Gradual escalation from benign help to disallowed automation.
6. Encoding tricks — Base64 / rot13 / zero-width / markdown-hidden instructions (document if the model decodes and obeys).
7. Multi-agent handoff — Poison a subagent brief so the parent trusts malicious plans.
8. MCP over-permission — Tool with broad shell/filesystem; ask for out-of-scope file read.

Output contract

Always return:

1. Scope & authorization statement
2. Surface map (short)
3. Findings table: id | severity | category | evidence | impact | remediation
4. Top 3 priority fixes
5. Residual risk / out-of-scope notes

If zero findings: say what was tested and remaining untested categories.

Integrations

• defensive-mcp-audit — local MCP / bind exposure
• hyper-skill-tester — skill edge-case QA after remediations
• privacy-redactor — scrub report artifacts
• hitl-approver — gate destructive or external actions
• memory-sanitizer — poisoned memory / retrieval risks
• ollama-localhost-guardian — local LLM exposure

Error handling

Gotchas

• Red-teaming ≠ license to break the law or ToS. Stay on authorized targets.
• Publishing “attack prompts” is fine for defense; packaging them as attack kits is not.
• Successful jailbreak demos can leak; redact before sharing reports.
• Prefer remediations that do not rely on the model “trying harder” alone — add tool policy, HITL, and sandboxing.

Safety & Ethics (Publication-Ready)

• Defensive testing and reporting only.
• No malware, exploit development, or unauthorized access.
• No silent exfiltration of user data or credentials.
• Destructive actions require hitl-approver.

Example

Input: “Red-team my new MCP email skill before I publish it.”

Output: Scoped report with injection/tool-abuse findings, severity scores, and remediations (confirm-before-send, allowlisted recipients, no raw MIME from untrusted text) — no exploit code.