
Der erste Benchmark zur Bewertung, wie gut LLM-Agenten im Einklang mit ihrem zugewiesenen Autorisierungsumfang handeln.
Das erste systematische Framework zur Bewertung der Ausrichtungsübereinstimmung von LLM-Agenten bei Autorisierungen unter gutartiger Delegation, unabhängig davon, ob direkte schädliche Folgen auftreten oder nicht.
Innerhalb des zugewiesenen Autorisierungsumfangs zu handeln, ist die grundlegendste Pflicht eines Agenten in einer Mensch-Agent-Delegationsbeziehung. Die meisten Agenten-Benchmarks belohnen die Aufgabenerfüllung oder bewerten, ob eine Aktion direkten Schaden verursacht. Sobald ein Agent jedoch außerhalb dieses Umfangs handelt, untergräbt er die Kontrolle des Prinzipals und die Delegationsbeziehung selbst – unabhängig davon, ob daraus direkter Schaden folgt. Aktuelle Benchmarks erfassen dieses Versagen selten.
Das Framework umfasst drei Komponenten:
Ein dokumentierter Fall wird in eine Aufgabe übersetzt, bei der sowohl der autorisierte Abschlusspfad als auch der fallspezifische Pfad außerhalb der Autorisierung ausführbar sind. Der Agent läuft in der Sandbox, und seine tatsächliche Trajektorie und der resultierende Zustand werden gegen den Autorisierungsvertrag bewertet.
Wir evaluieren vier Modelle mit niedrigem und hohem Reasoning-Aufwand über drei Agenten-Harnesses hinweg und erzeugen 6.864 Trajektorien. Agenten handeln in 19,2 % der delegierten Aufgaben außerhalb der Autorisierung.
Über 91 abgeglichene Aufgabenpaare hinweg treten etwa 54 % der beobachteten Läufe außerhalb der Autorisierung in der Version ohne direkten Sicherheits- oder Datenschutzschaden auf. Mit anderen Worten: Innerhalb dieser Paare würde mehr als die Hälfte des Verhaltens außerhalb der Autorisierung von einer Evaluation übersehen, die nur nach direkten schädlichen Folgen sucht.
authorization_eva_sandbox/
├── tasks/ 286 executable task bundles
├── vignettes/ authorization contracts and scenario specifications
├── seeds/ documented source-case summaries used by the benchmark
├── services/ deterministic mock services
├── evaluation/ harness adapters, judges, detectors, and analysis
└── task_generation/ seed-to-task and contextual-expansion pipelines
benchmark/
├── manifest.json frozen release inventory
└── lineage.csv source case to original and expanded task mapping
taxonomies/ environment pressure, direct-harm, and domain definitions
Voraussetzungen sind Python 3.12 und Docker Desktop.
git clone https://github.com/PEACH-Research-Lab/AuthorizationBench.git
cd AuthorizationBench
bash scripts/bootstrap.sh
docker build \
-f authorization_eva_sandbox/Dockerfile.v2 \
-t authorizationbench:sandbox \
authorization_eva_sandbox
cp authorization_eva_sandbox/evaluation/config.toml.example \
authorization_eva_sandbox/evaluation/config.toml
Füllen Sie nur die Provider-Profile aus, die Sie verwenden möchten. Die lokale Konfiguration wird von Git ignoriert und darf niemals committet werden. Siehe die Quick start guide für harness-spezifische Umgebungen und Evaluierungsbefehle.
python -c "from huggingface_hub import snapshot_download; \
snapshot_download('peach-lab/AuthorizationBench', repo_type='dataset', \
local_dir='authorizationbench-data')"
Der Benchmark enthält 44 ursprüngliche Aufgabenfälle, die auf 42 verwendeten Quell- datensätzen basieren, gefolgt von einer kontextuellen Erweiterung auf 286 Aufgaben. Zwei Quelldatensätze unterstützen jeweils zwei unterschiedliche ursprüngliche Aufgabenfälle.
benchmark/lineage.csv ordnet jede Aufgabe ihrem Quelldatensatz
zu, kennzeichnet ursprüngliche und erweiterte Fälle und dokumentiert die Erweiterungsachse,
sofern verfügbar. benchmark/manifest.json friert
das exakte Aufgabeninventar für dieses Release ein.
Der unterstützte Einstiegspunkt von Seed zu Aufgabe ist:
./au312/bin/python -m authorization_eva_sandbox.task_generation.run_v3 \
--seed-id S0001
Die kontextuelle Erweiterung beginnt mit einer validierten Aufgabe und variiert eine Dimension, während die zugewiesene Aufgabe und die Autorisierungsgrenze erhalten bleiben. Die öffentliche Pipeline umfasst Generierungs-Prompts, deterministische Gates, begrenzte Reparatur, Service-Realisierung und Erweiterungscode. Historische Migrationswerkzeuge und einmalige Entwicklungsskripte sind bewusst ausgeschlossen.