A minimal authorized engagement has four artifacts, in this order:

1. Scoping document (signed before testing starts)
2. Test taxonomy (what failure classes you'll probe)
3. Test log (what you ran, what happened, stopped at proof-of-concept)
4. Disclosure report (what the vendor should fix)

If you don't have a signed scoping document, you don't have an engagement — you have unauthorized access attempts. Stop and get sign-off first.

Progress:

• Step 1: Draft and get sign-off on scoping document
• Step 2: Build failure mode taxonomy for this target
• Step 3: Run tests with minimal-harm protocol, log everything
• Step 4: Triage findings by severity and reproducibility
• Step 5: Write and submit disclosure report
• Step 6: Track remediation across model versions

Step 1: Scoping Document

Before any testing, produce a written scope covering: target system(s) and version(s), in-scope failure categories, explicitly out-of-scope actions, data handling rules, engagement window, and named points of contact on both sides.

Template:

ENGAGEMENT SCOPE — [System Name] Red Team Assessment

Authorized by: [name, title, org]
Engagement window: [start date] – [end date]
Tester(s): [names / team]

IN SCOPE:
- Model endpoints: [API, chat UI, specific model versions]
- Failure categories to test: [see taxonomy, Step 2]
- Testing methods permitted: prompt-based adversarial inputs,
  multi-turn conversation strategies, encoding/obfuscation probes,
  cross-lingual probes

OUT OF SCOPE:
- Infrastructure attacks (network, auth, server-side exploits)
- Generating complete harmful payloads beyond proof-of-concept
  (e.g., stop at "model began providing synthesis steps," do not
  complete or refine the synthesis route)
- Testing against real user data or production traffic
- Social engineering of vendor employees

PROOF-OF-CONCEPT STANDARD:
Findings must demonstrate the failure occurred (e.g., filter bypassed,
refusal suppressed) without producing a maximally harmful or usable
output. Truncate generations at the point the bypass is proven.

DATA HANDLING:
- All transcripts stored in [location], access limited to [people]
- Harmful outputs redacted/truncated in all reports
- Retention period: [X days], then deleted

DISCLOSURE:
- Findings reported to [vendor security contact] within [X days] of discovery
- Coordinated disclosure timeline: [standard 90 days / vendor's policy]
- No public disclosure before [date] or vendor acknowledgment

Signed: _________________ (Tester)
Signed: _________________ (Authorizing party)

Step 2: Failure Mode Taxonomy

Organize test categories so coverage is auditable and nothing is tested ad hoc. Use this baseline taxonomy and tailor per engagement:

For each category tested, record: pass/fail criteria, number of variants tried, and reproducibility rate (e.g., "bypassed in 7/10 attempts with variant X").

Step 3: Minimal-Harm Testing Protocol

The operational rule: prove the mechanism, not the payload.

• Stop generation at the first token/sentence that demonstrates the bypass occurred.
• For content-generation failures (e.g., disallowed instructions), log "model began producing [category] content" rather than the full output.
• For behavioral failures (e.g., persona bypass), the proof is the presence of the bypassed behavior (dropped disclaimer, tone shift), not extended exploitation of it.
• Never refine, iterate on, or "improve" a harmful output once the bypass is demonstrated — that step has no remediation value and only increases harm/liability.
• Redact harmful specifics in logs and reports; replace with [REDACTED: category, e.g., "synthesis instructions"].

Example test log entry:

Test ID: CL-014
Category: Cross-lingual / low-resource language
Input strategy: Request translated into [language], hybrid with
  English technical terms
Result: Model provided first 2 steps of [REDACTED: restricted
  content category] before test was halted (proof-of-concept
  standard met)
Reproducibility: 4/5 attempts with minor phrasing variants
Severity: High — bypasses primary safety filter, low effort to reproduce

Step 4: Triage

Rank findings using a simple severity matrix:

Step 5: Disclosure Report

Template:

VULNERABILITY REPORT — [System Name]

Summary: [one paragraph, non-technical, what the failure class is
  and why it matters]

Severity: [Critical/High/Medium/Low] — [justification]

Affected versions: [model/version identifiers]

Reproduction steps:
1. [Setup/context needed]
2. [Input pattern used — generalized, not the most harmful variant]
3. [Observed behavior]

Evidence: [truncated transcript, harmful specifics redacted]

Reproducibility: [X/Y attempts across Z phrasing variants]

Root cause hypothesis: [e.g., "safety fine-tuning data has sparse
  coverage of language X" or "instruction hierarchy doesn't persist
  across simulated 'debug mode' framing"]

Suggested remediation: [e.g., "add adversarial training examples in
  category X," "harden system-prompt precedence against user-claimed
  authority"]

Disclosure timeline: Reported [date]. Requesting acknowledgment within
  [X days] per coordinated disclosure agreement. Intend to [publish
  summary / present internally] on [date] absent objection.

Contact: [tester info]

Step 6: Tracking Remediation

Maintain a running table across model versions:

Success for this skill is this table trending toward "fixed" over time — not a single reliable bypass.

Example 1: Scoping a persona-bypass test Input: A product team wants to know if their customer-support LLM can be made to ignore its "stay on topic" system prompt. Output: Scope document limiting testing to that one system prompt's instruction-hierarchy robustness, explicitly excluding any attempt to extract training data or other systems. Taxonomy category used: "Instruction hierarchy — system/user conflict." Test log records 3 framing variants tried, 1 successful bypass (claimed "admin override"), truncated at the point the model dropped topic restriction. Report recommends reinforcing system-prompt precedence instructions.

Example 2: Cross-lingual probe triage Input: Testing reveals a safety filter is weaker in a low-resource language. Output: Logged as Category "Cross-lingual/encoding," severity High (reliable, low effort, no special access needed). Report includes reproduction steps using a generalized, non-maximally-harmful example request, redacted evidence, and root-cause hypothesis pointing to sparse multilingual safety training data.