The reviewer ships with the author

Three of the most widely deployed AI coding platforms publish governance documentation. Read them next to each other and the same shape appears in all three. Nobody is hiding it. Each vendor sets it out plainly, and in at least one case recommends the workaround in the same paragraph as the limitation.

The shape is this. The platform supplies the mechanism. You supply the independence. Independence is the one thing that cannot be supplied from inside the process that needs to be independent of it.

What the audit logs cover

Cursor publishes the list. Enterprise audit logs record authentication events, user additions and removals, role changes, individual spend limits, API key creation and revocation, team settings, repository management, cloud agent environment lifecycle, directory group membership and permissions, privacy mode changes, team rules and integration authentication.

Those entries share a shape. Every one is an administrative act. Somebody was added, a limit was raised, a setting was flipped, a key was minted.

Cursor then states the position directly: “We do not log agent responses or generated code content.” The recommendation that follows is to use hooks. Write a script that fires when a prompt is submitted or when code is generated, and send whatever you need to your own compliance system.

GitHub says the same about Copilot in different words. The audit log carries plan changes, settings, policies, licences and agent activity on GitHub itself, with an actor_is_agent flag and a session identifier. It does not carry client session data such as the prompts a developer sends locally. GitHub’s documentation notes that reaching that data needs a custom solution, and offers the same example: hooks, sending events to a logging service you run.

Retention is the quiet half of this. Cursor’s Admin API holds audit events for thirty days, with streaming to a bucket you own as the route to anything longer. GitHub holds 180 days and recommends streaming to a SIEM. Neither window survives a regulatory look-back on its own.

The fair reading

Several things deserve saying before any criticism lands.

Changing a hook is itself an audited event. If someone removes the logging, the removal leaves a trace in the same log. That is a genuine control and it is more than several competitors offer.

The caution against writing raw prompts and generated code into a central compliance store is good security advice. Prompts carry secrets, customer data and unreleased plans. A vendor that pulled all of it into one log by default would deserve criticism of a different kind.

And naming your own gap in public documentation, next to the mechanism for closing it, is not the behaviour of a company hoping nobody looks. It is the opposite.

None of this is negligence. It is a set of defensible choices that add up to something worth noticing.

Where the record ends up living

Follow the hook recommendation and watch where the evidence settles.

You write the script. It runs on the developer machine, or in the same execution environment as the agent. It is configured, maintained and switched on by the engineering team whose output it exists to evidence. The destination is usually a system that same team administers.

Each of those is reasonable on its own. Together they describe a record produced by the process it is meant to hold to account.

A cottage industry has grown up in the gap. Open source hook loggers, tamper-evident local journals, hash-chained event files, several citing EU AI Act record-keeping obligations and ISO/IEC 42001 in their opening paragraph. The market has already priced this. That is a useful signal about whether the gap is real, and it does not change where the resulting record lives.

The newer move

Through 2026 the platforms stopped only writing the code and started reviewing it as well.

GitHub’s Copilot code review moved to an agentic architecture in March and now reads broader repository context before commenting, with team standards pulled from a skill file under .github/skills. Factory went further and shipped a dedicated security pass.

Factory’s announcement in June is worth reading properly, because it is easy to dismiss and should not be. On every non-draft pull request, Droid runs a STRIDE security review alongside the standard code review. Findings return with a severity, a CWE reference, an explanation and a suggested fix, posted inline on the diff. Coverage runs to OWASP Top 10, the OWASP LLM Top 10, and supply chain checks against dependency manifests and lockfiles. A two-pass pipeline generates candidate findings and then re-checks each one for reachability and exploitability before posting.

It works. CVE-2026-42876 in external-secrets was found this way, a template injection path that let an attacker with narrow permissions mint persistent service account tokens and impersonate any service account in the namespace. That went through responsible disclosure. There are others.

Capability is not the question here, and any argument that pretends otherwise is not worth making.

What the architecture puts in one place

The Droid that writes the code and the reviewer that inspects it are the same product, from the same vendor, in the same run.

Factory has thought about this more carefully than a quick reading suggests. Droid Action runs a dedicated security-reviewer subagent that loads the methodology before it reads any files. A security_model input exists specifically so the review can run on a different model from the implementation. Both are real architectural choices.

Two details still sit where they sit. The security_model input defaults to empty and falls back to the review model, so separation is available and off unless someone turns it on. And the threat model the review works against is read from .factory/threat-model.md, a file inside the repository under review, maintained by the team whose work is being reviewed.

The reviewer, the reviewed and the standard all live in the same place.

The detail that gives it away

Factory’s documentation shows how to run the deep audit on a schedule in CI. The workflow checks out the repository, installs the CLI, runs the mission across the whole codebase, and writes its output to a directory on the runner.

Then the docs tell you to add an upload step, with a ninety day retention, if you want the findings to outlive the job that produced them.

That is sensible engineering. It is also the whole governance question expressed in four lines of YAML. Without the extra step the runner exits and the security audit goes with it. The evidence is ephemeral by default and persists only because somebody remembered.

An audit trail of your settings is not an audit trail of your work.

This is the distance between a control that is documented and a control that works. The first is a state you can show an auditor. The second is a state you can point at changing an outcome. A team can hold a clean enterprise configuration, a complete audit log, a signed SOC 2 report and an automated security review on every pull request, and still have no independent evidence of what any agent wrote last month or what any review concluded about it.

