How to Prove Which Commits an AI Agent Authored Through a Source-Control Model Context Protocol Server

Attribution is an evidence problem, not a labeling problem

When an agent commits through a source-control MCP server, the commit usually lands under a shared service account or a developer's credentials. The Git author and committer fields do not settle the question. They are values supplied by whoever creates the commit, and they can be set or rewritten by anyone with the ability to write history. Treating them as proof of authorship confuses a claim with evidence.

The useful distinction is between claims a commit makes about itself and evidence produced independently at the point of action. A claim can be accurate, but it cannot be verified without trusting its author. Evidence comes from a system the author does not control, such as a signature checked against a known key or a record written by an enforcement point when the tool call occurred.

This matches the direction of NIST guidance. SP 800-204D notes there is no guarantee that pulled code is the same software the developer authored and checked into the repository. It recommends verifying developer identity and authorization and enforcing developer signing of commits. NIST's concept paper on software and AI agent identity, still an active area of work as of November 2026, asks how agents can prove authority for a specific action, how they can log actions and intent in a tamper-proof way, and how to bind actions back to human authorization. Those are open questions, so design for them rather than assuming a settled standard.

Which attribution mechanisms are verifiable and which are self-asserted

No single mechanism is sufficient. The table sorts common signals by whether someone other than the committer can verify them, and by what each one still leaves open.

• Author and committer fields: Self-asserted. Anyone can set or rewrite them. Useful for display only.
• Co-authored-by trailer: Self-asserted text in the commit message. Researchers use it to identify the human behind agent pull requests, but it does not show that person requested or approved the change.
• Dedicated bot or agent identity: Supports a first-pass inventory by filtering commits on the bot login. Only as strong as control of its credential. A shared credential weakens attribution.
• Signed commits: Verifiable against a public key without trusting the author field. Strength depends on who holds the signing key and whether the platform enforces signing.
• Tool-call record held outside the repository: Independent evidence created at the point of action. Tamper resistance depends on where it is stored and how it is protected.
• Tool-call ID in a commit trailer: The trailer is a claim, but it becomes checkable when the signed commit carries it and the external record lists the same SHA.

Implementation: what to capture and how to bind it

Start with the evidence record. Capture fields that let a reviewer reconstruct who acted, under what rule and with whose authority. NIST's generative AI profile points to provenance records that include sources, timestamps, metadata and modifications, and the field list below applies that wording to commits. It is a design choice, not a prescribed schema.

Then bind the record to the repository. Give each agent its own identity and credential so that no human or other agent shares it, because authentication rests on possession and control of the authenticator. Enforce commit signing in the repository, and test how that enforcement behaves for commits created through your MCP server, since agent write paths often differ from developer workflows. Decide who holds the signing key. A key held inside the agent runtime proves less than one held by a separate signing component the agent cannot read.

Finally, write the tool-call record to storage outside the repository, with access controls and tamper-evident properties such as append-only writes or hash chaining. Where you use signatures or attestations, schedule verification of the records themselves, as NIST's draft generative AI profile recommends through cryptographic checks and formal audits.

• Record fields: Agent identity, human principal, tool name, arguments (redacted where needed), policy decision and version, approver, timestamp, repository, branch and resulting SHA.
• Distinct identities: One credential per agent, never shared with humans or other agents.
• Signing: Enforce signed commits and control the signing key outside the agent runtime.
• Trailer: Add the tool-call record ID to the commit message so the commit points to the record.
• Independent storage: Keep records outside the repository so history rewrites cannot change them.
• Verification: Periodically check signatures and record integrity, and sample commits end to end.

Where runtime policy enforcement fits

The tool-call boundary is also the right place to decide whether the write should happen at all. Trussed enforces policy in the execution path across MCP servers and coding assistants. For a commit or pull request tool call, the decision can be to allow, redact, block or escalate for human approval, and it is enforced at runtime, not reviewed after the fact. The scope is the individual interaction and tool call.

Because the decision is made in the path, the same step can produce the evidence the chain needs: the policy applied, the outcome and any approval. Trussed generates audit-ready evidence from that enforcement, alongside code provenance covering the origin, licence and security context of code. Self-managed deployment in the customer cloud, with configurable retention and data residency, lets teams hold that evidence outside the repository.

This addresses the human-principal weakness of trailers. A trailer naming a developer shows only that someone typed a name. An approval recorded when a tool call was escalated shows that a specific person authorized a specific action under a specific policy. You still need signed commits and distinct agent identities in the repository, because enforcement at the tool call does not replace them.