Untrusted & BYO workers

Pond is built to run agents on machines you don’t fully control — a customer’s CI, a partner’s GPU box, a “bring your own compute” pool. This guide covers the two questions that raises: which machine may see which work, and can you trust the result that comes back.

The threat model in full: run-trust. The key nuance: a sandbox protects the host from the job, not the job from a malicious host. So an untrusted host needs data minimization (only give it what its owner may already see) and result attestation (verify what it returns) — not just isolation.

Trust tiers

A stage’s sandbox.tier decides which pool may run it:

Untrusted-code profiles default to trusted, so agent code never silently lands on a BYO/unpinned host. You reach a BYO host only by asking for it.

"sandbox": { "profile": "untrusted-code-write", "tier": "byo" }

Data minimization (per-tenant BYO)

A byo run is additionally pinned to its own tenant: pond appends a tenant:<projectId> required tag, so the job only lands on a worker the operator tagged for that tenant. Tag a BYO worker for the tenants it’s allowed to serve:

python swarm.py worker --orchestrator … --tags pool:byo,tenant:<projectId> …

A BYO host therefore only ever sees work for a tenant it’s already entitled to — cross-tenant data can’t reach it, even by mistake. (Today “tenant” is the project; org-level grouping can layer on top.)

Pinning worker identity (defeat a compromised orchestrator)

The orchestrator relays a worker’s public keys when it enrolls. To stop a compromised orchestrator swapping in keys it controls, an operator can paste the worker’s expected fingerprint when minting the enrollment code. At enrollment pond refuses any worker whose key fingerprint doesn’t match — and pins both the worker’s sealing key and its signing key at that gated moment (preferred over first-sight trust). Read the fingerprint out-of-band with:

python swarm.py fingerprint

Result attestation

When a worker finishes a pooled job it signs (job_id, input_sha, output_sha, rc) with its pinned signing key. Pond verifies the signature against that key and that input_sha matches the source bundle it issued — so a worker (or a relay) can’t fabricate or replay a result it didn’t actually produce. The run records attestation_verified; an unverifiable result is kept but flagged, never silently trusted.

This closes result fabrication by anyone who isn’t the keyholder. It does not make a malicious host honest about work it genuinely ran — for that, route sensitive work to trusted, or (future) a confidential-VM tier.

Putting it together

• Sensitive / multi-tenant work → leave it on trusted (the default).
• A customer running agents on their own repos on their own box → tier: byo
  • a tenant:<their-project>-tagged worker, with an enrollment fingerprint set.
• Either way, you get a signed, input-bound attestation back.

See also: Worker pool · Sandbox a run · run-trust.