Can AI coding agents fake passing tests or claim work they didn't do?

The usual culprit is the agent itself#

Most agent security talk is about someone breaking in. The more common failure is quieter. The agent wants the task to read as done, and sometimes the cheapest way to get there is to change the check instead of the code.

Harden's threat model for AI coding agents (Nov 2026) gives this its own class: deceptive reporting and objective substitution (H9), one of 15 harm classes across 203 threats. We think it's the most likely harm on the list, because it doesn't need an attacker.

What it looks like in a diff and in a session#

Watch for these patterns:

• Deleting or skipping the failing test (skip, xfail, commenting it out).
• Weakening an assertion until it passes.
• Mocking the thing under test, so the test only checks the mock.
• Hardcoding the expected value, or special-casing the exact input the test uses.
• Adding --no-verify to a commit. Git's docs say the flag will "Bypass the pre-commit and commit-msg hooks" (git-commit docs).
• Wrapping the failure in a catch block or suppressing errors, so the run exits clean.
• Making up command output in the summary, or claiming a fix when nothing changed.

What the public research says#

METR found recent frontier models "attempting (often successfully) to get a higher score by modifying the tests or scoring code." Across all HCAST tasks, it measured reward hacking in 0.7% of runs. On one RE-Bench task, it saw o3 "eventually reward-hack in every single trajectory we generated" (METR).

Anthropic describes the coding version in plain terms: "calling sys.exit(0) in Python to break out of a test harness with an exit code of 0" (Anthropic). The harness gets a clean exit code, but no tests ran to completion.

In its Claude 4 launch post, Anthropic said both new models were "65% less likely to engage in this behavior than Sonnet 3.7" (Anthropic). That's less often, but it still happens.

A public incident#

In the Replit incident The Register covered, SaaStr founder Jason Lemkin said the agent "kept covering up bugs and issues by creating fake data, fake reports, and worse of all, lying about our unit test" (The Register).

That one story has the whole pattern: something went wrong, then the report hid it.

What a diff review catches and what it misses#

Start with diff review. It catches a deleted test file, a skip decorator, a loosened assertion and a new --no-verify in a script.

It misses more than people expect:

• Volume. People approve most of what they're shown. In Anthropic's study of 1,053 testers, humans caught 13.6% of dangerous commands, and Anthropic reports that people approve 93% of permission prompts.
• Things that aren't in the diff. A command that ran but changed no files, a test run that never happened, or a summary saying the full suite passed when the agent ran one file.
• Context. Deleting a test can be a clean refactor in one session and a cover-up in another, and the two diffs look the same.

Why the agent's summary can't be the record#

Only the agent knows everything it did, and the agent writes the report. Once sessions run for hours, nobody reads every step, so the summary ends up serving as the audit trail.

That means the thing being graded also writes the grade. Keep the record somewhere the agent can't edit.

A checklist you can use this week#

• Protect test and CI config. Put tests, CI workflows, lint config, coverage thresholds and agent rules files behind CODEOWNERS and branch protection. Where you can, make them read-only to the agent.
• Trust CI over the claim. Before merge, require the pipeline to run on a clean checkout. A green result from the agent's own shell doesn't count.
• Block the escape hatches. Reject changes that add skips, lower coverage thresholds or turn off a CI step unless a human owner signs off.
• Compare the claim with the record. For every agent PR, check each "I ran X" in the summary against shell history, CI logs or recorded commands. A mismatch is your signal.
• Pin the verification command. Define the exact test command in CI, not in the prompt, so the agent can't redefine "passing."

Claude Code hooks can enforce part of this on the laptop. A PreToolUse hook runs "before a tool call executes" and "can block it" (Claude Code docs). For how hooks compare with permission rules and sandboxing, see this guide.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. It checks every command, file edit and push against the session's intent before it runs, and it makes those decisions locally in milliseconds. It starts in watch-only mode, so you can see what your agents do before you enforce anything.

Whether a test change is tampering depends on context. A local model reviews each action against the session for 19 risk categories, including test and verification tampering and security regressions in code. It can only make a verdict stricter, never weaker. Every decision is recorded, which gives you a record the agent didn't write.

Harden has limits. It's a layer, not a perimeter. It doesn't replace CI, code owners or review, and it can't stop an agent from writing a false sentence in its summary.