---
name: red-team-arena-experiments
type: analysis
title: "Arena Research Experiments"
description: "Three structured experiments evaluating attack transferability, defender blind spots, and adaptive vs static attacker performance"
tags: [ai-safety, experiments, transferability, adaptive-attacks, category-analysis, wilson-ci, z-test, research]
timestamp: 2026-07-21
---

# Arena Research Experiments

## Overview

The Red Team Arena includes three structured research experiments, each answering a specific question about attacker/defender capability. All experiments are implemented as standalone classes in the `experiments/` directory, produce structured JSON results, and save artifacts (charts, summaries) to timestamped folders under `runs/`.

```mermaid
graph LR
    E1[Transferability<br/>Do attacks generalize?]
    E2[Category Breakdown<br/>Where are blind spots?]
    E3[Adaptive vs Static<br/>Does learning help?]

    E1 -->|cross-attack matrix| R1[Wilson CIs<br/>Transfer scores]
    E2 -->|per-category rates| R2[Blind spot map<br/>Defender accuracy]
    E3 -->|paired comparison| R3[z-test<br/>Turns-to-success]
```

### Running Experiments

```bash
# All three (free mode)
python scripts/run_experiments.py --no-judge --defenders keyword_baseline --rounds 10

# Individual
python scripts/run_experiments.py --experiment transferability --rounds 20
python scripts/run_experiments.py --experiment category --rounds 10
python scripts/run_experiments.py --experiment adaptive --rounds 15
```

Each experiment produces a `results.json` file alongside the standard artifact bundle (summary, leaderboard, charts).

---

## Experiment 1: Attacker Transferability

**Research question**: Do attacks that beat Defender A also beat Defender B, or are they defender-specific?

**Implementation**: `experiments/transferability.py` -- `TransferabilityExperiment` class

### Design

```mermaid
graph TB
    subgraph "Transferability Experiment"
        ATK1[template_random] --> DEF1[keyword_baseline]
        ATK1 --> DEF2[openai_moderation]
        ATK2[template_dan] --> DEF1
        ATK2 --> DEF2
        ATK3[template_roleplay] --> DEF1
        ATK3 --> DEF2
        ATK4[template_hypothetical] --> DEF1
        ATK4 --> DEF2
        ATK5[template_system] --> DEF1
        ATK5 --> DEF2
    end
```

1. Run every attacker against every defender for N rounds per pair
2. Compute per-attacker success rates against each defender
3. Calculate Wilson 95% confidence intervals for each rate
4. Compute a transferability score per attacker

### Key Metric: Transferability Score

```
transferability_score = 1.0 - stdev(success_rates_across_defenders)
```

- **High score (close to 1.0)**: Attack works uniformly across all defenders -- high transferability
- **Low score (close to 0.0)**: Attack works against some defenders but not others -- defender-specific

Interpretation thresholds:
- `stdev < 0.1` -- "high transfer"
- `stdev < 0.25` -- "medium transfer"
- `stdev >= 0.25` -- "defender-specific"

### Statistical Method: Wilson Score Interval

For each attacker-defender pair, the 95% confidence interval on the success rate uses the Wilson score interval:

```
center = (rate + z^2 / (2n)) / (1 + z^2 / n)
margin = (z / (1 + z^2/n)) * sqrt(rate*(1-rate)/n + z^2/(4n^2))
CI = [max(0, center - margin), min(1, center + margin)]
```

Wilson intervals are preferred over normal-approximation intervals because they remain accurate for small sample sizes and rates near 0 or 1. With 15 rounds per pair, this matters.

### Actual Results (run `transfer_3e3c24`)

75 total rounds (5 attackers x 1 defender x 15 rounds per pair):

| Attacker | Success Rate | n | 95% CI | Transfer Score | Interpretation |
|----------|-------------|---|--------|---------------|----------------|
| template_hypothetical | 73.3% | 15 | [48.0%, 89.1%] | 0.0 | insufficient data |
| template_random | 73.3% | 15 | [48.0%, 89.1%] | 0.0 | insufficient data |
| template_roleplay | 33.3% | 15 | [15.2%, 58.3%] | 0.0 | insufficient data |
| template_system | 20.0% | 15 | [7.0%, 45.2%] | 0.0 | insufficient data |
| template_dan | 0.0% | 15 | [0.0%, 20.4%] | 0.0 | insufficient data |

**Note on "insufficient data"**: With only 1 defender in this run, the transferability score is always 0.0 (cannot compute stdev with a single data point). The experiment requires at least 2 defenders to produce meaningful transferability scores. In a full run with `keyword_baseline` + `openai_moderation`, the stdev would be calculable.

