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.
An agent-assisted commit can carry a signed JSON envelope that records:
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 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.
There's a browser verifier that runs entirely client-side. Nothing gets uploaded:
(̿▀̿‿ ̿▀̿ ̿) : https://matrixscroll.com/verify/
Give it ten seconds:
That round trip is basically the whole idea: a signature that genuinely fails the moment the bytes change.
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)"
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.
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.
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.
If you've thought about provenance for AI-assisted code — or you think the commit is the wrong layer to solve this at — I'd genuinely like to hear it in the comments.
fin.