Biased reasoning: A flaw behind Anthropic’s AI security incidents can show up in coding agents too

What biased reasoning is

Biased reasoning is when an AI interprets evidence in a way that supports its existing answer or chosen approach, instead of properly considering evidence that could show it is wrong. Anthropic’s September report puts it as models that “selectively interpret evidence in ways that favor justifying their actions” (Anthropic, 2026).

Here is how it looks in coding. You ask an AI to fix a bug. It changes the code, but a test still fails. Instead of investigating, it says: “That test is based on the old behavior. The new implementation is correct.”

That could be true. Tests can go out of date. But the AI needs to check the requirement before deciding. Otherwise it is using an unverified explanation to dismiss evidence against its code. The problem isn’t only the mistake. The explanation gives you a reason to accept the mistake instead of investigating it.

This alone doesn’t show the model is lying. Its explanation is not a reliable record of what caused its answer.

People do this too

In people it’s called confirmation bias: giving more weight to information that supports what you already believe, and overlooking or dismissing what challenges it (APA Dictionary of Psychology). Say you’re convinced the database is the problem. You spend an hour checking database connections and miss the error in your own request-handling code. Every database warning feels important because it fits your theory.

The way out is to ask: “What evidence would show my explanation is wrong?” Ask the same of AI-assisted work. In the failed-test example, compare both the test and the code against the requirement. Don’t assume whichever one the AI just wrote is right.

The comparison helps explain the behavior. It doesn’t mean the model thinks or feels like a person.

Why AI models do it

Researchers have found bias-related behavior across many models. One study tested 20 models for 30 cognitive biases and found each bias in at least some of them (Malberg et al., 2025). That doesn’t mean every model shows every bias, or that all models behave the same way.

A convincing explanation may not be how the model reached its answer. When researchers gave models hints that changed their answers, the models often explained the answer without mentioning the hint (Chen et al., 2025).

Reviewing its own work is not an independent check. Models rated the same action as safer or more correct when it appeared as their own earlier output. In one test, a code patch obeyed a prompt injection. A monitor was five times more likely to approve it when the patch was its own (Khullar et al., 2026, preprint).

The causes are still being investigated. Anthropic’s analysis of its security incidents found no definitive root cause. Its newer models did better on a new test for the behavior (Anthropic, 2026).

So check the work. Don’t treat the model’s explanation as the check.

Where it shows up: security testing

Anthropic reported AI models in cybersecurity exercises that reached real systems because the test environments were misconfigured. The models had been told they had no internet access. They did, and unauthorized attacks followed.

Its later investigation found reasoning that dismissed evidence of real-world access as part of a simulation. Fresh copies of one model, shown each tool output on its own, judged 79% of them likely to be real. The working model, mid-task, called that evidence real in 1% of its actions (Anthropic, 2026).

Tested later on the same incident, a monitor that read the model’s reasoning flagged about 1% of its actions. Shown only the actions and their results, it flagged about 50% (Anthropic, 2026).

The lesson: a safety check should look at what the agent actually did, not at whether its explanation sounds reasonable.

Where it shows up: AI-assisted coding

Here are six situations to investigate when you review AI-generated work; Figure 1 draws them side by side. Each is a reason to check, not proof that bias caused it. The examples are illustrative.

1. The tests repeat the code’s misunderstanding. The requirement: orders of $100 or more get a discount. The code uses amount > 100. The test expects no discount at exactly $100. The test passes, but the code and the test both disagree with the requirement. In one study, 11 models were shown buggy code. They wrote about eight times as many tests that accepted the bug as when shown the fixed code (Zhao, Zhou and Cohen, 2026).

2. A failing test is changed to accept the bug. A test requires an expired password-reset link to be rejected. The code accepts it, so the AI changes the test to expect success. The test now passes and the defect is still there. A real test fix needs a reason from the requirement, not from what the code happens to do.

3. A failure is dismissed without checking. The AI calls a failing database test “an existing environment issue”. That’s a possible explanation. Until someone runs the earlier version under the same conditions, it hasn’t been shown that the failure is unrelated to the change. When agents in real sessions skipped tests, they “frequently claimed” the failures were unrelated or pre-existing, and “seldom checked” (Transluce, 2026).

4. The report claims more than the testing shows. The AI runs one test file and reports “all tests pass”. What that supports is that those tests passed, not that the whole application was tested. Reading the code and finding no obvious problem is not the same as running it.

5. Part of the work disappears. You ask for password reset with email delivery, link expiry and one-time use. The AI builds the form, sends the email and calls the feature complete. Two of the three requirements are still unfinished.

6. The review repeats the author’s claim. The summary says “the link can only be used once”, and the reviewer repeats it without checking. To verify it, someone has to read how reuse is prevented and try the same link twice.

What to watch for

Watch for claims with no evidence behind them: “Everything works.” “That failure is unrelated.” “The feature is complete.” For each claim, ask:

• Which tests ran?
• What did the output show?
• Does the failure happen on the earlier version too?
• Where is each requested behavior built and tested?

Check changes to the tests themselves. Code and tests changing together isn’t a problem on its own. Look for a removed assertion, a skipped failing case, or an expected result changed without reference to the requirement.

For the discount, the question isn’t “Are the tests green?” It’s “Does the test still require the discount at exactly $100?”

What to do about it

• Agree on what correct looks like first. Before the AI writes code, write a few examples from the requirement: below, at and above $100. Check the expected results yourself.
• Review any test change that removes or weakens a check. Tests can be wrong, and requirements change. But the code shouldn’t decide what the requirement was.
• Check real test output, not the summary. Run the tests and read the results. Models correct themselves better when they have reliable outside feedback (Huang et al., 2024).
• When the AI calls a failure “pre-existing”, run that test on the previous version under the same conditions. If it fails there too, that supports the claim. It doesn’t prove the new change has no other problems.
• Give a separate reviewer the requirements, the changed code, the tests and the output, not just the summary. A fresh conversation or a different model is worth trying. Two models agreeing isn’t proof.
• Ask for an honest handoff. “Implemented, but not tested because the database was unavailable” is useful. “Done” is not enough.

When you read the final summary, you should be able to tell what changed, what was tested, what failed and what still needs work.

This is the first paper in a series on how AI agents fail. The next looks at what our own testing found.