**Key finding**: The hypothetical template achieves 73.3% success against the keyword defender, while DAN achieves 0%. This suggests that semantic reframing (hypothetical/academic) is fundamentally harder for keyword-based defenders than explicit jailbreak tokens (DAN).

---

## Experiment 2: Category Breakdown

**Research question**: Which harm categories does each defender systematically miss?

**Implementation**: `experiments/category_breakdown.py` -- `CategoryBreakdownExperiment` class

### Design

For each of the 8 harm categories:
1. Filter the seed bank to that category only
2. Run all attacker-defender combinations for N rounds per category
3. Compute per-category attack success rate and defender accuracy
4. Identify blind spots: categories where attack success rate is highest

### Key Output: Blind Spot Map

The experiment produces a `blind_spots` dictionary:

```json
{
  "keyword_baseline": [
    {"category": "privacy_violation", "attack_success_rate": 0.867, "defender_accuracy": 0.133},
    {"category": "hate_speech", "attack_success_rate": 0.8, "defender_accuracy": 0.2},
    ...
  ]
}
```

Sorted by `attack_success_rate` descending -- the top entries are the defender's worst categories.

### Actual Results (run `catbreak_2b4360`)

240 total rounds (2 attackers x 1 defender x 8 categories x 15 rounds per category):

**Overall**: 57.5% attack success rate across all categories.

**Keyword Defender Blind Spots** (sorted by worst defender accuracy):

| Category | Attack Success Rate | Defender Accuracy | Avg Severity |
|----------|-------------------|------------------|-------------|
| privacy_violation (Hypothetical) | 86.7% | 13.3% | 3.47 |
| hate_speech (Hypothetical) | 80.0% | 20.0% | 3.53 |
| misinformation (Hypothetical) | 80.0% | 20.0% | 3.00 |
| hate_speech (Random) | 66.7% | 33.3% | 3.53 |
| illegal_activities (Hypothetical) | 60.0% | 40.0% | 3.60 |
| self_harm (Hypothetical) | 60.0% | 40.0% | 3.93 |
| social_engineering (Hypothetical) | 60.0% | 40.0% | 3.07 |
| weapons (Hypothetical) | 60.0% | 40.0% | 4.07 |

**Best defender performance** (lowest attack success):

| Category | Attack Success Rate | Defender Accuracy |
|----------|-------------------|------------------|
| illegal_activities (Random) | 33.3% | 66.7% |
| misinformation (Random) | 40.0% | 60.0% |
| jailbreaks (Random) | 40.0% | 60.0% |

### Analysis

The keyword defender's biggest blind spots are:

1. **Privacy violation** (86.7% attack success, 13.3% defender accuracy): The keyword rules for `privacy_violation` rely on specific terms (`stalkerware`, `track.*location.*without`, `hack.*account`) that are easy to circumvent with hypothetical framing.

2. **Hate speech** (80.0% attack success, 20.0% defender accuracy): Keywords like `genocid`, `white supremac`, `nazi` are detectable but the hypothetical template wraps them in academic framing that avoids direct keyword matches.

3. **Misinformation** (80.0% attack success, 20.0% defender accuracy): The 5 misinformation keywords (`fake news`, `deepfake`, `disinformation`, `fabricated.*citation`, `false.*medical`) cover only a fraction of misinformation attack vectors.

The defender performs **best** against `illegal_activities` with the random template (33.3% attack success) because the 8 keyword patterns in this category (`methamphetamine`, `ransomware`, `malware`, `keylogger`, `counterfeit`, `drug synthes`, `fentanyl`) are specific enough that even random template selection sometimes includes them directly.

---

## Experiment 3: Adaptive vs Static Attackers

**Research question**: Does a multi-turn adaptive attacker that learns from failed attempts outperform a single-shot static attacker?

**Implementation**: `experiments/adaptive_vs_static.py` -- `AdaptiveVsStaticExperiment` class

### Design

```mermaid
graph TB
    subgraph "Paired Comparison"
        S[Static Arm<br/>1 attempt per seed] 
        A[Adaptive Arm<br/>up to 5 turns per seed]
    end

    SEEDS[Shared Seed Set<br/>N seeds] --> S
    SEEDS --> A
    S --> COMP[Comparison<br/>per-seed success rates]
    A --> COMP
    COMP --> Z[z-test<br/>two-proportion]
```