A question already answered once

In January 2003 the SEC adopted rules implementing Title II of the Sarbanes-Oxley Act. Section 201 names nine non-audit services that impair a firm’s independence if it provides them to an audit client.

Two are directly on point. The rules stop an accountant auditing bookkeeping work performed by that accountant’s own firm. And they stop a firm designing and implementing a client’s information system and then auditing it, unless it is reasonable to conclude the results of that work will fall outside the audit.

The reasoning had nothing to do with competence. Nobody argued that Andersen’s auditors could not audit. The argument was that from outside the firm, a clean opinion and a comfortable one look identical, and a market cannot run on a distinction only insiders can make.

The profession is honest that this was partly about perception. Later research suggests the prohibited services may have damaged confidence in independence more than they damaged measured audit quality. That is worth carrying, because it is exactly the point. The rule was not written because self-review always produces worse findings. It was written because self-review cannot be shown to have produced good ones.

Accountancy settled this with a statute. Software delivery is settling it with a configuration default.

What the research says, and how much it says

There is a body of peer-reviewed work on what happens when the same model generates and evaluates.

Panickssery, Bowman and Feng, published at NeurIPS in 2024, define self-preference as an evaluator scoring its own outputs higher than others while human annotators judge them equal. They find that models including GPT-4 and Llama 2 can distinguish their own text from other models’ and from humans’ with non-trivial accuracy out of the box, that fine-tuning produces a linear correlation between that self-recognition and the strength of self-preference, and that the causal explanation survives the obvious confounders. They discuss the consequence directly: weaker oversight, amplified when a model is trained on signal it generated itself.

That is the finding people reach for. The honest position is that its cause is contested and the contest matters.

Wataoka, Takahashi and Ri propose a different explanation. Models rate low-perplexity text more highly than human evaluators do, whether or not they wrote it. On that account the effect is familiarity rather than authorship, and a model prefers its own output because its own output is by construction the most familiar text it will see. Later work goes further. One line of argument holds that existing measures conflate self-preference with genuinely better output from stronger models. Another attributes most of the measured effect to evaluator uncertainty on harder questions rather than to favouritism at all.

There is a second limit worth stating. All of this tests evaluation of text quality in dialogue and summarisation settings. None of it tests whether a model finds fewer injection paths in code it wrote than in code it did not. Treating the transfer as established would be doing exactly what this note criticises.

So the argument cannot rest on bias, and it does not need to.

If Wataoka is right and the effect is familiarity, pointing the review at a different model family is a real mitigation, which is a point in favour of vendors that let you do it. If the sceptics are right and most of the measured effect is an artefact, self-review may be perfectly competent. Neither outcome produces evidence. An assurance you cannot demonstrate is not assurance, whatever its quality, and the party best placed to know its quality is the party with the least standing to certify it.

What would close it

The mechanism is not more logging inside the editor, and it is not a better authoring tool. Detection at the point of authoring is necessary and it is not sufficient. Anything living inside the process that produces the work can be reconfigured by the people producing the work.

Enforcement belongs at the promotion gate. The moment a change moves from a branch to somewhere it matters is the moment something outside the authoring process has to read the record and decide.

Four properties make that record worth having.

• Produced outside the process that made the change, so the author is not also the record keeper.
• Bound to the artefact, so the specification, the run, the review and the diff cannot drift apart afterwards.
• Read at the gate by something the author cannot reconfigure, so the check happens whether or not anyone remembers the upload step.
• Absent counts as absent. A change arriving with no provenance record should not pass quietly on the grounds that nothing was flagged. Work that turns up without a record grades as absent rather than clean.

None of that requires a vendor to build anything differently. It requires the record to be read somewhere the authoring process does not reach.

The test

If you want to know where your own estate sits, do not audit the configuration. Pull last month’s log and try to reconstruct a single merge. Which agent, working from what stated intent, reviewed by what, on what basis, changed by whom, approved by whom.

Then ask the harder version. Could you do it without asking the team that shipped it?

The distance between what you can show and what you can prove is the whole problem.

Sources

Cursor compliance and monitoring documentation, verified 7 September 2026. GitHub documentation on reviewing audit logs for Copilot and on agentic audit log events, verified 7 September 2026. Factory’s automated security review announcement, 11 June 2026, and its security review documentation, verified 7 September 2026. Independent analysis of Cursor and Copilot audit logs by Monad, July 2026. SEC press release 2003-9 and the rules adopted under Title II of the Sarbanes-Oxley Act of 2002. Panickssery, Bowman and Feng, LLM Evaluators Recognize and Favor Their Own Generations, NeurIPS 2024. Wataoka, Takahashi and Ri, Self-Preference Bias in LLM-as-a-Judge, 2024, and subsequent work mapping the disagreement about its cause.

Monad sells telemetry collection in an adjacent category, which is worth weighing when reading its framing. Vendor announcements about vendor products are self-interested by construction and are treated here as accurate about what the product does and unreliable about what it settles.

This note describes published product documentation and published research. It is not an account of how any organisation operates internally.

Jason Cruz Falzon is the creator of the Cognitive Delivery Framework and the Cognitive Delivery Index. cognitivedelivery.co.uk | jason@cognitivedelivery.co.uk