An AI agent said the code was verified. The evidence said otherwise

Uncle open-source developer Brian released an attestation tool called Uncle to prevent automated coding setups from approving code that was modified after verification, as detailed in brian.biz's report. The project attaches verifiable cryptographic evidence directly to specific Git tree hashes across every step of an autonomous workflow. It addresses the recurring failure mode where an agent writes a patch, secures an automated review, and subsequently alters files before publication without repeating the verification checks.

This breakdown examines how Uncle records exit codes, isolates human approvals from delegated automation, and validates artifacts against Git trees prior to release. Engineering teams deploying autonomous coding runners and automated pull request agents can use these mechanisms to prevent silent drift between reviewed code and deployed commits.

01The agent is not the authority

Software development workflows frequently allow artificial intelligence agents to write implementations, execute test suites, review code, and report completion status back to developers. This setup permits an agent to declare its own output trustworthy based solely on the fact that it generated the artifacts. In multi-agent environments, adding a second reviewing model fails to resolve the issue when reviews remain unbound to a fixed commit state, because an agent can easily edit an additional file after another agent provides approval.

Brian developed Yahoo Mail anti-spam infrastructure managing billions of messages per month and holding six patents, noting that components cannot be allowed to evaluate their own trustworthiness. When autonomous systems report green dashboards, developers have no guarantee whether tests finished, ran correctly, or evaluated the final state of the repository. An automated model remains uniformly confident regardless of whether failures occurred.

02The change is the unit of trust

Uncle binds workflow evidence to an exact Git tree hash so cryptographic proofs apply exclusively to that snapshot. The driver runs all verification stages, tracks exit codes directly, and generates in-toto Statement schema v1 attestations rather than trusting agent-generated status files.

The driver assigns three distinct evaluation outcomes: pass, fail, or unavailable. A timed-out test run or an unexecuted suite is explicitly recorded as missing evidence rather than a successful check.

When executing uncle verify against a repository branch, the utility verifies the cryptographic signatures against .uncle/allowed_signers and inspects all pipeline artifacts. These records include adversarial reviews, project plans, requirements interpretations, and implementation states. If the tree hash currently in the working tree fails to match the audited artifact digest, verification immediately fails and informs the operator that the evidence describes different code.

03Gaps in traditional branch protection

Standard Git hosting platforms and pull request systems offer branch protection mechanisms that dismiss stale approvals and mandate status checks on incoming commits. However, pull request systems fail to capture automated tasks executed locally on a developer machine or runner prior to opening a pull request. An approval issued by a local language model does not count as a platform-level approval, leaving systems blind to file alterations made between agent steps.

Uncle bundles in-toto metadata alongside the commit so cryptographic verification occurs independently of continuous integration services. The tool inspects whether a human provided a sign-off or if an unattended agent approved a step on behalf of an operator. Hosting controls cannot distinguish between human actions and simulated sign-offs, creating blind spots for automated reviews.

04Failure cases in live repositories

Testing Uncle on real repository workflows demonstrated that the system flags missing human approvals and tree mismatches instead of returning synthetic green checks. In one demonstration on pull request 4, the verifier declined to mark the pull request as verified because the required adversarial review gate lacked human authorization. The run merged despite the failure, illustrating that the tool records unverified states rather than functioning as an unyielding blocking mechanism.

In a secondary failure case, the verifier detected valid SSH signatures while still rejecting the commit. The repository's head tree 5c05dfcf39d63d7d80016978fef9f09fddde72a6 differed from the release artifact digest 23c1f870a7f0070d520e1082310e36ae218fedaf. Uncle output the audit failure status NOT_READY, flagged an unattended review approval, and detailed the exact digest mismatch across three independent reasons.

05Defending against agent mistakes and limits

Uncle focuses on mitigating mistakes where an agent misinterprets command output, skips failures, or modifies files after an evaluation finishes. Because the driver operates as the external harness recording exit codes and hashes, unrecorded agent modifications appear as immediate verification failures. Hostile agents with unsandboxed shell access can alter state where the driver writes, requiring developers to run agents inside isolated sandboxes to retain integrity.

Cryptographic verification validates process compliance and artifact matching rather than functional program correctness. A pull request can fulfill every pipeline requirement and still harbor underlying design bugs or shared reasoning flaws across models. The software project is written primarily in Bash and Python and supports multiple runner environments across GitHub at github.com/unclehq/uncle.