Asqav SDK: signed compliance receipts for AI agent actions
Python and TypeScript SDKs for verifiable evidence of AI agent actions. Signed receipts, policy enforcement, audit trails. Works with LangChain, CrewAI, MCP.
At a glance
- What is it?
- The asqav-sdk repository ships Python and TypeScript clients that turn each agent action into a hash-chained, ML-DSA-65 signed receipt, verified either against the hosted service or fully offline. The design is honest about what a receipt does not prove, and the licence is the part to read before you build on it.
- Who is it for?
- Adopt it if you already need portable, third-party-verifiable evidence of what an agent did, and you accept that signing calls the Asqav service, that the SDKs are versioned separately, and that the code is under the Elastic License 2.0 rather than an OSI-approved licence. Do not adopt it as a local-only audit log or as an open source component you intend to relicense or resell.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: agent actions that nobody outside your team can check
An agent calls a model, a tool, a payment API. Your logs record that it happened, but the log lives on your infrastructure, is written by your code, and is only as trustworthy as your own access controls. When a regulator, a counterparty or an auditor asks what the agent did, you are handing over a file you produced. That is the gap asqav-sdk targets: it produces a signed, hash-chained compliance receipt for each action, with the stated goal that anyone holding the receipt can verify it without an Asqav account and without trusting Asqav. The intended audience is teams running agents in regulated or contractual contexts, which the repository topics make explicit: eu-ai-act, dora, ai-compliance, audit-trail. It is not a logging library. It is an evidence format plus clients for producing and checking it.
What actually happens when you call agent.sign
The README is direct about where the cryptography runs: zero native dependencies in either SDK, and cryptography runs server-side. So agent.sign does not sign locally. It sends the action to Asqav and returns a signature object carrying a verification_url. Each receipt is ML-DSA-65 under FIPS 204, described as post-quantum, timestamped against independent witnesses, and hash-chained. The chain link is reproducible on your machine: verify() recomputes chain_hash as SHA-256 over the RFC 8785 canonical payload. That detail matters more than it looks. Canonicalisation is where receipt schemes usually break, because two implementations serialising the same JSON differently produce different hashes. Pinning the canonical form to RFC 8785 is what lets a third party recompute the same value. The algorithm is read per receipt from signature.alg: ML-DSA-65 for cloud-issued receipts, Ed25519 or ES256 for locally signed ones. Two signing paths, one receipt format.
Cold verification and the placeholder receipt that returns false
The README's own example calls asqav.verify("sig_example_regulator_cold_verify_2026") and prints verified as False. That is deliberate. The id is a shape example whose signature bytes are placeholders and whose kid resolves to no key, so the verifier refuses it. The reasoning given is blunt: a verifier that says no when the evidence is absent is the only kind worth having. This is the most useful thing in the README, because a verification API that returns true for a malformed receipt is worse than no API. For a check that does not touch the service at all, verify_receipt_offline(receipt, jwks) in Python and verifyReceiptOffline() in TypeScript reproduce the signature itself, and there is a standalone entry point: python -m asqav.verifier.verify_receipt --offline. The verifier/ directory holds what the repository calls a neutral multi-format verifier plus its conformance corpus, and the TypeScript verifier is held to verdict parity with the Python oracle by that corpus.
Getting it running: install, govern, sign, doctor
Python needs 3.10 or later: pip install asqav. TypeScript needs Node 20.19 through 20.x, or 22.12 and later: npm install @asqav/sdk. The Python flow is agent = asqav.govern(api_key="sk_...", agent_name="my-agent"), then agent.sign("api:openai:chat", {"model": "gpt-4o"}), then read sig.verification_url. The TypeScript flow is await govern({ apiKey: process.env.ASQAV_API_KEY, agentName: "my-agent" }) followed by await agent.sign({ actionType: "api:openai:chat", context: { model: "gpt-4o" } }) and sig.verificationUrl. Note the argument shape differs between languages: positional in Python, a single object in TypeScript. For CI, asqav doctor validates configuration and connectivity in any environment with ASQAV_API_KEY set and returns non-zero on failure, so it can gate a pull request. The README points to docs/github-actions.md for a copy-paste workflow. The repository also names integrations with LangChain, CrewAI and MCP, though the README defers the specifics to the per-language package READMEs rather than showing them here.
Signing is a network call, and that is the main constraint
Because cryptography runs server-side, agent.sign is not a local operation. An agent that cannot reach Asqav cannot produce a cloud-issued receipt. If your agent runs in an air-gapped environment, or you need evidence generation to survive an Asqav outage, the offline verifier does not help you: it verifies receipts, it does not mint them. The README does mention locally signed receipts using Ed25519 or ES256, which implies a path that does not depend on the cloud issuer, but the top-level README does not document how to produce one. That is a gap worth closing before you design around it. The second constraint is disclosure. Signing sends action types and context to a third party. The README references data-handling modes in the per-language guides, so the controls exist, but they are not described in the material available here. Treat that as something to read in python/README.md and typescript/README.md before you sign anything sensitive.
Conformance fixtures are the part that makes two SDKs credible
The repository layout puts conformance/ alongside python/ and typescript/, and the README explains the workflow: adding a feature means adding a fixture first, then making both SDKs pass it. CI reruns both matrices whenever conformance/ changes, even if neither language directory was touched, so cross-language drift is caught at pull request time. That is a stronger arrangement than the usual pattern of two SDKs that agree until someone edits one. CI itself is path-filtered: pytest on Python 3.10, 3.11 and 3.12, npm test on Node 20 and 22, with a conformance/ change triggering both. The aggregator job ci-ok is the single required status check. Releases are tag-driven: py-v* publishes to PyPI via OIDC, ts-v* publishes to npm via the NPM_TOKEN secret, and the two SDKs are versioned and released independently. Independent versioning is convenient for maintainers and slightly annoying for consumers, since a Python fix does not imply a TypeScript one.
Where the evidence stops, and what to use instead
A signed receipt proves that a payload was signed by a particular key at a particular time and that the chain link is intact. It does not prove the agent behaved well, that the action was authorised, or that the context field is complete. The README explicitly flags a section on what a receipt does not prove, and anyone evaluating this should read it before promising an auditor anything. If your requirement is tamper-evident local logging with no third party and no hosted dependency, a hash-chained append-only log plus your own key management is the smaller tool, and it keeps everything in your infrastructure. The trade is verifiability by outsiders: a self-hosted log is checked by trusting you, which is exactly the property asqav-sdk is built to remove. If your requirement is simply observability, tracing and dashboards, this is the wrong layer entirely.
Licence, maintenance and the release cadence
The repository's licence field reads NOASSERTION, and the README states Elastic License 2.0. Those are not the same statement, and the difference matters: Elastic License 2.0 is source-available, not an OSI-approved open source licence, and it carries restrictions on providing the software as a service and on circumventing licence keys. This is not legal advice, and the exact terms should be read from the licence file in the repository rather than from this article. Practically, if your organisation has a policy against source-available dependencies, this SDK will trip it. On maintenance: the default branch is main, the repository is not archived, and the most recent push is dated 2026-09-09. The recent release list shows v0.6.0 on 2026-06-20, with py-v0.5.16 and npm-v0.5.16 both on 2026-06-17. The version numbering has not reached 1.0, and the top-level README defers most operational detail to the two package READMEs, so the upgrade surface you actually depend on is spread across three documents plus CHANGELOG.md. Budget for reading all of them at each bump.
Editorial conclusion
Adopt it if you already need portable, third-party-verifiable evidence of what an agent did, and you accept that signing calls the Asqav service, that the SDKs are versioned separately, and that the code is under the Elastic License 2.0 rather than an OSI-approved licence. Do not adopt it as a local-only audit log or as an open source component you intend to relicense or resell. Before committing, run asqav doctor with ASQAV_API_KEY set, read the receipt-limits section of python/README.md, and confirm on asqav.com/pricing which capabilities your plan gates.
Community notes