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?
Last verifiedReliable 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.
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.