Sandbox Conformance Harness is the local-only safety boundary for exercising agent write actions before any vendor sandbox or production system is involved. It is exposed through the Witnora CLI and reuses the runtime approval, idempotency, verification, rollback, and audit contracts.
Quick conformance check
npx witnora@latest sandbox init
npx witnora@latest sandbox certify --adapter ./witnora.sandbox.mjs
The command actively tests ten controls and writes:
.witnora/sandbox/sandbox-adapter-conformance.json
A passing report retains its versioned agentcert.* schema identifier so old
and new verifiers can read the same protocol bytes.
Controls exercised
| Control | Active check |
|---|---|
| Tenant isolation | A run scoped to tenant A attempts to name tenant B and must be rejected. |
| Synthetic data only | Credential-like keys and values in seed data must be rejected. |
| Deny network egress | An action with targetUrl must be rejected before execution. |
| Target allowlist | A non-allowlisted target system must be rejected. |
| Production deny | An action with environment: "production" must be rejected. |
| Approval gate | Every mutation must carry an identified reviewer decision. |
| Execution limits | Per-action amount, cumulative run amount, and action-count limits fail closed. |
| Kill switches | Both tenant and global kill switches stop new execution. |
| Idempotency | Concurrent identical retries share one action result; conflicting reuse is rejected. |
| Verification and recovery | Expected state is verified, rollback restores the snapshot, and reset restores the seed. |
Every action must provide an explicit idempotencyKey. Safety rejections are
returned as structured codes rather than ambiguous adapter errors. Customers
execute through the generated adapter; the low-level runtime remains the
reference contract for future vendor-sandbox adapters.
Lifecycle
- Create an isolated tenant with declared synthetic seed data.
- Start a bounded run.
- Submit an action with an explicit idempotency key and reviewer decision.
- Execute only against an allowlisted local target with no network access.
- Verify expected state against observed state.
- Roll back when requested and emit the Onegent audit packet.
- Complete the run and retain its report, or reset the tenant to its seed.
What this proves
- the reference sandbox enforces the ten v0.1 controls deterministically;
- an action cannot reach the reference state adapter through the harness without tenant scope, allowlisting, limits, idempotency, and approval;
- execution, observed-state verification, rollback, and audit evidence are connected in one local workflow.
What this does not prove
- that a production integration is safe;
- that external credentials, vendor APIs, payments, email, or portals were tested;
- that rollback can reverse an irreversible real-world side effect;
- regulatory compliance or third-party certification.
Path to a customer sandbox
Keep the same SandboxSystem contract and move in stages: local simulator,
isolated official vendor sandbox, production read-only shadow mode, then a
manually approved low-limit canary. A vendor adapter must use a separate test
account, short-lived least-privilege credentials, explicit egress allowlists,
deterministic reset, independent read-after-write verification, and a kill
switch. Real payment or broad production write access is not a valid first
integration.
Adapter Kit v0.2
Third-party implementations should use createSandboxSystemAdapter() and run
runSandboxAdapterConformanceSuite(). The v0.2 layer adds bounded tenant
leases, automatic cleanup, a Stripe Test Mode read-only reference, and Hosted
Control Plane evidence upload without changing the v0.1 ten-control report.