Attestix: signed identity and evidence for AI agents

Identity, credentials and a verifier for every language you might ask

Attestix is a toolkit for what the project calls signed identity and evidence for AI agents. The manifest describes it in full: DID-based identity, W3C Verifiable Credentials, governance evidence, delegation chains, and reputation scoring. The README adds MCP and REST interfaces, automated functional tests, interoperability benchmarks, and real integrations with LangChain, the OpenAI Agents SDK and CrewAI.

The scope is deliberately narrow in one respect and wide in another. It is not a general identity provider and it is not an agent framework. What it offers is a way for an agent to hold credentials, to delegate authority down a chain, and to produce evidence that somebody else can check later, without trusting the machine that produced it.

The multi-language angle is the part that distinguishes it from a Python library with a client SDK. Attestix credentials use a published canonical-JSON and Ed25519 verification profile, and there are separate verifier repositories for JavaScript and TypeScript, Go, Rust, Java and R. The README is careful about what that means: the language-specific verifier repositories share conformance fixtures, but their trust-input and delegation-chain checks differ, so each verifier README has to be read and a reviewed version pinned. It states the separation plainly: cryptographic validity is separate from issuer trust, authorization, revocation and replay policy.

That is the correct way to build a verification layer, and it is also a warning that a valid signature is the weakest part of the chain rather than the whole of it.

The install pins a version, because the source and the registry differ

The install section is short and the comment above it is the important part:

# Reviewed release (check release notes before upgrading):
pip install attestix==0.4.2

An exact pin, with a note to check the release notes first. The reason is in the source and verification status section: published runtime hardening is available in Python attestix 0.4.2 on PyPI, the source tree also prepares the 0.4.3 website and documentation update, and source metadata is not proof of registry publication. The manifest version in the repository is 0.4.3, but the runtime baseline you can install today is 0.4.2.

The same section covers the other ecosystems, and it is worth reading the status column rather than the install command. JavaScript and TypeScript get the offline verifier as npm attestix 0.4.2. Go and Java are published at 0.4.2. Rust and R have GitHub 0.4.2 releases, while CRAN and crates.io still serve 0.4.1 at the release cutoff. So the same logical version exists in several places at once, and two of them lag.

One more migration is scheduled and dated. Since 0.4.0 the supported namespace is the canonical attestix.* namespace. The older flat layout, with imports like from services... import, keeps working through thin deprecation shims that emit a DeprecationWarning on first import, and those shims are scheduled for removal in v0.5.0. The README asks you to update imports to from attestix.services... import at your earliest convenience, and that request has a deadline attached.

Six CLI commands, and what each one actually asserts

The command line is the quickest way to see the model's shape:

attestix status                          # System overview
attestix init --name MyBot               # Create agent identity
attestix compliance <agent-id>           # Check recorded documentation gaps
attestix verify <agent-id>               # Verify identity cryptographically
attestix audit <agent-id>                # View hash-chained audit trail
attestix credential --list               # List W3C Verifiable Credentials

The first line of the list is where the value is, and the wording in the comments is precise. compliance does not check compliance. It checks recorded documentation gaps, and the source and verification status section spells out why the distinction matters: workflow_complete describes recorded documentation completion, legal_conformity is not assessed, and the deprecated compliant field is a workflow alias. Generated declarations are drafts for provider review.

That is a defensible design rather than a hedge. A tool that produced a green compliance badge for an agent would be misleading; a tool that tells you which required documents are missing and produces a draft declaration for a human to review is honest about where it sits in the process. The cost is that the output of compliance cannot be quoted as a conformity claim, and anyone writing policy on top of this has to accept that.

verify and audit are the cryptographic half. verify checks an identity cryptographically, and audit shows a hash-chained audit trail, which is the standard way to make a local log tamper-evident.

REST, the dashboard, and a single-tenant server by default

Three more entry points are documented. The API needs an extra and a key:

pip install 'attestix[api]'
# Configure ATTESTIX_API_KEY in your environment before starting the API.
uvicorn attestix.api.main:app --reload   # Swagger docs at http://localhost:8000/docs

The dashboard is a Streamlit app:

pip install streamlit
streamlit run demo/webapp/app.py         # Opens at http://localhost:8501

And the quick demo is a single script:

python examples/quickstart.py            # Local synthetic workflow

The REST caveats are specific and worth reading before you expose the server. REST use requires an API key by default. The default REST server is single-tenant and rejects non-default tenant headers, and a shared API key does not provide cross-tenant authorization. That is three separate statements, and together they mean the default configuration is safe for one tenant and offers no isolation between tenants beyond a header check. If you need multiple tenants on one deployment, that is configuration work the README does not document as solved.

The local storage story has a matching warning. JSON updates use the shared storage lock, and the README tells you to protect the local signing key and data directory and to test backup restoration, isolation and your selected signer or backend before production. The local purge is where the honesty is sharpest: a local purge cannot erase external replicas, remote logs, previously shared credentials or third-party backups, and the README says to plan historical data and credential migration separately.

Replay protection and issuer binding are the parts to check first

Two lines from the source and verification status section describe the security properties most systems get wrong, and they are worth repeating because they are stated as facts about the tool rather than as aspirations.

