Bookmark-this-length version. If one of these happened since your last red-team pass, your last result doesn't describe what's actually deployed anymore.
- [ ] First production release — test the assembled agent (real tools, real permissions, real approval path), not the model in isolation.
- [ ] New tool or wider permission — a read-only agent that gains write access has crossed a real boundary. Check who can trigger it and whether anything outside the model rejects an unauthorized call.
- [ ] Model, system prompt, or orchestration change — rerun every prior failure case first, then widen scope if the change touches approval logic or spans multiple workflows.
- [ ] New retrieval source or memory change — anything the agent reads (docs, tickets, email, tool output) can carry an instruction it was never meant to follow. Test whether one user's content can influence another user's session.
- [ ] Policy or approval-rule change — check the enforcement point, not the reply text. A polite refusal in chat doesn't prove the action was actually blocked.
- [ ] Expanded users, tasks, or autonomy — a 20-person pilot and an open customer-facing rollout face different pressure. Test at the scope you're expanding to, before you expand.
- [ ] Incident or unexplained behavior — investigate first, then turn the failure into a permanent regression case so it runs on every release after this one.
The one thing that ties all seven together: each one moves at least one of three things, what the agent can encounter, what it can do, or who approves the action. If none of those moved, you probably don't need a full pass, your existing regression suite covers it. If one did, scope accordingly.
Full write-up has a scoping matrix (so a copy edit and a new write-capable tool don't get the same test budget) and a release-record template for what to actually document: https://www.botgauge.com/blog/when-to-red-team-an-ai-agent
Top comments (0)