Attestix Signs Your AI Agent's Paperwork, Not the Law

An open-source EU AI Act toolkit for agents, and the gap between a tamper-evident log and a compliance verdict

An agent that can send email, move files and call APIs creates a question nobody used to ask about software: who did this, under whose authority, and can you prove the record was not edited afterwards? Attestix, a repo climbing GitHub's trending boards this week, answers the first two with signatures and the third with a hash chain. Then it goes a step further and tries to answer a fourth question, whether your agent complies with the EU AI Act.

The first three answers are solid engineering. The fourth is where the repo writes a legal rule into code, and the rule does not match the law as written.

What Attestix actually is

VibeTensor/attestix describes itself as "Compliance Automation for AI Agents." It is an Apache-2.0 Python package (copyright VibeTensor Inc.) with nine modules exposed as 47 MCP tools, so Claude or any MCP client can call them directly. It sat at #24 on Trendshift when I read the board at 15:10 ET on September 28, with 698 stars on a cache-busted shields.io read.

The modules split cleanly into two groups.

The identity and evidence group is built on standards you can check yourself. Agents get W3C Decentralized Identifiers (DID Core 1.0). Credentials follow the W3C Verifiable Credentials Data Model 1.1 with Ed25519 signatures (RFC 8032). Delegation uses UCAN v0.9.0 style capability tokens, so one agent can hand another a scoped permission and the chain of authority stays verifiable. A Provenance module records training data, model lineage and actions in a SHA-256 hash-chained audit log stored as local JSON. An optional Blockchain module can anchor hashes to Base, an Ethereum layer 2, through the Ethereum Attestation Service.

The compliance group maps that evidence onto the EU AI Act. The README claims coverage of Article 10 (training data governance), Article 11 (technical documentation), Article 12 (record keeping), Article 43 (conformity assessment) and Annex V (the declaration of conformity), and it can generate that declaration as a signed credential.

Getting started is short:

pip install attestix
attestix init --name MyBot
attestix compliance <agent-id>

The part that works: a log you can trust

Most agent logs are text files an agent could rewrite. The Attestix audit trail links each entry to the previous one with SHA-256, so changing any entry breaks every hash after it. The README is careful to call this tamper-evident, not tamper-proof. It tells you an edit happened. It does not stop one. Anchoring batches on chain is the optional step that makes silent rewriting expensive.

That distinction is exactly right, and it is why I think the evidence half of this repo deserves attention. When an agent does something expensive or embarrassing, the first hour goes to reconstructing what it did and who told it to. A signed identity for the agent, a delegation token showing which human granted which scope, and a hash-chained record of actions answer those questions faster than any dashboard.

The delegation piece matters most for multi-agent setups. When an orchestrator spins up sub-agents, the question "who authorized this sub-agent to touch the billing API" usually has no answer at all. UCAN-style tokens make the answer a verifiable chain rather than a guess.

The part that overreaches: a legal rule in code

Here is the line that made me stop. The README walks through recording a conformity assessment with record_conformity_assessment() and says the function refuses self-assessment for high-risk systems, with the error "High-risk AI systems require third_party conformity assessment."

The AI Act does not say that for most high-risk systems. Article 43(2) says providers of the high-risk systems listed in Annex III points 2 to 8 (employment, education, essential services, law enforcement, migration, justice and similar uses) "shall follow the conformity assessment procedure based on internal control as referred to in Annex VI, which does not provide for the involvement of a notified body." Only point 1, biometrics, has an optional path that brings in a notified body, and even there internal control remains available when harmonised standards are applied.

So a tool that forces third-party assessment on every high-risk system is stricter than the Act for most of the systems people would run it on. Stricter sounds safe. In practice it tells a team building a hiring-screen agent that it needs an outside assessor the law does not require, or it trains them to route around the check. Either way the code is making a legal call, and a README that also says the tool "does not replace legal counsel, notified body assessments, or official regulatory submissions" should not be doing that.

I read this as a design choice rather than carelessness, and the maintainer may have a reason I did not find. But it is the clearest example I have seen of the risk in compliance-as-code. Once a rule lives in a function, people stop checking whether the rule is right.

Why the timing is better than it looks

If you are worried you are late, the calendar helps. The EU's Digital Omnibus, reported by Orrick on July 29, 2026 as published in the Official Journal, moved the Annex III high-risk obligations from August 2, 2026 to December 2, 2027, and Annex I product-embedded systems to August 2, 2028, according to Orrick's summary.

That leaves more than a year to get record keeping right before the high-risk rules bite, which is the part of Attestix I would adopt now. A year of clean, signed, hash-chained agent logs is worth more on the day of an audit than a declaration generated the week before.

Put this into practice

Start with the half of the repo that makes no legal claims.

Install it in a throwaway environment first. pip install attestix, then attestix init --name for one agent. See what the identity and credential look like before you wire anything into production.
Log one agent's actions for a week. Route a single agent's tool calls through the audit log and try to tamper with an entry. Confirm the chain breaks the way the README says.
Add delegation for one sub-agent. If you run an orchestrator, issue a scoped token for one sub-agent and check that the permission chain reads back correctly.
Skip the compliance verdict. Generate the profile if you want the documentation scaffold, but treat the risk classification and any declaration as a draft for your counsel, not an answer.
Decide on anchoring later. On-chain anchoring is optional and adds a dependency on Base and the Ethereum Attestation Service. Local tamper evidence is enough to start.

Honest limitations

This is a small, young project, and its own documentation says so.

Single maintainer. The README describes it as a single-maintainer project that welcomes community contributions. For something you might present to a regulator, bus factor matters.
No third-party security audit. The README says none has been done and advises the same diligence as "any pre-1.0 open-source crypto stack." A signing library you rely on for evidence should get that audit eventually.
The numbers do not agree with each other. The README reports 531 tests (440 functional plus 91 conformance). The v0.4.1 release notes report 585. The README's own status line still reads v0.4.0 stable. Neither count is wrong on its face, but a compliance tool with inconsistent self-reporting invites the question of which document is current. Its performance figures, like Ed25519 signing in about 0.28 milliseconds, are self-reported too.
The last stable release is three months old. v0.4.1 shipped in late June 2026 (June 23 on the release feed, June 24 in the changelog) with ML-DSA plus Ed25519 hybrid signing, and nothing newer has shipped since. The trending spike is attention, not new code.
Tamper-evident is not tamper-proof. Without anchoring, anyone with write access to the JSON can rebuild the whole chain from scratch. The hash chain proves internal consistency, not that the log is the original.
The Article 43 rule. As covered above, the self-assessment block does not match Article 43(2) for Annex III points 2 to 8. I am not a lawyer, and this is not legal advice. Check any classification with someone who is.

Where to take it from here

The useful idea in Attestix is that an agent should carry proof of who it is, who let it act, and what it did, in formats other systems can verify without trusting the agent. That idea will outlast this repo, and the standards it chose (DIDs, verifiable credentials, UCAN, Ed25519) are the right ones to learn.

The compliance layer is a reminder of what code should not decide on its own. Use Attestix to build the record. Keep a person in charge of what the record means.

Sources: VibeTensor/attestix README · attestix releases · EU AI Act Article 43 · Orrick on the Digital Omnibus

Medium metadata

Title: Attestix Signs Your AI Agent's Paperwork, Not the Law
Subtitle: An open-source EU AI Act toolkit for agents, and the gap between a tamper-evident log and a compliance verdict
Tags: AI Agents, EU AI Act, MCP, Open Source, AI Governance
Canonical: import from the fervorai.dev URL
Reading time: about 8 minutes