Who actually wrote that commit... you, or your AI agent?

The gap nobody's really tracking

Your Git history can tell you that a workstation pushed a commit. What it can't tell you is who or whatactually produced the change. Was it you? An AI agent running inside your IDE? A CI job? Some vendor tool you forgot you'd wired in?

For a long time that question was academic. It isn't anymore. The more code we write with AI in the loop, the shakier one quiet assumption gets: that there's a human author behind every commit. Audit trails, incident reviews, compliance workflows; they all lean on it. And it's breaking.

Matrix Scroll is a small, open attempt to fix that. It attaches a signed provenance envelope to a commit, and anyone can verify it offline.

What it actually does

An agent-assisted commit can carry a signed JSON envelope that records:

the actor (human or agent)
the tool that produced the change
an optional bounded scope
an Ed25519 signature over a canonicalized version of the manifest

The signing input is strict and frankly kind of boring — which is the entire point. It has to be reproducible byte-for-byte across implementations, so:

the top-level signature block is stripped before signing
object keys are sorted recursively
compact separators, ASCII escaping, UTF-8 bytes
no NaN, no Infinity

The device ID comes from the first eight uppercase hex characters of SHA-256(public_key), formatted as MS-XXXX-XXXX. Verifying is the easy part: take the canonical manifest bytes, check them against the embedded public key and signature. No central service in the middle.

Try it without installing anything

There's a browser verifier that runs entirely client-side. Nothing gets uploaded:

(̿▀̿‿ ̿▀̿ ̿) :    https://matrixscroll.com/verify/

Give it ten seconds:

Hit Load Commit Envelope → Verify Signature. You'll get VALID, plus the device ID, mode, algorithm, and canonical byte count.
Now hit Tamper Sample → Verify Signature again. It flips to INVALID and tells you exactly what broke — e.g. "Device ID mismatch: expected MS-4319-20D5, manifest says MS-TAMP-ERED".

That round trip is basically the whole idea: a signature that genuinely fails the moment the bytes change.

Adding it to a repo

pip install "matrixscroll==0.2.6"
matrixscroll hook-install
matrixscroll hook-status

Mark a commit as agent-produced:

export MATRIXSCROLL_ACTOR_TYPE=agent
export MATRIXSCROLL_TOOL=agent-runner
git commit -m "feat: agent change"
matrixscroll envelope-verify "$(git rev-parse HEAD)"
# ok: true / actor: agent / tool: agent-runner

Want to gate a pull request in CI? The GitHub Action ("Scroll Gate") verifies every commit in a PR range before merge:

- uses: SSX360/matrixscroll-verify-action@v1  with:
    matrixscroll-version: "0.2.6"
    require-mode: # ...

Hooks default to warn mode. Set "enforce": true in .git/matrixscroll/config.json if you want failed signing to actually block.

Where it fits (and where it doesn't)

This is the part I want to be straight about, because security tools earn trust by being precise about scope.

Matrix Scroll is commit-time provenance. It answers one narrow question: "who signed this commit before it merged?" That's not the same question the established supply-chain tools answer.

Tool	Layer	Signs commits?	Records AI/agent identity?
Matrix Scroll	Commit	Yes	Yes
Sigstore / cosign	Artifact	No	No
GitHub attestations	CI artifact	No	No
SLSA	Build framework	N/A	No

Sigstore, SLSA, and GitHub attestations secure build outputs — what came out of CI. They're good tools and Matrix Scroll doesn't replace any of them. It just sits one step earlier, on the commit itself.

And to be clear about what it isn't: it's not IAM, not sandboxing, not a prompt filter, not an agent runtime. It's the provenance layer. That's all.

Honest status

Here's where things actually stand.

Shipping now: PyPI 0.2.6, the Git hooks, the browser verifier, and PR-range verification via the GitHub Action.

In progress: hardware-backed signing on a dedicated secure element (SE050), external Ed25519 key backends, and transparency-log integration.

The default today uses software-emulated keys — an "L1" mode — meant for local dev, demos, and CI. Hardware-rooted keys are the next trust layer, not the thing I'm leading with.

So if your threat model includes a fully compromised local machine, the emulated path won't save you yet. That's exactly what the hardware work is for. I'd rather just say that than oversell it.

The protocol, JSON schemas, and conformance vectors are all open, so anyone can implement the format or pick it apart.