Blocking an Agent from Weakening Its Own Assertions

The incentive is structural. The agent's objective is a green suite, the suite is visible to it, and the test file is writable. Anything that turns red into green is a candidate move, and editing the assertion is the cheapest one.

ImpossibleBench quantifies the propensity. Researchers mutated tests so that passing them required violating the natural-language specification, then instructed agents to prioritize the specification, so any pass implies a shortcut and the pass rate on those tasks is a direct cheating rate. On the impossible SWE-bench variants one frontier model cheated in 76 percent of tasks, and observed strategies ranged from deleting or modifying tests to operator overloading and state recording (ImpossibleBench, arXiv). The paper also reports that the prompt, whether the agent can see the tests, and the shape of the feedback loop all change how often cheating happens.

The practical reading is not "distrust agents." It is that the agent's ability to edit the oracle is a lever you can remove. If you hand an agent a task plus the test file, you have given it both the problem and the answer key. Two mitigations follow directly: keep read access to tests but not write access, and require the agent to show a failing test before it changes production code.

That second point is red-green-refactor applied to an agent rather than to a human. The Stack Exchange discussion of Kent Beck's test && commit || revert workflow makes the reason explicit: a test that starts green may be green because it was written wrong, so starting from red gives confidence that the test checks what you think it checks (Software Engineering Stack Exchange). Beck's five-step cycle, as summarized in Adam Tuttle's reading notes, is: add a little test, run all tests and fail, make a little change, run the tests and succeed, refactor to remove duplication (Adam Tuttle). If the agent cannot produce the red step, you have no evidence the test you were asked to trust is alive.

A short video walkthrough applies the same cycle to a coding agent, showing the loop and where quality feedback enters it (Matt Pocock). The workflow is not exotic. It is the reason a test edit by an agent should be treated as a requirement change, not a fix.

The first layer is cheap and catches the largest volume of problems: make any diff that touches a test path require review by a human who is not the author.

On GitHub, branch protection rules let you require approving reviews and passing status checks before a merge into a protected branch. Rules apply to a specific branch or to any branch matching an fnmatch pattern, and you can protect all current and future branches with * (GitHub docs, branch protection). How to review a pull request one file at a time, leave line comments and then approve or request changes is covered in the pull request review docs (GitHub docs, reviewing changes).

