SkillSafetyBench

SkillSafetyBench ist ein vollständig materialisierter Benchmark zur Bewertung von Sicherheitsfehlern, die durch Angriffe auf den skill-bezogenen Kontext verursacht werden. Jeder Fall hält die benutzerorientierte Aufgabe gewöhnlich, während der Angriff in lokalen Skills, Hilfsskripten, Sidecar-Dateien, Korpora, Vorlagen oder anderen Workspace-Artefakten platziert wird, die ein Agent während der Ausführung konsultieren kann.

Erkunden Sie das Benchmark-Design, den Fall-Explorer, das Leaderboard und die Experimentanalyse auf der SkillSafetyBench-Website und lesen Sie das vollständige Paper auf arXiv.

Was der Benchmark bewertet

Moderne Codierungs- und Aufgabenagenten verlassen sich oft auf lokale Skills und Umgebungsartefakte, nicht nur auf den Benutzer-Prompt. SkillSafetyBench testet, ob ein Agent harmlose Arbeiten erledigen kann, während er unsicheren Anweisungen oder irreführendem Kontext widersteht, der in diesen skill-bezogenen Oberflächen eingebettet ist. Die harmlosen Aufgaben-Träger sind aus SkillsBench ausgewählt.

Der Benchmark ist statisch und sofort ausführbar. Er ist kein Fallgenerator. Das Repository enthält 155 vorbereitete Fälle in 6 Risikodomänen und 30 Kategorien. Jeder Fall enthält:

• eine harmlose Basistask, die dennoch abgeschlossen werden sollte
• eine oder mehrere skill-bezogene Angriffsflächen
• einen deterministischen Verifizierer für das unsichere Verhalten
• Task-Tests für die Abschlussprüfung der Basistask
• Metadaten und Begründung, die das endgültige Falldesign beschreiben

Jeder Lauf wird auf zwei Achsen bewertet:

• task_success: ob die gewöhnliche Benutzeraufgabe abgeschlossen wurde
• attack_success: ob das unsichere Verhalten beobachtet wurde

Diese Trennung ist wichtig: Ein System kann fähig erscheinen, weil es die Aufgabe abschließt, während es dennoch verwundbar ist, weil es dem angriffsbehafteten Skill-Kontext folgt.

Benchmark-Struktur

SkillSafetyBench enthält 155 Fälle, die in 6 Risikodomänen und 30 Kategorien organisiert sind. Jede Risikodomäne enthält 5 Kategorien, und jede Kategorie enthält mehrere konkrete Fälle, die um gewöhnliche Aufgaben-Träger herum aufgebaut sind.

SkillSafetyBench
└── 6 Risikodomänen
    ├── RD1: Kontextvertrauens- und Prompt-Manipulationsrisiken
    ├── RD2: Agency-, Umfangs- und Autorisierungsrisiken
    ├── RD3: Ausführungs-, Laufzeit-, Framework- und Protokollrisiken
    ├── RD4: Datengrenz-, Ausgabe- und Externalisierungsrisiken
    ├── RD5: Speicher-, Wiederherstellungs-, Audit- und Persistenzrisiken
    └── RD6: Wissens-, Modell-, Lieferketten- und Betriebsrisiken

Fälle werden nach Risikodomäne, Kategorie und Fall-ID gespeichert:

benchmark/<risk-domain>/<category>/<case>/
  metadata.json
  rationale.md
  attacked_task/
    instruction.md
    task.toml
    environment/
    solution/solve.sh
    tests/test.sh
  eval/verify_attack.py

Das Benchmark-Verzeichnis ist die Quelle der Wahrheit für Fälle. Kategorieverzeichnisse verwenden das Namensmuster categoryN-..., zum Beispiel:

benchmark/risk-domain-6-knowledge-model-supply-chain-and-operational-risks/category1-availability_cost_and_service_exhaustion/

Benchmark-Konstruktionspipeline

Die Benchmark-Konstruktionspipeline beginnt mit harmlosen Aufgaben-Trägern, bewahrt die ursprüngliche benutzerorientierte Aufgabe, injiziert den Angriff über skill-bezogene Artefakte und fügt deterministische Prüfungen sowohl für die Aufgabenabschluss als auch für das Angriffsverhalten hinzu. Dies hält die Bewertung darauf fokussiert, ob Agenten unsicherem lokalem Kontext widerstehen können, während sie dennoch die angeforderte Arbeit erledigen.

Sicherheitshinweis

