Google’s Harness² Lets Agents Rewrite Their Own Harness — The Security Questions That Come With It

Google Research just published Harness² (arXiv 2610.14224, code at google-research/harness2) — a framework where an AI agent rewrites its own harness to get better at tasks it was never designed for, with the model’s weights left untouched. It works, and the gains are real. For security and AI-platform leaders, it is also a clear look at a surface we will all have to govern: the scaffolding around the model, when that scaffolding can edit itself.

Analysis for CISOs, AI-platform and GRC teams. This is PlayCISO’s own read of a public research release; it is not a vulnerability report and not an alarm. Every figure is from the paper/repo and linked at the end.

What it is, plainly

A harness is everything around a model that makes it an agent: the system prompt, tools, memory, skills, subagents, orchestration and guardrails. Harnessing is optimizing that system. Harness² automates it, with two loops and fixed model weights:

• Task-level recursion — for the task in front of it, a Propose–Probe–Compose step: propose harness edits, probe their effect on the same task, and compose a refined harness from the behavioral contrast between runs — no ground-truth answer needed.
• Harnessing-level recursion — a persistent improvement harness that accumulates adopted harnesses and evidence-backed lessons to guide refinement on future tasks.

Across three professional benchmarks (JobBench, LAB, WorkBuddy-Bench) and models including GLM-5 and Gemini 3.5 Flash, one step reports gains of up to 11.8 points on LAB, 11.5 on WorkBuddy-Bench and 4.5 on JobBench, with more budget yielding more. The eight editable components are the system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins.

Why a security brand cares about an agent-performance paper

Because that list of eight components is also an attack-surface map, and Harness² makes it a moving one. Static agents are governed by fixing what they can see and do. A self-editing harness changes those very things — tool guidance, guardrails, subagent delegation, plugins in the tool loop — as it runs. The advance is welcome; the discipline it demands is the story.

The paper flags its own sharp edge

Credit to the authors for stating it directly. Under Web access, the release notes that executor network access is unrestricted, the Codex executor runs with its sandbox disabled, and public benchmark rubrics may be reachable online — so it instructs you to configure network restrictions before evaluation to prevent access to benchmark answers and grading criteria. That is two lessons in one. First, eval integrity: an agent that can reach the rubric can game the score, so a self-improving loop with open egress can "improve" by cheating. Second, the general one: an agent executor with unrestricted egress and no sandbox is a data-exfiltration and SSRF surface, whatever the task. Default to an egress allow-list and an enabled sandbox; make open access the deliberate exception, not the starting point.

How to fold it into frameworks you already run

None of this needs a new program — it extends the ones maturing now. The agent-specific threats a self-editing harness raises (prompt injection into memory or tool output, tool misuse, capability creep) map cleanly onto ISO/IEC 27090’s threat catalogue and the CIA triad. The "who may change what, and is it evidenced" question is an ISO/IEC 42001 AI-management lifecycle and change-control problem. The "what tools and components does this agent actually run, and where did they come from" question is provenance — the same discipline as an AI Bill of Materials. And to reason about a specific agent’s blast radius, our LLM Threat-Model Generator gives a fast first pass.

The honest takeaway

Harness² is a genuine step: measurable gains from optimizing the system around a model instead of the model itself, generalizing to unseen tasks. The security point is not fear — it is that the harness is now part of the attack surface and the change-control surface, and self-improvement only stays safe when it runs inside bounds you set: human-gated edits to anything privileged, non-self-expandable grants, auditable provenance, and executors that are sandboxed with controlled egress by default.

Sources & credit

• Harness² paper — arXiv 2610.14224, "Harness²: Recursive Agent Harnessing for an Open World" (Xu et al., Google Research).
• Code — github.com/google-research/harness2 (Apache-2.0; "not an officially supported Google product," per its own disclaimer).

Published 18 Oct 2026. Figures and the "Web access" caveat are quoted from the public paper and repository; where our summary and the paper differ, the paper is authoritative.