spec(search-with-proof): gVisor is the cluster boundary; declarative demos; capped rotated key

kube-ax probe: AX tasks have no capabilities (no namespaces, no setuid), so no
in-task isolation. Demos become data the verifier executes; the explore key risk is
accepted and bounded by cap and rotation.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
This commit is contained in:
Marius Ciepluch
2026-10-05 16:20:26 +02:00
co-authored by Claude Opus 5.5
parent e5ce630edc
commit 5e03bdf07f
@@ -56,8 +56,11 @@ known instead of restarting.
#### Acceptance Criteria #### Acceptance Criteria
1. A demonstration is an executable artefact (test, script or request sequence) that the system, not the agent, 1. *(Amended 2026-10-05, maintainer decision after the kube-ax probe: AX tasks have no capabilities, so gVisor and one
re-runs in fresh sandboxes. The **verifier observes the effect itself** through a per-family oracle it owns (for fresh task per side are the only isolation.)* A demonstration is **declarative data, never agent-written code**: a
build recipe chosen from the verifier's fixed per-ecosystem recipes, a start command of the form runtime + path +
arguments (no shell), and a request sequence (HTTP requests or CLI invocations, with values captured from earlier
responses) that the verifier itself sends. The system, not the agent, runs it in fresh sandboxes. The **verifier observes the effect itself** through a per-family oracle it owns (for
example a request log, a planted resource it watches, a browser execution check for XSS); the artefact's own exit example a request log, a planted resource it watches, a browser execution check for XSS); the artefact's own exit
code or output is never the oracle. code or output is never the oracle.
2. Each family's oracle states the attacker boundary (what the artefact may touch: only the documented external 2. Each family's oracle states the attacker boundary (what the artefact may touch: only the documented external
@@ -98,8 +101,10 @@ known instead of restarting.
operator). Store credentials stay out of the cluster (presigned links, as today). For this arm, model calls inside operator). Store credentials stay out of the cluster (presigned links, as today). For this arm, model calls inside
the cluster supersede `unseen-repo-evaluation` Req 4.4 (model calls on the VM); that boundary is unchanged for all the cluster supersede `unseen-repo-evaluation` Req 4.4 (model calls on the VM); that boundary is unchanged for all
other arms. *(maintainer decision 2026-10-05: scoped key in the cluster)* other arms. *(maintainer decision 2026-10-05: scoped key in the cluster)*
2. The key never appears in a manifest, a log, a board entry or a record, and is not readable by the repository code 2. The key never appears in a manifest, a log, a board entry or a record. *(Amended 2026-10-05, maintainer decision.)*
the sandbox executes (the model client and the executed code are separated). In the cluster, repository code run by an explore step shares the task with the key and could read it; this risk is
accepted and bounded: the key is scoped to search, has a low spend cap, and is rotated after every run. On the host
and VM the inner sandbox keeps the key out of executed code.
### Requirement 6: Feasibility pilot, false-proof qualification, then the unseen pool ### Requirement 6: Feasibility pilot, false-proof qualification, then the unseen pool