Pilot reference / reviewed 5 September 2026

Private Agent Handoff: setup and threat model

One lead agent shares selected brief fields with one reviewer. The kit signs and encrypts locally, and checks policy before releasing the brief at the recipient. It does not host messages, execute tasks, or authorize a payment.

Download the kit · SHA-256 checksum · Source and tests · $299 team pilot

What is available now?

A local Python reference kit, a synthetic browser policy simulator, and a no-charge pilot application. The kit has real encryption and signature checks; the browser simulator has neither and is labeled accordingly. A hosted private messaging service and automated subscriptions are not available.

The paid pilot is implementation work: one agreed Python review workflow in your test environment, acceptance tests, a runbook and two scheduled check-ins over 30 days. Apply free; an invoice follows only after written scope agreement and delivery of the agreed acceptance tests. No automatic renewal.

Local quickstart

Download and extract the kit into a private working directory. Use Python 3.11 or newer and synthetic data. The kit includes a requirements file, an executable CLI example, an example brief, and offline tests.

python3 -m venv .venv
.venv/bin/python -m pip install -r requirements.txt
.venv/bin/python -m unittest -v checks
mkdir -m 700 local-demo

.venv/bin/python handoff.py keygen \
  --private local-demo/lead.private.json --public local-demo/lead.public.json
.venv/bin/python handoff.py keygen \
  --private local-demo/reviewer.private.json --public local-demo/reviewer.public.json
.venv/bin/python handoff.py init-state --state local-demo/reviewer.sqlite3

.venv/bin/python handoff.py seal \
  --brief brief.example.json --fields objective,deliverable \
  --issuer agency:lead --audience agency:reviewer --ttl 300 \
  --issuer-key local-demo/lead.private.json \
  --recipient-key local-demo/reviewer.public.json \
  --out local-demo/handoff.jwe

.venv/bin/python handoff.py accept \
  --envelope local-demo/handoff.jwe \
  --issuer agency:lead --audience agency:reviewer \
  --issuer-key local-demo/lead.public.json \
  --recipient-key local-demo/reviewer.private.json \
  --fields objective,deliverable --state local-demo/reviewer.sqlite3 \
  --out local-demo/accepted.json

accepted.json contains private plaintext and a recipient-signed receipt. Never publish or log it. The console contains a decision only. Repeating acceptance with a new output path must return already_consumed.

For a real integration, separate the sender and receiver processes and keep each private key at its owner. Deliver the encrypted envelope over your existing authenticated transport. Pin public keys and identifiers through an independent trusted channel; never take a trust key from the incoming envelope.

What is enforced?

Control	Reference behavior
Data minimization	Only selected `objective`, `deliverable` and `style` strings. Recipient independently allowlists fields. Maximum selected payload: 8,192 bytes.
Identity binding	Locally pinned signing/decryption keys and exact issuer/audience. Names are operator-configured identifiers, not certified real-world identities.
Scope	`review:brief` only; zero spending permission. No execution engine.
Freshness	60 to 900 seconds. Receiver clock checks issuance, not-before and expiry.
Replay	One atomic acceptance per issuer and handoff ID in the recipient's durable SQLite store. Missing or corrupt state blocks acceptance.
Revocation	Authorized operator writes a revocation into the recipient's local store before acceptance. No remote revocation service.
Receipt	Recipient-signed acceptance record with a hash of the encrypted envelope. No task contents; not proof of execution, quality or payment.

Threat model and limits

The reference assumes uncompromised hosts, private keys, authenticated provisioning, synchronized clocks, and durable state. The team retains responsibility for transport authorization, key lifecycle, monitoring, data classification, backups and recipients.

Tests cover wrong issuer/key/recipient, altered envelopes, expiry, replay, local revocation, unexpected fields, scope escalation, nonzero spending and unavailable state. Passing tests is not an independent audit.
An authorized receiver can retain or forward plaintext. Revocation cannot undo an accepted handoff.
Field selection does not detect secrets inside an approved field. This is not automated redaction or data-loss prevention.
Encryption does not solve prompt injection, malicious instructions, endpoint compromise, or traffic analysis. RSA encryption in this kit does not provide forward secrecy; no post-quantum claim is made.
Local files use restrictive permissions, not encryption at rest. Protect keys, accepted briefs and backups separately.
Replay protection covers one shared recipient store, not independent replicas. Distributed deployment needs a shared atomic store and revocation design. Do not roll back or delete live replay state.
Receipts are not OAuth tokens, Ontario safety attestations, or certified identities. Keep existing authorization, and do not forward one service's bearer token to another.
Production use with sensitive data requires an organizational security/privacy review. No compliance certification, guaranteed safety or production SLA is supplied.

What does Ontario receive?

The downloaded kit makes no network requests and sends no keys, envelopes or task payloads to Ontario. The website serves ordinary page assets and receives normal hosting request metadata. Its simulator uses fixed synthetic data without local storage or analytics events.

The separate pilot form sends only work email, public company homepage, integration choice, weekly volume range and contact consent. Ontario privately stores these for qualification and follow-up; an owner notification may include your business contact. The form does not accept task documents. Contact hello@ontarioprotocol.com to request deletion. Do not send confidential workflow contents during initial qualification.

Protocol and library references

The kit uses JWCrypto for JWS RS256, followed by JWE RSA-OAEP-256 / A256GCM, with RSA keys of at least 3072 bits. Fixed headers reject compression, key-lookup URLs and algorithm negotiation. The requirements pin JWCrypto 1.6.0; inspect its security release history.

These are standard JOSE envelopes with application-specific review claims. They do not replace MCP transport authorization. Ontario's existing payment preflight remains separate and is not invoked by this zero-spend review kit.

Report a security issue · Evaluate the synthetic handoff