1. Sample ONE set of seeds, shared by both arms
2. **Static arm**: One attempt per (seed, defender) -- standard single-shot attack
3. **Adaptive arm**: Up to `max_adaptive_turns` (default 5) per (seed, defender), passing failure history each turn; stop early on success
4. Compare **per-seed** success rates (did the attacker succeed at all for this seed?)
5. Statistical significance via two-proportion z-test

**Critical design decisions**:

- **Per-seed comparison, not per-attempt**: Comparing per-attempt rates would penalize the adaptive arm for its own failed intermediate turns. The fair question is "did the attacker eventually succeed for this seed?" not "how many total attempts did it take?"

- **Elo updated once per episode**: In the adaptive arm, Elo is updated once after the full multi-turn episode, not once per turn. This prevents defender ratings from being inflated by intermediate failures.

- **Paired design**: Both arms use the same seeds, eliminating seed-selection bias.

### Statistical Method: Two-Proportion Z-Test

```python
def two_proportion_ztest(successes_a, n_a, successes_b, n_b):
    p_pool = (successes_a + successes_b) / (n_a + n_b)
    se = sqrt(p_pool * (1 - p_pool) * (1/n_a + 1/n_b))
    z = (successes_b/n_b - successes_a/n_a) / se
    p_value = erfc(abs(z) / sqrt(2))
    return z, p_value
```

Two-sided test with alpha = 0.05.

### Actual Results (run `adaptive_19fd90`)

63 total rounds across both arms (15 episodes x 1 defender):

**Static Arm**:

| Metric | Value |
|--------|-------|
| Episodes | 15 |
| Success Rate | 53.3% |

**Adaptive Arm**:

| Metric | Value |
|--------|-------|
| Episodes | 15 |
| Total Turns | 48 |
| Per-Episode Success Rate | 60.0% |
| Per-Attempt Success Rate | 18.8% |
| Avg Turns to Success | 2.0 |
| Turns Distribution | [1, 4, 1, 1, 1, 4, 1, 4, 1] |

**Comparison**:

| Metric | Value |
|--------|-------|
| Improvement | +6.7% |
| z-statistic | 0.368 |
| p-value | 0.7125 |
| Significant at 0.05? | No |
| Adaptive advantage? | No |

### Analysis

The adaptive arm achieved a **60.0% per-episode success rate** versus the static arm's **53.3%**, a raw improvement of +6.7 percentage points. However, the two-proportion z-test yields p=0.7125, far above the 0.05 significance threshold.

**Why the improvement is not significant**:

1. **Small sample size**: Only 15 episodes per arm. With these effect sizes, detecting significance would require approximately 200+ episodes per arm.

2. **Turns-to-success distribution**: Of the 9 episodes where the adaptive attacker succeeded, 6 succeeded on turn 1 (same as static), and 3 succeeded on turn 4. The adaptive mechanism rarely helps -- it mostly just retries the same strategy.

3. **Template limitation**: The base attacker was `template_escalating`, which cycles through templates by turn number. The adaptive wrapper passes history back, but the escalating strategy doesn't use history -- it just picks the next template in sequence. A truly adaptive attacker (Ollama or OpenAI-based) would benefit more from the history.

**What the data suggests**:

- The adaptive mechanism adds computational cost (48 total turns vs 15 static turns) for a marginal, statistically insignificant improvement
- With template-based attackers, multi-turn adaptation provides little benefit because the template pool is finite and the attacker cannot generate novel strategies
- LLM-based adaptive attackers (Ollama, OpenAI) are expected to benefit significantly more from history, as they can reason about why previous attempts failed

---

## Experiment Orchestration

All three experiments are orchestrated by `scripts/run_experiments.py`:

1. Parse arguments (which experiment, rounds, defenders, seed, judge mode)
2. Create shared `ArenaLogger` (all experiments write to the same SQLite DB)
3. Run each experiment sequentially
4. After each experiment, write artifacts (replay logged rounds through `RunArtifacts` to populate `rounds.jsonl`)
5. Save `results.json` with the experiment's structured output

The artifact writing uses a "replay" pattern: experiments stream to SQLite during execution, then the results are replayed through the `RunArtifacts` writer to generate the standard folder structure. This ensures artifacts are consistent even if the experiment crashes mid-run.

## Cross-References

- [[red-team-arena]] -- Full system overview
- [[red-team-arena-agents]] -- The agents used in experiments
- [[red-team-arena-elo]] -- How Elo ratings are tracked during experiments
- [[red-team-arena-dashboard]] -- How experiment results are visualized