All posts

How to Prove Which Code Your AI Agents Wrote

The techniques and evidence auditors accept to attribute code to Copilot, Cursor, or Claude Code, plus a practical checklist.

To prove which code your AI agents wrote, you need attribution captured at the moment of the change and stored in a tamper-evident log, not reconstructed after the fact. The strongest evidence combines git signals (commit trailers, authorship metadata), a CLI or git hook that detects the active agent, and a hash-chained audit trail an auditor can verify. Guessing from code style doesn't hold up; a durable record captured at commit time does.

"Which AI wrote this code?" is the question auditors, security reviewers, and regulators now ask first. Here's why it's hard, the techniques that actually work, and exactly what evidence to produce.

Why does AI code attribution matter?

Attribution is the foundation of every other AI governance control. Without it, you can't answer basic accountability questions:

• Compliance, SOC 2, ISO/IEC 42001, and India's DPDP Act (core obligations phasing in to 13 May 2027) expect logging and human oversight of AI systems. You can't evidence oversight of agent-written code you can't identify.
• Security reviews, enterprise buyers increasingly ask, "How is your AI-generated code governed?" A prospect with no way to attribute AI code has no answer, and the deal stalls.
• Incident response, when a change breaks production, tracing it back to the agent and commit that caused it turns a multi-hour outage hunt into a targeted fix.
• Trust, attribution isn't surveillance of developers; it's a record of what the agents did, so humans stay accountable for code they can't manually review line by line.

Can you tell AI-generated code just by looking at it?

No, and this is the most common misconception. AI-detection heuristics that guess from code style, comment density, or "it looks too clean" are unreliable. Modern agents adapt to your codebase conventions, and human developers write clean code too. Style-based detection produces false positives you can't defend to an auditor.

Reliable attribution doesn't infer after the fact. It captures the fact at the moment the code is written, from the environment where the agent runs. That's the difference between a guess and evidence.

The techniques that actually work

1. Git signals: commit trailers and authorship

Git already carries attribution signals if you use them deliberately:

• Co-Authored-By trailers, many agents and workflows append a trailer like Co-Authored-By: Claude <...> to the commit message. It's a lightweight, native marker of agent involvement.
• Author vs. committer metadata, git distinguishes the author from the committer; agent-driven commits can be tagged so the two carry different, identifiable signals.
• Signed commits, cryptographic signatures tie a commit to a verified identity, raising the bar on tamper resistance.

Git signals are a good first layer, but they're advisory and editable: anyone can add or strip a trailer. They prove involvement when present; they don't prove absence, and they aren't tamper-evident on their own.

2. CLI and git hooks: capture at the source

The most reliable attribution comes from capturing the event where it happens, on the developer's machine, at commit time. A lightweight CLI with git hooks (pre-commit, post-commit) can detect which agent session is active, Claude Code, Cursor, or Copilot, and record the action as it happens, including what changed and whether it touched a sensitive path. Because it captures in real time rather than inferring later, the record reflects what actually occurred.

This is how Pramana captures attribution: a CLI and git hooks detect the active agent and post each action to an audit trail, with an offline queue so nothing is lost when a developer is disconnected.

3. Repo-side webhooks: the backstop

Client-side capture can be bypassed if someone commits outside the tooling. A server-side layer, GitHub or GitLab webhooks plus a nightly backfill, normalizes what actually reached the remote, so the audit trail reflects reality even when the CLI wasn't used. Client capture gives you rich, real-time signal; the webhook backstop gives you completeness.

4. Tamper-evident logging: making it evidence

Attribution is only as trustworthy as the log that holds it. If an insider can quietly edit the record, it isn't evidence. A hash-chained audit trail, where each entry cryptographically references the previous one, makes any alteration detectable, because changing one record breaks the chain. This is what separates a real audit trail from a database table anyone with access can rewrite.

Which capture method should you use?

The robust answer is not one technique but a layered one: CLI capture for granularity, webhooks for completeness, git trailers as corroborating signal, all written to a tamper-evident log.

What evidence do auditors actually ask for?

When an auditor evaluates AI code governance, they're looking for a specific set of artifacts. Have these ready:

• An agent-attributed event log, each code action tied to a specific agent or a human, with a timestamp.
• Proof of tamper resistance, evidence the log is hash-chained or otherwise verifiable, so it can't be edited after the fact.
• Risk flags with review status, records that risky actions (direct push to main, large diffs, sensitive-path changes) were flagged and either reviewed, approved, or dismissed.
• Control mapping, events tied to the framework control they satisfy (SOC 2, ISO 42001, DPDP).
• On-demand export, the ability to regenerate an evidence pack for any repo and date range, not a manually assembled spreadsheet.

A practical AI code attribution checklist

Use this to assess whether you can actually prove which code your AI wrote:

• Every commit carries an attribution signal (trailer, metadata, or captured event).
• You can distinguish human-written from agent-written changes.
• You can identify which agent, Claude Code, Cursor, Copilot.
• Attribution is captured at commit time, not inferred later from code style.
• Client-side capture is backed by a server-side webhook backstop.
• The audit log is tamper-evident (hash-chained or cryptographically verifiable).
• Risky agent actions are automatically flagged for human review.
• You can export an auditor-ready evidence pack on demand.
• Developers see only their own activity, attribution, not surveillance.

If you can check every box, you can walk into a security review or certification with a defensible answer. If you can't, the gaps are exactly where an auditor will push.

FAQ

How do I track AI-generated code in git?

Capture attribution at commit time with a CLI and git hooks that detect the active agent, corroborate with Co-Authored-By trailers, and back it up with repo webhooks. Store everything in a tamper-evident log so the record holds up.

Can I detect which AI wrote code just from its style?

No. Style-based detection is unreliable and produces false positives auditors won't accept. Reliable attribution captures the fact when the code is written, from the environment where the agent runs, it doesn't guess afterward.

What is a tamper-evident audit log?

A log where each entry cryptographically references the previous one (a hash chain), so altering any record breaks the chain and becomes detectable. It turns a plain database of events into defensible evidence.

What evidence do auditors want for AI-generated code?

An agent-attributed event log, proof it's tamper-evident, risk flags with review status, mapping to framework controls, and the ability to export an evidence pack on demand for any repo and date range.

Is AI code attribution the same as monitoring my developers?

No. Good attribution records what the agents did and gives developers visibility into only their own activity. It's an accountability record for AI actions, not a surveillance feed.

---

Want to see agent attribution on your own repos? Pramana turns AI-agent activity into audit-ready evidence, explore the Hunaru suite or book a demo.