Prove what the AI wrote
Auditors, acquirers, insurers and procurement teams have started asking which parts of a codebase were machine-generated, and whether anyone checked them. At most companies the honest answer today is “we don’t know.” kal produces that answer as a by-product of normal work.
The four questions nobody can answer
- Which parts of this release were written by a model, and which models were they?
- Can we prove it to someone who doesn’t trust us — an auditor, a regulator, a buyer?
- Which AI-authored changes were never verified by anyone?
- Is the record itself intact, or could it have been edited after the fact?
These are unanswerable in git — not because git is badly built, but because it was designed before the question existed. Its author field is one free-text string; an agent looks exactly like a colleague, and the model behind it is recorded nowhere. kal captures authorship as structured data at write time, so the report below is a statement of recorded fact, never a reconstruction.
One command, one artifact
$ kal attest v1.0 --key release.key ================================================================== AI-AUTHORSHIP ATTESTATION ================================================================== repository attest-demo revision f07b0b41170400fe tag v1.0 generated 2026-07-26 21:27:40 by kal 0.8.0 AUTHORSHIP snapshots 3 (1 human, 2 AI-authored) lines attributed 9 (2 human, 7 AI) AI-written share 77.78% BY MODEL claude-opus-5 4 lines 1 snaps 1 verified azmx-coder-v0.3 3 lines 1 snaps 0 verified VERIFICATION OF AI WORK AI snapshots 2 verified by tests 1 (50.0% coverage) human-approved 0 never verified 1 ! f07b0b411704 exponential backoff [azmx-coder-v0.3] INTEGRITY objects verified 9 (intact) digest sha256:d702e41d0bfd648cf0262460ba4304ca6e07cf1d62aa54400bcb4be8133c343b signed hmac-sha256 943a44e29085a4241435cb56aae3bfe4… ================================================================== Derived from provenance recorded at write time. Verify with: kal attest --verify <file> [--key <path>]
Every number is derived from data captured when the work happened: structured authorship on each snapshot, verification stamps from your own test command, and human approvals. Nothing is inferred after the fact, and nothing is estimated.
Tamper-evident, tested against the obvious attack
The report carries a SHA-256 digest over its own canonical form, and optionally an HMAC signature bound to a key you hold. Verification is one command:
$ kal attest --verify report.json --key release.key digest ok signature valid attestation is intact (attest-demo @ f07b0b411704)
Now suppose someone dislikes the number and edits the report to claim 12% AI-written instead:
$ kal attest --verify tampered.json # someone edited the AI share digest MISMATCH — report was altered signature INVALID ATTESTATION FAILED VERIFICATION
Both checks fail. And if that person is sophisticated enough to recompute the digest so it matches their edited figures, the digest check passes — but the signature still fails, because they don’t hold the key. That property is regression-tested in kal’s own suite.
What the signature does and doesn’t prove
Stated plainly, because a compliance tool that overstates itself is worse than none:
- HMAC is symmetric. A valid signature proves the report was produced by a holder of the key — not by a named person or company.
- For third-party-verifiable signing, take the printed digest and sign it with the infrastructure you already trust: cosign, openssl, a KMS, your existing release-signing key. The digest is stable and exists precisely for that hand-off.
- kal attests to what was recorded, not to reality. If an engineer commits agent-written code under their own identity with attribution switched off, no tool can catch that. The attestation is only as good as the discipline around it — which is why the trust ladder and CI integration matter more than the report itself.
Machine-readable for your pipeline
Use --json to feed dashboards, policy gates or evidence stores. Attach it to a
release, store it with the build artifacts, or fail CI when unverified AI work exceeds a threshold.
$ head -26 report.json { "type": "kal.attestation", "schema_version": 1, "kal_version": "0.8.0", "generated_at": 1785126461.015632, "repository": { "name": "attest-demo", "revision": "f07b0b41170400fe92a38cb4536732d14db77ee276d0c39a1273e769ed7c847e", "branch": "main", "tag": "v1.0" }, "scope": { "files_in_tree": 1, "files_attributed": 1, "files_skipped": 0 }, "authorship": { "commits": { "total": 3, "human": 1, "ai": 2 }, "lines": { "human": 2, "ai": 7, "attributed": 9,
Wire it into a release
# in your release job kal attest "$TAG" --json --key "$KAL_SIGNING_KEY" -o attestation.json kal attest --verify attestation.json --key "$KAL_SIGNING_KEY" # fails the build if altered # gate on unverified AI work python -c "import json,sys; r=json.load(open('attestation.json')); sys.exit(1 if r['verification']['unverified'] > 0 else 0)"
Agents can generate one too — kal_attest is exposed as an MCP tool, so a coding
agent can attest its own work before opening a pull request.
Who this is for
Regulated engineering
Finance, health, defence and public-sector suppliers facing AI-disclosure clauses in contracts and audits. The report is the evidence artifact those clauses ask for.
Diligence and M&A
Buyers increasingly ask what share of a codebase is machine-generated and whether it was reviewed. “We don’t track that” is an answer that costs money in a negotiation.
Agent fleets
If autonomous agents commit to your repositories, this is the record of what they did and what was verified — per model, so you can also tell which ones you should keep paying for.
Contract and agency work
Prove to a client that delivery met their AI-usage terms — in either direction, whether they require disclosure or prohibit machine-generated code outright.
kal init and kal snap inside an existing git project, then
kal attest. Even with one snapshot you will see the shape of the artifact — and from
that point on the record builds itself.