Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
How can you detect AI-generated code?
Updated
Reliable detection uses provenance and telemetry you control — commit markers, tool logs, IDE attribution. Statistical classifiers are probabilistic and carry false positives and false negatives. This page is not legal advice.
AI code detection, last verified 10 September 2026 against SLSA and in-toto provenance specifications, GitHub commit and co-author metadata documentation, NIST SP 800-218 provenance practices, and peer-reviewed detection-accuracy papers with methodology stated. It is not legal advice and does not endorse any detector.
Two different questions — provenance versus guessing authorship
Audience: an engineering leader setting policy on AI-assisted development. This page is not legal advice. It does not recommend punitive enforcement based on statistical detectors alone.
Teams ask how to detect AI-generated code for governance, review load, and risk sizing. There are two distinct approaches. Provenance and telemetry record that a tool or human attests AI involvement at commit time — reliable when YOUR pipeline enforces it, useless when developers omit markers. Statistical detection estimates authorship from code style, entropy, or model classifiers — always probabilistic, with false positives (human code flagged as AI) and false negatives (AI code flagged as human).
Do not treat classifier output as grounds for discipline or security decisions without human review of errors. NIST SSDF and SLSA emphasise artifact provenance and build attestations for supply-chain integrity — a stronger foundation than post-hoc authorship guessing. Last verified 10 September 2026. Not legal advice.
- Legal requirement versus guidance versus best practice versus SRM recommendation: SLSA and in-toto are industry specifications for provenance — adopt through YOUR CI policy. GitHub co-authored-by and commit metadata are platform features — best practice to use them consistently. Academic classifiers are research tools with reported accuracy below 100 percent on stated test sets. ShipReady AI-authored-code floor and per-committer metering are provenance and telemetry signals — not a classifier.
- The measure-human-vs-ai-generated-code guide on this site defines denominators for share metrics. The is-ai-generated-code-secure guide on this site covers risk. The review-agent-generated-pull-requests guide on this site covers review depth.
Approaches compared
The table summarises detection families. No approach offers certainty for every line in every repository.
| Approach | Reliability | False positives / false negatives | Best use |
|---|---|---|---|
| Provenance and attestation — SLSA, in-toto, signed build metadata | High when enforced in CI; low when bypassed | FN when developers skip attestation; FP rare if metadata is truthful | Supply-chain and release integrity; link AI tool version to build |
| Commit and platform telemetry — co-authored-by, AI bot accounts, IDE export markers | High for marked commits; does not cover unmarked edits | FN when markers omitted or squashed away; FP if markers misapplied | Governance dashboards and review routing |
| Tool and API logs — Copilot, Cursor, agent session IDs | High for sessions the tool logs; vendor-dependent retention | FN for offline or alternate tools; privacy policy governs use | Policy compliance and licence metering |
| Heuristic and ML classifiers — stylometry, entropy, fine-tuned detectors | Probabilistic only | Published studies report non-zero FP and FN on their test corpora; rates vary by language, obfuscation, and human editing after generation | Research signals only — not sole enforcement input |
| Self-report and policy | Depends on culture | FN from non-reporting; FP from over-reporting | Pair with technical markers on high-risk paths |
Classifier accuracy — read the methodology
Peer-reviewed and preprint detection papers typically report accuracy, precision, recall, or F1 on fixed datasets — often GitHub samples or classroom submissions. Common caveats: training data age, single-language bias, short snippets versus full repos, adversarial editing by humans, and concept drift as models update.
A detector with 90 percent accuracy on a paper's test set still generates substantial errors at repository scale. Example arithmetic (illustrative, not a study): 10,000 commits classified at 90 percent accuracy implies on the order of 1,000 mislabels — unacceptable as the only input to HR or merge policy.
False positives harm developers whose legitimate code is mislabeled. False negatives let unreviewed AI changes bypass YOUR gates. Prefer provenance YOU control over black-box scores.
What provenance looks like in practice
Require AI-assisted commits to include a consistent marker — co-authored-by trailer, signed bot identity, or CI-generated attribution from an approved IDE plugin.
Store agent session identifiers in PR descriptions for autonomous coding agents.
Use branch protection to block merges from unmarked agent accounts on protected branches.
Retain build provenance per SLSA level YOUR programme targets — SLSA v1.0 specs describe increasing rigour.
Do not rely on squashed merge history alone; attribution may be lost — document YOUR squash policy.
What you need to do now
Policy and pipeline steps. Not legal advice.
- Choose provenance-first detection: mandated markers for approved AI tools.
- Disable punitive use of third-party classifiers unless legal and HR have reviewed error rates.
- Route marked AI PRs to the review-agent-generated-pull-requests playbook on this site.
- Measure share with explicit denominators — measure-human-vs-ai-generated-code guide.
- Audit quarterly for marker bypass and squashed attribution loss.
- Align per-committer metering with licence policy — distinct committers in a 90-day window, not authorship guessing.
Checklist
Detection programme readiness. Not a certification.
- Approved AI tools list includes required attribution format?
- Branch protection enforces bot and marker rules on main?
- You distinguish provenance signals from classifier scores in dashboards?
- False-positive handling process exists before enforcement?
- SLSA or in-toto provenance level documented for releases?
- Legal reviewed employee monitoring if logs are used for compliance?
Where this shows up in ShipReady Metrics
AI-authored-code floor in signed-in AI Code Readiness reporting counts git-marked or attributed AI commits. That is a provenance and telemetry signal — not a statistical classifier and not proof of every line's origin.
Per-committer metering in signed-in admin Committer Seats tracks distinct committers in a 90-day window for licence alignment — activity telemetry, not AI-authorship classification.
This product does not sell or operate a proprietary AI-code classifier that claims certain detection of AI-written code. It does not determine employee misconduct from authorship estimates.
Primary sources (last verified 10 September 2026)
SLSA specification (slsa.dev). in-toto attestation framework. GitHub documentation on commit trailers and co-authored commits. NIST SP 800-218 practices on provenance and SBOM. Peer-reviewed AI authorship detection papers — read each paper's dataset size, language coverage, and reported FP/FN before adoption. Not legal advice.
Frequently asked questions
Can we detect AI-generated code with 100 percent accuracy?
No. Provenance is reliable only when YOUR tools and developers record attribution honestly. Statistical classifiers are probabilistic and produce false positives and false negatives. No product or paper cited here claims perfect detection across all repos.
Should we buy an AI code detector for policy enforcement?
Use caution. If you use one, treat scores as advisory, measure FP/FN on YOUR codebase, and do not use scores alone for HR or security decisions. Provenance-first programmes are more defensible.
Does ShipReady Metrics classify code as AI-written?
No. It surfaces counts from git markers and attributed commits — provenance telemetry. Per-committer metering tracks committer activity, not classifier-based authorship inference.
What happens after squash merges?
Squash can remove per-commit trailers. If YOU squash, require AI attribution in the PR title, body, or release notes, or prohibit squash on agent branches.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.