HANDOFF's implemented security boundary is local Wassette/Wasmtime execution, recipient-specific encryption and separation of public metadata from private task data. It does not use confidential VMs or provide complete confidentiality against the seller machine owner. See the README's security overview and the future confidential-compute design before making public claims.

Treat each claim below as something to verify in the running build before saying it on stage.

• runner.wasm runs as a WebAssembly component under Wassette (Wasmtime), deny-by-default. No filesystem, no raw sockets, no hosts beyond the grants:
  • seller (run-cycle): the Ollama origin (http://localhost) and the marketplace origin; one secret, AGENT_API_KEY (the seller's own marketplace identity).
  • judge (judge-cycle): https://api.anthropic.com and the marketplace origin; three secrets, AGENT_API_KEY, ANTHROPIC_API_KEY, JUDGE_PRIVATE_KEY_B64.
• Say it precisely: grants are per hostname, not per port. Wassette 0.8 matches scheme + hostname and ignores the port (C verified this against its HTTP filter). A seller sandbox granted http://localhost for Ollama can reach any service listening on localhost, not only port 11434. For the local demo the marketplace is addressed as 127.0.0.1 and Ollama as localhost, so the two grants stay distinct.
• The buyer's task is decrypted only inside the component: run-cycle generates a fresh X25519 key, presents it on claim_task (contract v0.2), decrypts and runs the task, and seals the result in the same instance. The daemon handles ciphertext only. The server refuses the judge's public key as a runner key.
• Demo: revoke or omit a grant and show Wassette's log line refusing the request (HTTP request blocked by network policy), then show the policy and the allowed call succeeding (demo/run.sh denied, denied-seller).

• It is not a TEE. The seller's OS can read the Wasm instance's memory and the Ollama process sees prompt tokens. A GPU TEE (confidential VM + attested inference) would close exactly that gap; the Wasm boundary covers everything else (files, network, env, other processes).
• No remote attestation. runner_wasm_sha256 is reported by the daemon; a malicious host could report any hash. From the server's side a per-claim key generated inside the sandbox is indistinguishable from one generated by the host. The model list and digests come from the seller's own Ollama and are self-reported; the runner only checks that the model is listed in /api/tags before running (no liveness canary yet).
• Encryption protects data in transit and at rest, keyed by whoever holds the private key. The server holds buyer keys for hosted convenience (documented in register_agent notes). A buyer-side proxy would remove that trust and is a stretch goal.
• Verdict explanations are fixed server text per reason code; judge model text is never published (contract §8.1). A judge infrastructure failure defers the review and cannot strike a seller (§8.2).
• The judge is a quality signal, not proof. One rejection is enough to suspend a seller in the demo (SUSPEND_AFTER_STRIKES=1) because the point is to show the mechanism; a real deployment would want a review path.

• Everything is Stripe test mode; the server refuses to start with a live key. Holds, captures, refunds and transfers are real Stripe objects you can show in the dashboard. Seller payouts (D, on main) succeed because test sellers get a synthetic Stripe test-mode identity, tagged as such in account metadata. Say so: it is not real KYC. A real seller would complete Stripe's hosted onboarding (onboardingLink()).
• Human control over agent spend: a human sets spend_cap_cents at buyer registration. post_task reserves max_price_cents against reserved + spent + max ≤ cap with an atomic compare-and-swap before placing the hold, so concurrent posts cannot jointly exceed the cap; a failed hold gives the reservation back. In MPP mode the human additionally approves each Link spend request, and a paid task is still refused if it would exceed the cap.

• Never log prompts, context, rubrics, answers, ciphertext bodies, API keys or private keys. events.meta holds ids and counts only.
• .env, .atm-state/, *.wasm build output are git-ignored. Do not commit keys; rotate in the dashboard if one leaks.
• Demo tasks use non-sensitive text.
• Only the judge machine holds JUDGE_PRIVATE_KEY_B64 and ANTHROPIC_API_KEY; seller daemons pass the judge key to their runtime only for --role judge.