Asqav SDK (Python + TypeScript)
Signed, verifiable compliance receipts for every AI agent action — post-quantum signatures, hash-chained audit trails, verifiable without trusting the vendor.
Least privilege: pure client SDK with zero native dependencies; private keys are documented as server-side only and never exposed to the SDK; test fixtures isolate the credentials path to tmp. Good, but evidence is file-level only, so not full marks. User confirmation: as a receipt/audit SDK it rarely performs destructive actions, yet no documented review-or-approve flow before signing exists — 1. Data flow transparency: receipt payload structure is visible in tests, offline verification and local chain_hash recomputation are supported; however every signed action's evidence goes to a third-party cloud, and README does not enumerate which context fields leave the machine. Sensitive data handling: server-side key storage and credential-file isolation are sound, but arbitrary context payloads go to the cloud and no redaction guidance appears. Dependency security: SECURITY.md enumerates GHSA IDs, explains extras gating, reports 0 vulnerabilities on the default path, and honestly discloses an unpatched critical chromadb advisory behind an opt-in extra — rare transparency, full marks. External effects: the SDK sends action evidence to asqav.com (an external side effect), but locally signed Ed25519/ES256 receipts offer a cloud-free option; deduction for the incompletely documented boundary of the cloud-issuance path. Rollback: the hash chain is immutable by design and no receipt revocation/deletion mechanism is documented — 1. Source attribution: publisher is an unverified individual GitHub account; per the publisher rule no extra deduction for that, but attribution depth is limited — 1.
Self-consistency: conformance/ mandates shared cross-language fixtures, fixture-first development, and CI-enforced verdict parity; the acceptor tests cross-check the oracle and include meta-tests guarding against default-accept bugs — full marks. Dependency availability: zero runtime dependencies on the default path, but the framework extras (smolagents/dspy/crewai) carry known advisories including an unpatched critical — an optional-path tension worth 2. Failure messages: middleware fails closed (403 with no request reaching the app for missing/junk receipts), refusals carry a named rule and first failing edge, doctor returns non-zero — failure paths are well tested, full marks.
Audience and scenarios: clearly aimed at agent-framework developers (LangChain/CrewAI/MCP) and compliance/audit consumers, with per-language READMEs covering quick start, CLI, and CI integration; depth lives in linked docs — 2. Capability boundaries: README explicitly explains that the example signature_id returns verified:false and promises a 'what a receipt does not prove' section — outstanding boundary awareness, full marks. Trigger precision: sign/verify/doctor entry points are clearly delineated in CI and tests; the acceptor/verifier responsibility split is pinned by dedicated tests, but agent-side interception triggers are under-documented — 2. Environment fit: exact Python 3.10–3.12 and Node 20.19+/22.12+ pins, offline CLI verification, ASGI middleware; deduction for the narrow Node version window — 2.
Information architecture: clear repository layout diagram, sensible separation of conformance/verifier/python/typescript, layered docs (repo README, language READMEs, docs site) — full marks. Install notes: install commands, version requirements, and extras examples for both languages — full marks. Naming stability: consistent asqav/asqav-sdk/@asqav/sdk naming, but ELv2 licensing and independent versioning carry no continuity commitment — 2. Examples and FAQ: complete main README examples with the example-ID failure behavior explicitly explained (a highlight), but the FAQ lives off-repo and language-level examples are only referenced — 2. Known limitations: 'what a receipt does not prove' section, known-advisory disclosure, and an honest note that the macOS binary is hand-built are positive evidence; the limitations list is still incomplete (e.g., cloud availability dependency undiscussed) — 2. License: full Elastic License 2.0 text is present, but repo metadata is NOASSERTION and ELv2's hosted-service and trademark restrictions materially constrain enterprise adoption — 2. Versioning/changelog: independent per-language versioning, tag-prefixed OIDC publishing (py-v*/ts-v*), CHANGELOG referenced; mechanism is complete but the changelog content itself is not in evidence — 2. Maintenance responsibility: 48-hour security response commitment, latest-version-only support without backports, scheduled published-artifact probes, blocked direct pushes to main — mature process; but the maintainer is a single unverified individual with no long-term backing — 2.
Output usability: verify returns verified/chain_hash/verification_url; acceptor decisions are injected into scope.state for downstream handlers with structured refusal reasons (rule/edge/class) — good usability, but the full result schema is not shown in evidence — 2. Marginal value: a verifiable, offline-checkable, post-quantum evidence layer for agent actions is a scarce position, and acceptor-side admission control (rejecting evidence a verifier would accept) fills a real gap — full marks. Cost benefit: zero-dependency default install, free tier, accountless offline verification keep costs low; but cloud issuance is plan-gated and outbound evidence data carries its own assessment burden — 2.
Claim traceability: nearly every claim (CI behavior, publishing, binary builds, advisories, example-ID semantics) maps to a concrete file or test, and tests include anti-self-deception meta-tests — full marks. Cross-source corroboration: external claims about PyPI/npm packages, the IETF Independent Submission, an NSA citation number, and the pricing page cannot be verified from within this repository; the draft's existence and status are unconfirmed — 1. Fact/inference separation: SECURITY.md cleanly separates default-path vs extras-path exposure, README distinguishes the shape-example ID from real receipts, wording is generally careful; but some security claims ('liboqs server-side', 'RFC 3161 compliant') are not re-checkable from static evidence — 2.
- Publisher is an unverified individual account; assess long-term maintenance and supply-chain trust independently.
- The license is Elastic License 2.0, which prohibits offering the software as a hosted/managed service — review restrictions before commercial integration; repo license metadata is NOASSERTION.
- Every signed action's evidence is uploaded to asqav.com by default; assess whether outgoing context contains sensitive business data. Only the locally-signed (Ed25519/ES256) path avoids the cloud.
- Installing the [crewai]/[dspy]/[smolagents] extras pulls known-vulnerable dependencies, including a critical chromadb advisory with no upstream patch; avoid asqav[all] in production.
- External claims (IETF draft status, NSA citation, PyPI/npm publication) were not verified in this static review.
- Security fixes ship only in the latest version and are never backported; production deployments must track patch releases.
- The receipt chain is immutable and no revocation mechanism is documented; confirm remediation paths for mis-issued receipts in advance.
What does this agent do, and when should you use it?
Asqav SDK is the Python and TypeScript client for asqav.com, the evidence layer for AI agents, hosted at jagmarques/asqav-sdk with python/, typescript/, conformance/ and verifier/ directories. Developers create a governed agent via govern(), then sign each action (e.g. api:openai:chat) with sign(), producing a compliance receipt signed with ML-DSA-65 (FIPS 204, post-quantum), hash-chained, and timestamped against independent witnesses. Anyone holding a signature_id — auditor, counterparty, regulator — can verify it via verify() without an Asqav account; the SDK recomputes the SHA-256 chain_hash locally over the RFC 8785 canonical payload. Both SDKs have zero native dependencies, with cryptography executed server-side, and offline zero-trust verification is available via verify_receipt_offline. The project profiles an IETF Internet-Draft (draft-marques-asqav-compliance-receipts), integrates with LangChain, CrewAI and MCP ecosystems, and is distributed under Elastic License 2.0 with Free/Pro/Enterprise plans.
The core flow: register an agent with asqav.govern(api_key="sk_...", agent_name=...) in Python or govern({apiKey, agentName}) in TypeScript; then call agent.sign("api:openai:chat", {"model": "gpt-4o"}) per action, where the server signs with ML-DSA-65 and returns a receipt containing a verification_url. On the verification side, asqav.verify(signature_id) or verify() returns a verified boolean and recomputes chain_hash (SHA-256 over the RFC 8785 canonical payload) locally with no account required; cloud-issued receipts use ML-DSA-65 while locally signed ones use Ed25519/ES256, with the algorithm taken from the receipt's signature.alg field. For fully offline zero-trust checks that reproduce the signature itself, use asqav.verify_receipt_offline(receipt, jwks), verifyReceiptOffline(), or the CLI python -m asqav.verifier.verify_receipt --offline. The repository also ships conformance/ cross-language fixtures, a neutral multi-format verifier in verifier/, and the asqav doctor configuration/connectivity check, with CI publishing py-v* tags to PyPI (asqav) and ts-v* tags to npm (@asqav/sdk).
- Teams regulated under the EU AI Act or DORA that need tamper-evident receipts for every production agent API call
- AI platform engineering teams adding policy enforcement and audit trails to agent pipelines built on LangChain, CrewAI, MCP or OpenAI Agents
- External auditors or regulators who hold only a signature_id and must verify an action receipt without an account and without trusting the vendor
- Procurement or security reviewers needing to reproduce and verify receipt signatures in a fully offline, zero-trust environment via verify_receipt_offline
- SaaS providers who must present third-party-verifiable evidence of agent behavior to customers or counterparties as contractual deliverables
- CI/CD platform teams using asqav doctor to validate configuration and connectivity in pipelines, where failure exits non-zero to gate merges
What are this agent's strengths and limitations?
- Third-party verifiable: auditors and regulators can validate receipts without an Asqav account, and the verifier honestly returns verified: false when evidence is absent
- Uses NIST FIPS 204 (ML-DSA-65) post-quantum signatures, aligned with RFC 8785 (JCS) and NSA CSI standards; the algorithm is per-receipt (cloud ML-DSA-65, local Ed25519/ES256)
- A genuinely offline zero-trust verification path exists (verify_receipt_offline / --offline CLI), with chain_hash reproducible on your own machine
- The conformance/ directory forces both language SDKs through the same fixture set, and CI reruns both matrices on fixture changes, catching cross-language drift at PR time
- Documented integrations with mainstream agent ecosystems — LangChain, CrewAI, MCP, OpenAI Agents — plus an IETF Internet-Draft as a standards anchor
- Core signing depends on the Asqav server: the README states cryptography runs server-side with zero native dependencies, creating a runtime dependency on the vendor's cloud for the signing path
- Licensed under Elastic License 2.0 (GitHub marks it NOASSERTION), which is not an OSI open-source license, limiting self-hosting and redistribution for enterprise adopters
- Plans are Free/Pro/Enterprise with quotas and some capabilities plan-gated; prices and limits live on asqav.com/pricing, so heavy usage incurs ongoing costs
- The TypeScript runtime window is narrow (Node 20.19–20.x or 22.12+), requiring upgrades on older Node environments
- The README's example signature_id is a shape example with placeholder signature bytes and an unresolvable kid, so first-time users must generate a real receipt to see a passing verification
How do you install or deploy this agent?
Python (requires 3.10+): pip install asqav. TypeScript (requires Node 20.19–20.x or 22.12+): npm install @asqav/sdk. Both packages have zero native dependencies; cryptography runs server-side. After installing, obtain an API key (sk_... format) from asqav.com and supply it as the ASQAV_API_KEY environment variable or an explicit parameter. From source: clone https://github.com/jagmarques/asqav-sdk, then run cd python && pip install -e ".[all,dev]" for Python or cd typescript && npm ci for TypeScript.
How do you use this agent?
Step 1, register the agent: import asqav; agent = asqav.govern(api_key="sk_...", agent_name="my-agent") in Python, or const agent = await govern({ apiKey: process.env.ASQAV_API_KEY, agentName: "my-agent" }) in TypeScript. Step 2, sign an action: agent.sign("api:openai:chat", {"model": "gpt-4o"}) returns a receipt with a verification_url; in TypeScript use agent.sign({ actionType: "api:openai:chat", context: { model: "gpt-4o" } }). Step 3, verify: asqav.verify(signature_id) or verify(signature_id) returns verified and chain_hash with no account needed. For offline verification use asqav.verify_receipt_offline(receipt, jwks), verifyReceiptOffline(), or python -m asqav.verifier.verify_receipt --offline. Run asqav doctor (with ASQAV_API_KEY set) for a configuration and connectivity check. Framework integrations, the CLI and data-handling modes are documented in python/README.md and typescript/README.md.