The first: presentation verification requires the caller's expected challenge and domain, and a signature alone does not provide replay protection. A signed credential that a verifier will accept from anyone, at any time, in any context, is a bearer token with extra steps. Requiring the caller to supply the expected challenge and the domain means a presentation captured in one context does not validate in another.

The second: credential verification binds the stated issuer to the supported proof controller, and ambiguous NFC-normalized keys fail before signing or verification. The failure is deliberately early, at the point of signing or verifying rather than afterwards, which is the right place for a check that is about key identity.

The verifier table adds a third distinction that most implementations blur. The credential formats follow a published canonical-JSON profile, and every verifier targets it, but the profile differs from strict W3C handling, and the verifiers share fixtures while differing in trust-input and delegation-chain checks. A delegation chain, meaning an agent acting on behalf of another agent, is exactly where a cross-language implementation is most likely to disagree with its siblings. The practical advice in the README is to read each verifier README and pin a reviewed version, which is also the reason the table lists a separate verifier source repository for every language.

Dependency floors tied to advisories, and a digest-pinned image

The dependency policy is unusual enough to be worth reading closely. The requirements file pins both ends of every range, and the comments explain why in the same lines:

mcp[cli]>=1.28.1,<2.0.0
cryptography>=50.0.0,<51.0.0
PyJWT[crypto]>=2.15.0,<3.0.0
anyio>=4.14.2,<5.0.0
base58>=2.1.1
httpx>=0.28.0

The manifest comment says runtime dependencies are pinned with both lower and upper bounds to prevent silent breakage from major-version drift on a fresh install, and the requirements comments name the advisories that set the floors: a cryptography floor that closes a name-constraints bypass and an earlier related advisory, and a PyJWT floor that closes a crit-header validation bypass, with upper bounds to stop major-version drift arriving silently. The mcp floor is described as closing advisories flagged by Dependabot.

The container takes the same approach. The base image is python:3.12-slim pinned by SHA digest, with a comment explaining that the digest exists to satisfy an OpenSSF Scorecard pinned-dependencies check and that Dependabot refreshes it. The dependency install uses a hash-pinned lockfile with --require-hashes so the image cannot pick up a different artefact.

ENV PORT=8080
EXPOSE 8080

The image runs as a dedicated unprivileged user with UID 10001 rather than as root, and the liveness probe is written with the standard library urllib because the slim base image has no curl and the project does not want a new dependency for a health check. The port is the Cloud Run default, which tells you the deployment target the image is shaped for.

A single maintainer, no external audit, and a fast release cadence

The README states its own status plainly, and it is unusual to see this written in a project README rather than left to the reader to infer. The status is a pre-1.0 toolkit, the README describes the current main source, it is a single-maintainer project with community contributions welcome, and no independent third-party security audit has been performed yet. The advice given is to deploy with the same diligence you would apply to any pre-1.0 open-source crypto stack.

That sentence is the correct one to keep in mind when reading the rest of the README. The tooling is careful, the caveats are specific, and the caveat list is really the security documentation, but nothing here has been reviewed by someone outside the project.

The release cadence is brisk. The tags are v0.4.1 on 2026-06-23, v0.4.2 on 2026-10-12 and v0.4.3 on 2026-10-12, with the last push to the repository on 2026-10-19. Two releases on the same day suggests the packaging of the website and documentation update alongside the runtime hardening, and the README's advice to compare release notes and pin the version you reviewed is the way to stay on top of that.

The repository layout matches a product rather than a library. Alongside the attestix/ package there are api/, audit/, auth/, blockchain/, signing/, storage/, tenancy/ and idempotency/ directories, a spec/ and specs/ pair, an integrations/ directory for the framework hooks, a demo/ tree with scenarios and a web app, a paper/ directory, tools/, a Dockerfile and a Dockerfile.test, a buildspec.yml, a server.json, and governance files including SECURITY.md, CODEOWNERS, CONTRIBUTING.md, ROADMAP.md and a CHANGELOG. The licence is Apache-2.0 and the package requires Python 3.10 or newer, with classifiers for 3.11, 3.12 and 3.13 and a topic of Security :: Cryptography.

So the project is best read as an infrastructure attempt rather than a finished product: broad, opinionated about its verification profile, honest about its gaps, and moving quickly enough that the published version and the source version will not stay aligned for long.

Editorial conclusion

Adopt Attestix if you need portable, offline-verifiable evidence about what an agent did, because the design puts the verification story first, with a canonical-JSON and Ed25519 profile that six language verifiers implement and conformance fixtures they share. Do not adopt it on the assumption that a generated declaration is a compliance result, since the README states that legal_conformity is not assessed and that workflow_complete only records that documentation exists, and do not treat a single shared API key as a multi-tenant boundary, because the default REST server is single-tenant. Before you deploy it, pin attestix to 0.4.2 because that is the published hardening baseline, move your imports to the attestix.* namespace before v0.5.0 removes the shims, and read the offline verifier README for the language you plan to use, since the trust-input and delegation-chain checks differ between them.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. VibeTensor/attestix on GitHub