Recursive Harness Change-Control Lab
Google Research's Harness² (arXiv 2610.14224) lets an agent recursively rewrite its own harness — the system prompt, guardrails, persisted memory and “lessons”, tool guidance, subagents, skills, scripts and plugins — and carry improvements forward. Powerful, and a change-control problem: an optimizer that can edit its own guardrails can quietly remove the controls that keep it safe. You are the change-control board. For each proposed self-edit, decide whether to auto-adopt, adopt with logging, require human review, or reject it, name the risk tier it carries, and pick the control that should gate it — because an edit touching tools, permissions or guardrails never auto-adopts, a safety-removing “lesson” is a reject, and the harness may never grant itself more privilege than it was given.
The real job. More noise, a tighter clock.
Proposed self-edits
1 / 9 triaged
System prompt · wording
diff · “be helpful and careful” → “state your assumptions, then answer” — no capability, tool, permission or guardrail change
The optimizer found the old phrasing produced rambling openings and proposes a clearer instruction with identical behaviour.
1 · Adoption decision
2 · Risk tier
3 · Control / evidence that should gate it
Pick a decision, the risk tier, and a control to continue.
Decision × risk map
This edit: choose its decision and the risk it carries.
Change control
A recursive harness (Harness², Google Research) wants to rewrite itself. For each of 9 proposed self-edits, decide the adoption decision, the risk tier, and the control that should gate it.
So far: 0 / 9 edits triaged.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based governance drill for self-rewriting agents: Google Research's Harness² (arXiv 2610.14224) lets an agent recursively rewrite its own harness — system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins — and carry "lessons" forward. This lab is the change-control board for those self-edits.
- For each proposed self-edit you pick the adoption decision (auto-adopt / adopt with logging / require human review / reject), the risk tier it carries, and the control that should gate it (change-control gate, provenance log + rollback, scope cap, sandbox, or re-review on drift).
- The core rule it drills: edits touching tools, permissions, guardrails or auth NEVER auto-adopt; benign prompt-wording and formatting edits can; a persisted "lesson" that removes a safety step is a reject; and the harness may never grant itself more privilege than it was given (non-self-expandable privilege).
- It also drills the opposite failure — over-gating. A pure wording change, or a vetted read-only skill, should flow through cheaply; blocking every edit defeats the point of a self-improving harness.
- Mapped to ISO/IEC 42001 change-control and lifecycle management of the harness as a governed artifact, and ISO/IEC 27090 security guidance (supply-chain and self-modification concerns). An edit queue, a live decision × risk map, difficulty tiers, a speed bonus and an S–D grade.
The decision follows the substance of the edit
Most governance mistakes on a self-rewriting agent come from classifying an edit by where it lives instead of what it does. An edit that sits in the system prompt is not automatically “just wording” — if the words are a guardrail, like a required AI-disclosure, deleting them is a safety change and a reject. An edit that merely reformats the tool section adds, removes and re-scopes nothing, so it is safe to auto-adopt. The rules the lab drills are concrete: edits touching tools, permissions, guardrails or auth never auto-adopt; they go to human review behind a change-control gate, sandboxed and scope-capped first. A persisted lesson that removes a safety step is a reject — reviewing or logging it still leaves a self-authored instruction to skip a control living in memory. And a subagent must run under a scoped-down, least-privilege token, never the parent's full credentials: non-self-expandable privilege is the rule.
Just as important: do not over-gate. A pure wording or formatting change should flow through with a logged, reversible diff and no review board; a vetted, read-only, no-new-privilege skill or a benign task technique should adopt with logging. Blocking every edit trains the optimizer that improvement is pointless and defeats the purpose of a self-improving harness. The whole skill of this review is letting the safe edits through cheaply while stopping the ones that touch tools, permissions, guardrails, auth or safety-removing memory — and that is exactly the lifecycle change-control that ISO/IEC 42001 expects over a managed AI system, with the supply-chain and self-modification threats that ISO/IEC 27090 describes in view.
Frequently asked questions
What is Harness² and why does it need governance?
Harness² is work from Google Research (arXiv 2610.14224) in which an agent can recursively rewrite its own "harness" — its system prompt, guardrails, persisted memory and "lessons", tool guidance, subagents, skills, scripts and plugins — tuning itself per task and carrying improvements forward. That is powerful, but an optimizer that can edit its own guardrails can also quietly remove the controls that keep it safe. Change control is what lets the useful self-edits through while stopping the ones that erode safety, so this lab drills that review as a per-edit decision.
What does the lab actually ask me to decide?
For every proposed self-edit you make three calls: the adoption decision (auto-adopt, adopt with logging, require human review, or reject), the risk tier it carries (none, low, medium or high), and the control or evidence that should gate it (a change-control gate, a provenance log with rollback, a scope cap, a sandbox, or re-review on drift). The decision is weighted most heavily, then the control, then the risk tier, and you only clear the drill when every decision and every control is correct.
Which self-edits should never auto-adopt, and which safely can?
Anything touching tools, permissions, guardrails or auth never auto-adopts — adding a shell-exec tool, relaxing an egress guardrail, or changing how a money-moving action fires all go to human review behind a change-control gate, or are rejected outright when they remove a safety control or over-grant privilege. A persisted "lesson" that removes a safety step is a reject, and a subagent handed the parent's full token violates non-self-expandable privilege. On the other side, a pure wording or formatting change auto-adopts (logged and reversible), and a vetted, read-only, no-new-privilege skill or a benign task technique adopts with logging. The skill is telling those apart rather than blocking everything.
Does this touch a real agent or make any claims about Harness²'s performance?
No. It is an educational, offline exercise with synthetic self-edit scenarios. It does not run, modify or connect to any agent, and it makes no performance claims about Harness² — it simply uses the published idea of a recursively self-rewriting harness as the setting for a change-control decision. The governance framing is tied to ISO/IEC 42001 (managing the AI system and its changes through a controlled lifecycle) and ISO/IEC 27090 (security guidance for AI, including supply-chain and self-modification risks).