[FEATURE] request: cryptographic attestation that a git commit (or other action) was taken by a Claude agent
Summary
There is currently no mechanism for Claude Code to sign git commits, and no safe place to store a signing key on a user's machine that Claude can use. Many GitHub organisations enforce required signed commits as a branch protection rule — meaning unsigned commits are simply rejected. This creates a hard blocker: Claude Code cannot commit to those repos at all without a signing key, and there is no tamper-proof way to give it one.
The right solution is for Anthropic to host a signing key on their servers and expose a signing endpoint that Claude Code can call on request — similar to how code-signing services work for software distribution. Claude would never hold the private key; Anthropic's infrastructure would sign on its behalf.
This is the converse of #79193 (which covers proving who is speaking to an agent). This request covers proving that an agent took a specific action in a way that external parties can verify.
Motivating scenario
A developer's GitHub organisation has "Require signed commits" enabled on all protected branches. They want Claude Code to commit and push directly — a core part of the agentic workflow. Currently they must choose between:
- Disable signed commits — weakens org security policy to unblock Claude
- Give Claude a GPG subkey stored on disk — the key is unprotected (no passphrase Claude can enter interactively), so any process running as that user can sign commits as them; there is no way to make the key tamper-proof or restrict it to Claude's process
- Have the user sign every commit manually — defeats the purpose of autonomous operation
None of these are acceptable for security-conscious teams. The root problem is that there is nowhere safe to store a signing key that Claude alone can use.
Why a local key cannot solve this
Giving Claude a local GPG or SSH key has an unavoidable catch: Claude runs as the same OS user as the developer. Any key Claude can read, the developer (and any other process running as that user) can also read. There is no OS-level isolation that makes a local key "Claude's key only." Even a hardware token (YubiKey) requires an interactive PIN that Claude cannot enter.
The only party that can hold a private key that Claude — and only Claude — can use is Anthropic, on their servers.
Proposed solution: Anthropic-hosted signing service
Anthropic hosts a signing key (GPG or SSH) and exposes a signing endpoint in the Claude Code API:
POST /v1/sign
{
"payload": "<base64 of the data to sign>",
"type": "git-commit"
}
→ { "signature": "<detached signature>", "key_id": "...", "timestamp": "..." }
Claude Code calls this endpoint when it needs to sign a commit. The private key never leaves Anthropic's infrastructure. The corresponding public key is published at a well-known URL (e.g. https://api.anthropic.com/.well-known/claude-code-signing-key.pub) so anyone — GitHub, a CI system, an auditor — can verify that the signature came from Anthropic's Claude Code service.
This would:
- Allow Claude Code to produce verifiable signed commits accepted by GitHub's "require signed commits" policy
- Give organisations cryptographic proof that a commit was made by a Claude agent, not a human impersonating one
- Work without the user storing any key locally or weakening their security policy
Additional verification benefits
Once Anthropic holds the signing key, each signature can also carry metadata:
- Model version (
claude-sonnet-4-6) - Session ID (linkable to API logs for audit)
- Timestamp
This turns the signature from a simple "Claude did this" into a full attestation record — useful for compliance, regression attribution, and AI-involvement disclosure requirements.
Related
- #79193 — harness-anchored trust for inbound messages to agents (different direction)
- #78787 — commit-signing keys empty in cloud environments (signing infrastructure gap)
Why this matters
As AI agents take more autonomous actions in codebases, the ability to audit "what did the human do vs. what did the AI do" becomes important for:
- Organisations with required signed commits policies — currently a hard blocker for Claude Code
- Security reviews and compliance
- Attribution of bugs or regressions
- Regulatory contexts where AI involvement must be disclosed
---
Filed by Claude Code on the operator's behalf, at their request.