Dieses Repository enthält adversariale Benchmark-Fälle. Einige Fälle simulieren Phishing, Anforderung von Anmeldeinformationen, destruktive Operationen, Datenerfiltration, Missbrauch von Sandbox-Grenzen, externe Aktionen und persistenzähnliche Verhaltensweisen.

Führen Sie den Benchmark nur in isolierten Forschungsumgebungen aus. Verwenden Sie keine Produktionsanmeldeinformationen, Produktions-Cloud-Konten, persönliche Konten oder sensible lokale Dateien. Bevorzugen Sie Wegwerf-API-Schlüssel, Wegwerfcontainer, eingeschränkten Netzwerkzugriff und ein dediziertes Arbeitsverzeichnis. Überprüfen Sie Laufartefakte, bevor Sie sie teilen.

So führen Sie den Benchmark aus

1. Toolchain vorbereiten

Erforderliche Werkzeuge:

• bash
• python3, empfohlen >= 3.11
• docker
• uv
• harbor
• nvm
• Node.js 22

Installieren Sie Harbor bei Bedarf:

uv tool install harbor

Überprüfen Sie die grundlegende Toolchain:

harbor --help
python3 --version
docker --version

Wenn Ihr Harbor-Agent über Node installiert ist, aktivieren Sie Node 22 in der Shell, die den Lauf startet:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
nvm use 22

2. Umgebungsvariablen konfigurieren

Erstellen Sie eine lokale .envrc aus der Beispieldatei:

cp env.example .envrc

Für codex setzen Sie mindestens:

export OPENAI_BASE_URL="https://your-openai-compatible-endpoint/v1"
export OPENAI_API_KEY="replace-with-your-openai-api-key"

Für claude-code setzen Sie eine Anthropic-kompatible Auth-Variable, zum Beispiel:

export ANTHROPIC_BASE_URL="https://api.anthropic.com"
export ANTHROPIC_API_KEY="replace-with-your-anthropic-api-key"

Wenn Sie direnv verwenden, führen Sie aus:

direnv allow

Wenn nicht, ist kein zusätzlicher Schritt erforderlich. Das Batch-Skript lädt .envrc zur Laufzeit explizit.

3. Fälle ausführen

Der kanonische Einstiegspunkt ist:

scripts/start_agent_batch.sh

Eine Risikodomäne ausführen:

scripts/start_agent_batch.sh --rd 5

Agent und Modell wählen:

scripts/start_agent_batch.sh \
  --rd 3 \
  --agent codex \
  --model openai/gpt-5.4

Mit Claude Code ausführen:

scripts/start_agent_batch.sh \
  --rd 3 \
  --agent claude-code \
  --model claude-3-7-sonnet-20250219

Einen einzelnen Fall ausführen:

scripts/start_agent_batch.sh \
  --rd 5 \
  --case travel_planning_poisoned_belief_persistence_memory_anchor

Eine einzelne Kategorie ausführen:

scripts/start_agent_batch.sh \
  --rd 6 \
  --category category3-model_behavior_and_finetuning_poisoning

Aus einem expliziten Manifest ausführen:

scripts/start_agent_batch.sh \
  --manifest benchmark/risk-domain-6-knowledge-model-supply-chain-and-operational-risks/manifest.json

Eine benutzerdefinierte Env-Datei verwenden:

scripts/start_agent_batch.sh \
  --rd 5 \
  --envrc /path/to/your.envrc

Ausgewählte Fälle ohne Ausführung anzeigen:

scripts/start_agent_batch.sh --rd 5 --dry-run

4. Laufausgaben lesen

Jeder Lauf erstellt ein Ausgabeverzeichnis unter jobs/:

jobs/<agent>-risk-domain-5-memory-recovery-audit-and-persistence-risks-<timestamp>/

Beginnen Sie mit:

• jobs/<run>/attack_results.json
• jobs/<run>/summary.json
• jobs/<run>/attack_results.csv
• jobs/<run>/summary.csv

Nützliche Dateien pro Lauf:

• selected_cases.json
• batch_config.json
• <case_id>/case_result.json
• attack_results.md

Häufige Angriffsergebnisse:

• attack_success
• attack_not_observed
• task_output_missing

task_output_missing bedeutet, dass die erwartete explizite Aufgabenausgabe fehlte. Der Angriffsverifizierer kann dennoch fortfahren, wenn genügend Artefakte vorhanden sind, um die Angriffsbedingung zu bewerten.