Authority Arena · replays of real runs

Follow an attack from the model's call to what the system did

Pick a task. Each replay puts one model on one task in two arms of the evaluation: on the left a weaker guard you choose, on the right Seal. Every call is shown as the model made it, every Seal decision as a signed record your browser checks, and every outcome as the simulated system recorded it.

The model asksA tool call, exactly as the model made it.
Seal decidesAllowed or blocked, against approvals that fix exact values.
The decision is signedAn ACTION-v1 record: 13 fields, Ed25519.
Your browser checks itAgainst the issuer key the run pinned. Edit it and the check fails.
The system applies or refusesIts ledger is the verdict, never what the model says it did.

Simulated systems. Payments and production are in-memory systems with their own ledgers. No money moved and nothing was deployed.

Local signing key. These runs used a local Seal gateway with a throwaway organisation and its own issuer key, pinned when each run started. It is not Seal's production key, so these records are evidence about the evaluation runs only.

Choose a task

The two runs

Compare Seal with

Where these runs come from

Each replay is a scored run from the Authority Arena results: for each model, task, repetition and arm, the newest run file, counted as the results page counts it. The run file and the harness commit are named under each run.

A replay is chosen where the model, with no boundary, applied something no approval covered, and the same model, task and repetition behind Seal applied nothing unapproved. One run is evidence about that run, not a rate; the rates are on the results page.

Check a record without this page

Copy any record above, then check it with the published verifier, against the issuer key shown under its run:

pip install aqta-verify-receipt

import aqta_verify_receipt
result = aqta_verify_receipt.verify_receipt(
    record, trusted_public_key="<the run's issuer key>", profile="ACTION-v1")
print(result.valid, result.reason)

The check on this page runs the ACTION-v1 field checks and verifies the Ed25519 signature with your browser's Web Crypto. Nothing is sent anywhere.

What a replay does not show

The systems that apply effects are simulated. A real executor that skips the check of Seal's record is not covered.
Seal governs the actions routed through it. An agent holding its own credentials to a system needs a sandbox as well.
In these runs the supplier's web page (A4) was the registered copy, not read live.

How the systems decide

An approval fixes exact values: invoice, amount, currency and IBAN for a payment; version and environment for a deploy. It can be used once and expires after 15 minutes.

Behind Seal, payments and production apply nothing without a Seal record that verifies against the pinned key, says ALLOWED, clears this tool, is unused and recent, and hashes to exactly the arguments about to run. The shell, a merge into release and a direct API call meet the same check.