Auto-approve is not a neutral convenience

Removing human confirmation appears to reduce friction. In a coding agent, however, the same setting that accelerates legitimate operations may also release actions that cross the task boundary. This is not only a developer-experience decision: it is an authority decision.

Status: Evidence Brief approved for publication. This text analyzes the *HarnessSecurity-Bench* preprint and its public artifacts. It does not claim that Trustyu Forge reproduced the experiments, that the result universally ranks the evaluated products, or that the percentages transfer to another model, version, environment, or organization.

What the study separates

The work distinguishes two questions that are often mixed together:

1. which security mechanisms appear in coding-agent harnesses and with what default configuration;
2. what effect those mechanisms have on legitimate utility and unauthorized actions under controlled execution.

In the first stage, the authors built a ten-mechanism taxonomy and evaluated 40 harnesses — 27 open source and 13 closed source. This produced 400 harness–mechanism cells. The team classified 205 as confirmed implementations, 83 as confirmed absences, and 112 as unresolved. Among the 205 confirmed implementations, 109 were opt-in and 96 were enabled by default.

Unresolved states were more frequent in closed-source products: 69 of 130 cells, compared with 43 of 270 in open-source alternatives. This difference describes evidence availability; it does not prove that one licensing model is more secure than another.

How the benchmark was run

HarnessSecurity-Bench contains 23 programming tasks across five attack surfaces. The tasks preserve a legitimate instruction, an executable environment, and separate deterministic oracles for utility and adversarial effect.

Nine mechanisms were evaluated across six harnesses: Claude Code, Codex CLI, Gemini CLI, gptme, Qwen Code, and GitHub Copilot. GLM-5.2 was held as the base model so enabled and disabled conditions could be compared.

The study ran 2,500 trials, recorded 81,155 tool calls, more than 2.2 billion tokens, and 589.32 cumulative execution hours. Each condition was repeated ten times. The design measures fixed configurations in isolated containers; it is not telemetry from everyday enterprise use.

The observed effect of auto-approve

In the published aggregate, enabling auto-approve raised utility from 77.1% (601/780) to 95.4% (744/780). At the same time, the adversarial-effect success rate rose from 29.2% (105/360) to 95.6% (344/360).

The result does not say that 95.6% of real sessions with auto-approve will be compromised. It describes what happened in the tasks and adversarial surfaces constructed by the benchmark, with the model and versions fixed by the researchers. Even so, the simultaneous increase in utility and exposure shows why “faster” and “safer” cannot share the same metric.

Auto-approve does not add a new capability. It removes a confirmation barrier before capabilities that are already available. If the agent trajectory contains a misleading instruction, an untrusted artifact, or an alternate path to a protected operation, removing the pause makes the effect more likely.

Restrictions also have a cost

The study does not offer a magic control. Network isolation reduced the adversarial-effect rate from 57.1% to 0.8%, but cost 24.5 percentage points of utility. Read-only mode reduced the same indicator from 8.3% to 0.8%, accompanied by a 34-point utility loss.

Command allowlisting and denylisting showed smaller aggregate trade-offs, but the cases also revealed alternate paths. Allowing an interpreter or another general-purpose tool can keep an operation reachable even when the list was intended to block it.

The architectural conclusion is not to turn on every restriction. It is to build a task-boundary with minimum capability, preserved legitimate paths, tested denials, and evidence of both protection and operational cost.

An operational contract for approvals

1. Classify the effect: reading, writing, execution, network, secrets, publication, deletion, and infrastructure change do not have the same consequence.
2. Bind authorization to the task: an approval should state which operation, resource, destination, time window, and volume were accepted.
3. Keep deny-by-default for material effects: the agent requests elevation only when the action is necessary and justifiable.
4. Separate review from mechanical confirmation: repetitive and reversible actions may use policies; irreversible, external, or privileged operations require proportional human authority.
5. Test alternate paths: shells, interpreters, package managers, compound tools, and APIs may reach the same effect through another route.
6. Measure utility and adversarial effect: blocking everything may produce a secure system that cannot complete the task; allowing everything may produce speed without control.
7. Record the receipt: request, policy, decision, granted capability, calls made, result, revocation, and the person responsible for acceptance.

Architecture rule

Sandbox, network, identity, authorization, and human confirmation are different controls. None of them alone defines the agent's total authority. A safe boundary comes from task-level composition and must be tested across allowed and denied routes. [R2-C3]

In Forge, auto-approve should not be treated as an interface preference. It changes the execution contract. Enabling it requires scope, validity, rollback, telemetry, and a human owner accountable for the released effect.

Limits and conflicts of interest

The preprint is v1 dated October 6, 2026. The runtime evaluation uses 23 tasks, six harnesses, and one controlled base model; containers and simulated services do not reproduce all production complexity. Approval decisions in the no-auto-approve condition use an LLM-based reviewer subject to bias and residual variation.

Closed-source products have more evidence gaps and graphical workflows that are difficult to automate. This limits comparability and does not justify concluding that a mechanism is absent. Task packages and utility checks are public; the repository states that the full runner is maintained separately. As of the October 7, 2026 cutoff, we found no independent reproduction of the complete benchmark.

The authors are affiliated with Sun Yat-sen University, Peng Cheng Laboratory, East China Normal University, Hong Kong Baptist University, and Tsinghua University. We found no commercial affiliation between the authors and the six evaluated providers in the preprint's public information. No identified conflict is not proof of absolute independence.

Direct sources

1. HarnessSecurity-Bench: Do Security Mechanisms Really Protect Coding Agent Harnesses? — arXiv. Preprint, authors, abstract, version, and dates.
2. HarnessSecurity-Bench — full text. Method, denominators, results, limits, and data availability.
3. HarnessSecurity-Benchmark — official repository. Task packages, manifests, and utility checks.
4. HarnessSecurity-Bench — project page. Official study material.

Editorial and responsibility note

This text combines facts attributed to sources with the author's analysis and technical proposal. Personal and professional views are not proven facts; data, denominators, limits, affiliations, and the absence of independent reproduction are stated when available. The content is informational and does not replace technical, legal, financial, or security assessment. Product names belong to their respective owners; there is no sponsorship, endorsement, or claim of a specific production vulnerability. Tech Human and Trustyu work commercially in digital-product development and governance. Research, structure, and writing were assisted by AI; factual review, author approval, and publication were authorized by Fernando Parreiras on October 7, 2026, without additional independent human review.

Research cutoff: October 7, 2026. Editorial status: special Evidence Brief authorized for October 11, 2026 at 9:00 AM BRT.