open-standards/sandbox/conformance
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science e526133f21 Sandbox + JCP: long-horizon agent execution
Add a coherent set of long-running-agent capabilities, each as a spec
section + reference implementation + conformance class, every one metered,
attested, and receipt-chained.

Sandbox:
- §13 Durable run records (C6): the receipt chain IS the resumable run;
  execute/suspend/resume segments hash-chained; idle energy metered across
  parks. (sandbox-attest::runrecord)
- §14 Environment manifest (C7): devcontainer.json declarative-subset
  ingestion -> canonical, content-addressed, signed manifest;
  command/widening and unknown fields refused. (sandbox-attest::manifest)
- §5.5 Content-addressed process control (C8): exec allow/deny by BLAKE3 of
  the binary; denylist absolute, survives rename/move/wrapper.
- §15 Warm pools (C9): a claim attributes accrued idle energy to the run
  (a fast start has a visible joule price); evictions record overhead, not
  zero. (sandbox-attest::warmpool)
- §16 Fleet records (C10): merkle aggregate receipt over per-item runs;
  log-size membership proofs. (sandbox-attest::fleet)
- durable.json cross-impl wire vectors + file-backed verify.

JCP:
- §4.6 Standing grants (C20): a signed mint policy turns a held grant into
  bounded, rate-limited, event-triggered children via the attenuation path.
  (jcp-grant::standing)
- §4.7 Checkpoints + amendments (C21): mid-run steering under separation of
  duties — the agent checkpoints its own state, only the issuer (a distinct
  principal) may amend, and only to tighten. (jcp-grant::checkpoint)
- standing.json cross-impl vectors.

Both workspaces green; conformance harnesses pass with no skips; clippy clean.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-12 23:14:59 -04:00
..
v1 Sandbox + JCP: long-horizon agent execution 2026-06-12 23:14:59 -04:00
README.md
VERSIONS.md

Sandbox conformance vectors

Signed, content-addressed wire vectors for the Sandbox standard (SPEC §10, ../spec/conformance.md). An implementation is conformant for the tiers it advertises if it round-trips these vectors with no skips.

The vectors are the authority. They are not illustrative: each is a real, cryptographically computed value, and the reference harness recomputes every content address, sealed JCR-1 envelope, and Ed25519/JCS signature and checks it against the committed file. A change to wire behaviour MUST regenerate the vectors and note it in VERSIONS.md.

Layout

conformance/
├── README.md        — this file
├── VERSIONS.md      — vector-set changelog
└── v1/              — the v1 vector set
    ├── content_addressing.json   — C1: bytes → BLAKE3 content id
    ├── capability.json           — C2: grant set → allow/deny decisions (incl. negatives)
    ├── receipt.json              — C3: per-device receipt → core, content id, sealed JCR-1 envelope
    ├── attestation.json          — C4: attestation → JCS bytes, content id, Ed25519 signature
    ├── tier.json                 — C5: grant set + flags → required tier
    ├── negative.json             — C-neg: malformed receipts + attestations a host MUST reject
    └── confidential.json         — C-tee: SEV-SNP report verification + audit-chain vectors

Vector classes

  • C1 — canonicality. Content addressing (b3: + base64url over BLAKE3-256) is byte-stable.

  • C2 — capability enforcement. The deny-by-default Enforcer returns the fixed decision for each query, including the negatives (ungranted device class, read-only path written, wrong port).

  • C3 — receipt integrity. The per-device records sum to the total; the (provenance, measured_uj) coupling holds; the sealed JCR-1 envelope verifies under the committed steward key and matches the canonical core.

  • C4 — attestation. The core canonicalizes to the fixed JCS bytes and verifies under the committed supervisor key; the device classes match the receipt's.

  • C5 — tier minimization. Each grant set + flag combination resolves to the lowest satisfying tier (S0–S7).

  • C-neg — adversarial negatives. negative.json holds malformed artifacts a conformant host MUST reject: a HwShunt reading with no measured figure, an Estimator carrying one, a total that does not equal the device sum, a measured-coverage mismatch, an attestation that omits an accelerator the receipt metered (SPEC §7.2), an S6 attestation without TEE evidence (SPEC §7.6), a replay journal that diverges and one that is truncated (SPEC §8), and a mid-run grant-set mutation whose content address changes (SPEC §1.2). The harness asserts each is rejected or detectable.

  • C-tee — confidential + sovereign. confidential.json carries SEV-SNP report vectors — a valid report that verifies against policy + VCEK, plus negatives (wrong launch measurement, tampered body that fails the ECDSA-P384 signature) — and a hash-chained audit-log vector that must verify (SPEC §7.6, §7.7).

Negatives are what a standard certifies; growing this set (tier-minimization violations, anti-evasion probing) is the highest-value contribution here — see ../CONTRIBUTING.md.

Regenerating and verifying

cd ../sandbox-rs
cargo run -p sandbox-conformance --bin gen_vectors   # rewrite conformance/v1/*.json
cargo test -p sandbox-conformance                    # verify in-code + file-backed
cargo run -p sandbox-cli -- conformance              # human-readable pass/fail

Ed25519 signing is deterministic (RFC 8032), so the signatures are reproducible known answers: regenerating on an unchanged reference produces byte-identical files.