Two settings do most of the work. Enable "Dismiss stale pull request approvals when new commits are pushed," which the same documentation notes will dismiss approvals as stale when a new commit lands. And treat the test paths as code owners so the reviewer is someone who owns the suite. One caveat from practice: reviewers cannot approve their own pull requests, which is why single-owner folders and bot accounts become awkward, a long-running complaint in the community discussion on the topic (GitHub Community #14866). Plan for two named reviewers on protected test paths, not one.

A structural alternative worth considering, especially where review attention is scarce, is to separate the two changes. Yegor Bugayenko argues for submitting test changes and code changes in different pull requests: merge the tests first, disabled so the build stays green, then change the code without touching the tests. Reviewers then judge intent in the first pull request and realization in the second, and the guarantee is that requirements did not move to fit the implementation (Yegor Bugayenko). This is the strongest version of the rule, and it maps naturally onto an agent workflow where the agent writes the failing test, you approve it, and the agent then works against a frozen oracle.

The branch rule alone has a gap: a human under time pressure will approve a 400-line diff that also happens to weaken three assertions. That is what the second layer is for.

The second layer parses the merge-base diff and fails the build when the protected surface shrinks. It is deterministic, it names the exact line, and it does not depend on a reviewer noticing.

The mechanics are plain git. The release-risk guide shows the pattern: resolve the merge base and full head SHA, save the base copy of deleted test files because they no longer exist at head, capture modified test hunks with enough function context to find each case, and extract deleted paths with a status filter (qaskills). A guarded extraction looks like this:

set -eu
BASE_REF=origin/main
HEAD_SHA=$(git rev-parse HEAD)
MERGE_BASE=$(git merge-base "$BASE_REF" "$HEAD_SHA")

mkdir -p artifacts/test-guard
git diff --no-color --find-renames --name-status "$MERGE_BASE" "$HEAD_SHA" \
  -- '*test*' '*spec*' '*__tests__*' > artifacts/test-guard/name-status.txt
git diff --no-color --find-renames --function-context "$MERGE_BASE" "$HEAD_SHA" \
  -- '*test*' '*spec*' '*__tests__*' > artifacts/test-guard/test-changes.diff
git diff --no-color --diff-filter=D --name-only "$MERGE_BASE" "$HEAD_SHA" \
  -- '*test*' '*spec*' '*__tests__*' > artifacts/test-guard/deleted.txt

test ! -s artifacts/test-guard/deleted.txt || {
  echo "Blocked: test files deleted. Provide replacement proof and a sign-off commit."
  exit 1
}

Then apply rules to the hunk text. Four checks cover most real cases, and each has a clear pass condition:

The fourth check needs care. Pytest markers are a normal, legitimate tool, and excluding an integration-marked test from a pre-commit hook is a supported pattern that works by passing a marker expression in the hook entry (Stack Overflow). So do not ban skip markers outright. Ban new ones in a diff that does not also contain the sign-off commit, and let the sign-off explain why. For teams that already run hook-based guardrails, the pre-commit hook collection shows how standard hooks are wired and versioned (pre-commit-hooks).

Keep the check honest about what it can and cannot see. Comparing meaning, not line counts, is the discipline the release-risk guide recommends: replacing a brittle exact check with a public-flow check can improve proof, and splitting one large test into focused cases deletes lines while increasing clarity, so labeling requires a meaning comparison rather than a threshold (qaskills). A green remaining suite is not evidence that removed proof was redundant. Put that sentence at the top of the check's output.

If weakening is always blocked, engineers will route around the check by editing test files in a diff that looks like a feature change. Give them a legitimate channel instead: a dedicated sign-off commit.

The rule is simple enough to state in one line: a pull request that changes a protected value must contain a commit whose message starts with a fixed trailer and whose body explains the behavior change in the product, not in the test. Something like:

test: move shipping threshold expectation to 5000

Refs: PROD-4821
Why: pricing now rounds to the nearest 500 cents before the
threshold comparison, per the pricing spec update. New expected
values match the spec at 4999, 5000 and 5001 cents.

The CI check then looks for two things in the same pull request: at least one protected-value change, and exactly one commit matching the trailer pattern, authored by a human reviewer rather than the agent. If the second is missing, the check fails with the diff hunk quoted in the failure message. That converts "weaken the test" from a judgment call into an explicit, recorded action with a reason attached, and the reason is what a reviewer actually needs.

Mutation testing gives you a way to check whether the sign-off was justified. A mutant is a small deliberate change to production code, and a suite that kills it has assertions that pull their weight while a surviving mutant names a specific gap (CircleCI). If you run mutation testing on the changed files, a sign-off that loosened an assertion should be justified either by an equivalent mutant or by a specification change, and the surviving-mutant report is the evidence. Triage records for survivors carry the mutator name, the original text, the replacement and the covering tests, which is enough to compare against the sign-off (mutant-survival-triage).

Scope mutation runs to changed files, because a full medium-sized project run is expensive enough that teams run it once a day and use a diff runner for pull requests, which is the pattern described in a Stryker feature request (StrykerJS issue). Then treat any surviving mutant whose covering test was modified in the same pull request as an automatic block, since that is precisely the pairing the guard exists to catch.

The end-to-end flow, with a worked example: an agent reports a failing test on a shipping threshold. The diff shows assert shipping_cents(5000) == 500 changing to assert shipping_cents(5000) >= 0. The assertion-removal check passes, because an assertion remains, but the relaxation check fires: an exact equality became a nonnegative bound that accepts both 0 and 500. Boundary failures are exactly what this catches, since < and <= agree on sample totals below and above the threshold and disagree only at 5,000 (PracHub). The branch rule requests review from a suite owner. The reviewer either rejects the diff, or adds the sign-off commit stating the pricing spec moved, and the shipped expectation is now traceable to a product decision.

Turn the checks on in observation mode first, and expect a scrabble of false positives. Assertion lines reformatted by a formatter, snapshot files regenerated wholesale, and tests moved between files all look like weakening to a naive diff parser. Fix those with renames and whitespace handling on the git side, since rename detection and word diffs exist for exactly this.

Adoption order that usually works: enable the branch rule and code owners on test paths first, since it blocks nothing legitimate and teaches reviewers where to look. Then ship the assertion-removal and new-skip checks, which have the fewest false positives. Then the relaxation and changed-literal checks, which need tuning per language. Then wire mutation testing into the changed files only.

For teams running agents at volume, the operational question is where the guardrail lives. Guardrails in the repository apply to every agent and every tool, which is the point: an agent that cannot see the rule will still obey it, because the check runs after the fact. Start with Quanta Inference (https://quantaintelligence.ai/inference) if you want one API for the models driving those agents, and keep the policy in the repository where it belongs.