Provenance Guard: The Accountability Engine

Inspiration

Since coding agents went mainstream, maintainers have been buried under pull requests that pass CI and look clean but were never actually understood by the person who opened them. This isn't a guess. A contributor pushed a 13,000 line AI generated PR to the OCaml compiler and admitted he wrote none of it. Godot maintainers have called AI slop PRs draining and demoralizing. A Voiceflow infrastructure lead estimated only 1 in 10 AI generated PRs he receives are legitimate enough to meet contribution standards. GitHub is reportedly looking at PR rate limits just to cope with the volume. Linters, CI, and bots like CodeRabbit already check whether code is good. Nobody checks whether the person who opened the PR actually understands it. That gap is what we built for.

What it does

Provenance Guard sits between an opened pull request and a maintainer's review queue. When a PR lands, it checks out the branch into a short lived local workspace and runs Codex CLI in headless mode against the real repository, not just the diff, so it can flag lines that break existing conventions or introduce risk.

Those flagged lines open a live Verification Terminal for the PR author. Their diff sits on one side, a chat panel sits on the other, and our Auditor persona asks a specific question about a specific line. When the author answers, Auditor immediately asks an unpredictable follow up based on that exact answer. Nothing in the follow up is scripted ahead of time.

While this happens, the terminal quietly captures whether the answer arrived as natural typing or a single pasted block, how long it took, and whether the reasoning holds together across rounds. None of these signals counts as proof by itself. They combine into a weighted score, and a maintainer dashboard lists every PR by risk tier with a one line diagnosis and a full transcript replay, so review time goes to the PRs that actually need a human's attention.

How we built it

The design started from a simple question, if a reviewer asks a PR author to explain their own diff, how would someone fake a good answer. The same repository context our agent uses to write a question is available to the submitter's own AI tool, so a single written answer, no matter how specific it sounds, can't be trusted on its own. That's why Auditor never works from a fixed set of questions. Every follow up is generated live from what the author just said, which means faking it requires a fresh trip through an external AI tool for every single round, and that adds delay, awkward timing, and inconsistency we can actually detect.

On the technical side, a GitHub App listens for pull_request events over webhook. On trigger, we check out the PR branch into an ephemeral local directory and run Codex CLI headless (codex exec), authenticated through ChatGPT sign in rather than a metered API key, parsing its structured JSON event stream for flagged lines and risk rationale. That gets handed to the Challenge Engine, which runs through the AIML API so the underlying model is configurable rather than hard coded. The Verification Terminal is a split pane web interface built to capture keystroke timing and paste detection alongside the actual transcript. Everything lands in a scoring engine that never lets a single signal produce a high risk verdict on its own, and a dashboard that replays the whole exchange rather than showing a black box number.

Challenges we ran into

The hardest part was designing the Challenge logic so it couldn't be defeated by simply relaying our own questions into another AI tool. We spent real time thinking through that failure mode before writing a line of the challenge logic, because a demo that looks clever but doesn't survive an obvious workaround isn't actually solved. That's what pushed us toward multi round, unpredictable follow ups instead of a single static question.

The second challenge was making the verification process feel like something worth watching in a three minute video instead of a quiet backend job running somewhere out of sight. That's why the Verification Terminal exists as a live, visible exchange with a persona instead of a static bot comment buried in a PR thread.

Keeping Codex's local repository checkout genuinely ephemeral was also something we had to get right rather than assume. The Analysis Engine briefly holds real source code on disk to let Codex explore it properly, and we made sure that checkout gets deleted immediately after analysis completes, since that's a different trust boundary than a pure remote API call with no code residency at all.

Accomplishments that we're proud of

We're proud that we didn't ship the naive version of this idea. It would have been easy to demo a single question and answer bot and call it done. Instead we designed specifically against the most obvious way to game it, building the follow up logic and behavioral signals to close that hole before it ever became a problem.

We're also proud of being upfront about what this doesn't do. It cannot prove human authorship with certainty. A patient enough person who slows down and actually studies the code before answering could still pass, and we accept that, because the target is high volume low effort slop, not a determined individual working against us. Timing and stylometric signals are treated as probabilistic hints, never as a pass or fail gate by themselves. Stating that clearly, instead of quietly assuming a text answer equals proof, felt like the more honest engineering decision.

What we learned

We learned that an adversarial mindset has to shape the architecture from the start, not get bolted on after the demo works. The moment we asked "what would someone with the same tools we're using do to beat this," the whole design changed, and it changed for the better. We also learned how much a visible, personified interaction changes the experience of a verification step. The same underlying logic feels completely different to a submitter and to a judge watching a video when it's a live transcript with a persona instead of a bot comment that just posts a score.

What's next for Provenance Guard: The Accountability Engine

Next we want to take this from a single demo repository to something teams can actually deploy at scale. That means self hosted options for companies that need to keep code on their own infrastructure, proper SSO for logging in, audit logs for compliance review, and support for multiple organizations and repositories under one deployment instead of just one.