AEVS by Fetch.ai is a drop-in SDK that wraps every AI agent tool call in a tamper-evident, cryptographically signed receipt (ECDSA P-256, hash-chained, KMS-backed) that anyone can verify through a public explorer or a no-account API. The problem is real and timely: model text is not proof of what an agent actually did, and teams running agents that move money or touch sensitive systems increasingly need independent audit trails. The build is polished and credible, with two-line integration, an excellent llms.txt, an open-source Apache-2.0 repo, and a working public ledger. The biggest gaps are trust and compliance hygiene: there is no privacy policy or terms despite storing tool inputs and outputs, security headers are thin for a security product, the public explorer is dominated by internal test receipts, and real-world traction is still early. Note: the dashboard sits behind Google/GitHub OAuth only, so this review covers the full public surface plus the explorer but not the logged-in account area.
Scorecard
ux: 7.0/10 — The public site is clear, with a clean three-step flow, copy-paste quickstart, and an explorer where verification works in seconds. Points off because the dashboard is OAuth-only and the live ledger is cluttered with internal test data.
trust: 6.0/10 — Backed by a real company, open source, honestly labeled as beta, and independently verifiable, with no fabricated proof seen. Trust is held back by missing legal pages, thin security headers, and no named customers or testimonials.
demand: 5.0/10 — The macro need for agent auditability is real and growing, and Fetch.ai gives distribution, but on-site evidence of actual users is thin: the explorer is mostly internal test receipts and GitHub traction is modest.
design: 8.0/10 — Polished, consistent dark technical aesthetic with a terminal motif, strong typography, and clear visual hierarchy across the marketing site and the explorer. It looks like a serious engineering product.
use case: 7.0/10 — The use cases are concrete and well-aimed at developers and compliance-minded teams running agents that touch money or sensitive systems. It is less clear what limits, retention, or team features exist beyond the SDK and explorer.
innovation: 7.5/10 — Cryptographically signed, hash-chained, KMS-anchored receipts with a public, no-account verify flow is a fresh angle versus typical agent observability that just logs traces. The explorer as a public ledger of agent actions is a distinctive idea.
performance: 8.0/10 — Pages load fast on Vercel, the explorer and receipt verification respond quickly, and no console errors appeared on AEVS pages. Verification of a real public receipt completed successfully.
problem fit: 8.0/10 — It targets a genuine pain: the model's reply is not proof of execution, and agents that take real actions need verifiable records. The problem is clearly stated and the receipt approach maps directly onto it.
docs policies: 4.0/10 — Developer docs, examples, a changelog, and a security policy exist in the GitHub repo and the llms.txt is excellent, but there is no privacy policy and no terms of service, which is a real gap for a product that stores tool inputs and outputs.
discoverability: 6.0/10 — Strong OpenGraph, Twitter cards, and a self-contained llms.txt make it AI-friendly, but there is no JSON-LD structured data, no sitemap.xml, and no robots.txt, and pricing is not machine-readable.
The standout: Every agent tool call becomes a signed, hash-chained receipt that anyone can verify with no account and without re-running the agent.
The genuinely new idea here is treating each tool call as a cryptographic artifact rather than a log line: ECDSA P-256 signatures, a hash chain that exposes any deletion or reordering, KMS anchoring, and a public explorer where a third party can independently confirm a receipt. That is a meaningful step beyond mainstream agent observability tools, which mostly record traces you have to trust them to keep honest. Where AEVS plays it safe is the surrounding product: framework interception via LangChain and MCP patching, a dashboard, and visibility toggles are all conventional, and the two-line integration, while excellent for adoption, is not itself novel. The signing and public-verification core is the differentiator; the rest is solid table stakes.
Genuinely new:
Cryptographically signed, hash-chained receipts per tool call
Independent verification with no account via reference_id
Public receipt explorer as an auditable ledger of agent actions
KMS-backed signing keys for stronger non-repudiation
Plays it safe:
LangChain and MCP interception via SDK patching
Two-line drop-in integration
Dashboard with per-agent visibility settings
Success and error status tracking
How to push the edge further:
Anchor proofs to an external authority: Periodically publish the chain root to an independent timestamp authority or public chain so verification does not depend on trusting the AEVS backend, which sharpens the non-repudiation claim that is the whole point.
Add policy-aware receipts: Capture not just what ran but whether it was authorized under a declared policy, so a receipt proves the agent acted within bounds, not merely that it acted.
Support privacy-preserving proofs: Offer hashed or zero-knowledge style receipts that prove a tool call happened without exposing sensitive inputs and outputs, which would unlock regulated use cases that cannot put payloads in a public explorer.
Disrupt factor
What it is: AEVS (Agent Execution Verification System) is a Python SDK and hosted backend that intercepts each tool call an AI agent makes and writes a tamper-evident, cryptographically signed receipt: tool name, inputs, output, timing, and errors, ECDSA P-256 signed, hash-chained, and KMS-anchored. Receipts can be browsed in a public explorer or verified by anyone holding a reference_id through an API that needs no account.
Who it is for: The user is developers building agents on LangChain, LangGraph, or MCP; the buyer is engineering, security, and compliance leaders at teams whose agents take consequential actions. It sits in the AI agent observability and governance market, on the audit and non-repudiation end rather than the performance-tracing end.
Disruption potential (7.0/10): The wedge is real: most agent observability tools store mutable traces in their own database, while AEVS produces portable, independently verifiable cryptographic proof that does not require trusting the vendor or re-running the agent. That non-repudiation angle, plus a public explorer and a no-account verify API, is a credible differentiator as regulation and enterprise risk teams start demanding provable audit trails for autonomous actions. Being backed by Fetch.ai gives it distribution and a crypto-native signing story. It is early and unproven in the market, so the potential is strong but not yet realized.
Roadmap to disrupt:
Map receipts to compliance frameworks: Show explicitly how receipts satisfy audit requirements (for example EU AI Act record-keeping or SOC 2 evidence). Buyers in regulated settings need that mapping to adopt, and it turns a neat primitive into a procurement-ready product.
Land and publicize a real reference customer: Replace the internal test receipts in the public explorer with at least one named design partner using AEVS in production. Concrete proof of someone trusting it with real agent actions is what converts a clever idea into a category.
Add external anchoring and exportable proofs: Offer periodic anchoring to an independent timestamp authority or chain and one-click exportable proof bundles, so an auditor can verify offline. This strengthens the non-repudiation claim beyond trusting the AEVS backend.
Hallucination factor (3.0/10, lower is better)
Reality check: This is mostly grounded in a real problem. Agents that take real actions genuinely need provable records of what executed, and demand for AI audit and governance is rising, even if AEVS itself has not yet shown much real-world adoption.
The core need is real: anyone running agents that move money, issue refunds, or change data has felt the gap between what the model says it did and what actually happened, and existing logs are mutable and easy to dispute. Teams already pay for agent observability tools, which shows budget exists nearby, and the cryptographic, independently verifiable angle is a sensible response to regulation and enterprise risk. Where it leans toward scope for its own sake is the visibility and explorer machinery: a public ledger of agent actions is elegant but it is not obvious that customers want their agent activity publicly browsable, and the live explorer being filled mostly with internal test and benchmark tools suggests the demand is still being manufactured rather than observed.
Reads as invented:
Public explorer dominated by internal test and benchmark receipts rather than real customer activity
No named users, testimonials, or case studies
Public ledger framing may not match how cautious enterprises actually want to store agent logs
Grounded in real demand:
Clear, specific job: prove which tool ran, with which inputs and outputs
Adjacent market already pays for agent observability (LangSmith, Langfuse, AgentOps)
Concrete high-stakes example (agent issuing a refund) where audit matters
Rising regulatory pressure for AI record-keeping
How to lower it: Talk to a handful of teams running agents that touch money or regulated data and confirm whether they want public verifiability or private, exportable proof, then lead the site with that one validated job instead of the broader explorer story.
Social & marketing strength (4.0/10)
AEVS markets itself competently to developers but proves itself thinly. The positioning is sharp and the copy is clear, with a strong central message that model text is not proof of execution, a clean call to action to install and open the explorer, and excellent machine-readability through llms.txt and a public GitHub repo. What is missing is social proof and reach: there are no customer logos, testimonials, usage stories, or visible follower counts, the explorer is filled mostly with internal test receipts rather than real activity, there is no on-site blog or email capture, and pricing is absent. It leans on the Fetch.ai brand and a Product Hunt listing rather than its own demonstrated traction, so it reads as an early, engineering-led launch that has not yet built a marketing or proof engine.
Social proof:
Product Hunt listing (AEVS by Fetch.ai)
Open-source GitHub repo (54 stars, 16 forks)
Backed by the Fetch.ai brand
Public verifiable explorer with live receipts
Channels:
GitHub repository
Product Hunt
PyPI package listing
llms.txt for AI assistants
Public receipt explorer
Strengths:
Sharp, memorable positioning line
Clear primary call to action (install and open explorer)
Strong developer-facing machine-readability via llms.txt
Credible open-source and brand backing
Gaps:
No customer logos, testimonials, or case studies
No on-site blog or content marketing
No email or newsletter capture
No pricing presentation
Live explorer dominated by internal test data, weakening the proof it offers
How to grow reach and conversion:
Replace test data with real receipts in the explorer: Curate the public ledger so first-time visitors see real, named agent activity rather than aevs_test_drain entries. The explorer is the strongest proof asset and it currently undercuts itself.
Publish a short technical blog and changelog on-site: Write up the signing, hash-chaining, and verification design and surface the repo changelog as a web page. This builds SEO, gives AI assistants more to cite, and demonstrates momentum.
Add email capture and a get-credentials funnel: Offer a way to follow updates and a clear, low-friction path from the marketing site to a registered agent and API key, so interest is captured instead of lost.
Land and publish two design-partner stories: Even short quotes from real teams using AEVS would convert the credible idea into credible proof and lift the trust and demand signals the product currently lacks.
Pivot factor
The same interception, signing, and verification pipeline AEVS already runs is worth more than the developer audit tool it is sold as today; the receipts are a data and trust asset that could anchor several adjacent products.
Agent insurance and dispute resolution (new application): Signed receipts are exactly the evidence an insurer or a chargeback process needs to settle what an autonomous agent did. AEVS could become the proof layer underneath agent liability and dispute products, using the receipt chain it already produces.
Compliance evidence pack for AI governance (new audience): Repackage the receipt store as a SOC 2 and AI Act evidence exporter for risk and audit teams rather than developers, tied to the structured, tamper-evident records it already captures.
Marketplace trust layer for agent-to-agent commerce (partnership): Fetch.ai is building autonomous agent ecosystems; AEVS receipts could be the settlement and trust record when one agent pays or transacts with another, using the existing signing and KMS infrastructure.
Verified analytics and benchmarking (revenue stream): Because receipts capture tool, timing, and error data in a trustworthy way, AEVS could sell verifiable reliability and performance benchmarking of agents and tools, data competitors cannot fake.
Screenshots
Landing page (9.0/10)
Strong hero with the bold 'Every tool call, signed.' headline, a real code snippet, copy-ready install command, and clear CTAs backed by a Product Hunt badge and trust details like ECDSA P-256 and open source.
How it works section (9.0/10)
Highly scannable Catch, Sign, Verify flow paired with a realistic signed receipt example and a clear problem framing that convincingly sells the value.
Login page (8.0/10)
Clean, low-friction sign-in with Google and GitHub options, a reassuring note that an account is created automatically, and consistent branding with the search bar visible.
Pros
Solves a real and timely problem: provable, independent evidence of what an agent actually executed
Genuinely low-friction integration, roughly two lines of code with no changes to existing tools
Strong cryptographic story: ECDSA P-256 signatures, hash chaining, KMS anchoring, and a working public verify flow
Public receipt explorer lets anyone verify a receipt with no account, which is a credible trust mechanism
Excellent machine-readability via a self-contained llms.txt aimed at coding agents
Open source under Apache-2.0, backed by Fetch.ai, with docs, examples, changelog, and a security policy in the repo
Honest beta labeling and clear, well-designed developer-focused site
Cons
No privacy policy and no terms of service, despite storing agent tool inputs and outputs and using OAuth login
Missing security headers (no CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy) on a product whose whole pitch is trust
Public explorer is mostly internal test and benchmark receipts (aevs_test_drain, aevs_bench_tool), which weakens the live-ledger impression for visitors
Thin real-world traction and social proof: no customer logos, testimonials, or usage stories, and modest GitHub stars
No pricing or usage limits stated anywhere, so cost and quotas are unknown
Messaging inconsistency: the site leads with ECDSA P-256 while the README and llms.txt lead with HMAC-signed
Dashboard login is Google or GitHub OAuth only, with no email option, which excludes some users
No JSON-LD structured data, sitemap.xml, or robots.txt, which limits search discoverability
Best for
Developers and teams building AI agents that take consequential, real-world actions (payments, refunds, data changes) and need portable, independently verifiable proof of exactly what ran.
Not for
Non-technical users, or simple chatbots and agents with no tool calls and no audit, compliance, or non-repudiation needs.
FAQ
What does AEVS actually do?
It intercepts every tool call your AI agent makes and writes a tamper-evident, cryptographically signed receipt that records the tool, inputs, output, timing, and errors. Each receipt is ECDSA P-256 signed, hash-chained, KMS-anchored, and can be verified by anyone with its reference_id.
Which frameworks does it support?
LangChain and LangGraph, and MCP (Model Context Protocol), on Python 3.10 to 3.13. Integration is about two lines of code and does not require changing your tools.
Do I need an account to verify a receipt?
No. Anyone holding a reference_id can verify a receipt through the public API or the explorer, without an account and without re-running the agent.
How much does it cost?
No pricing or usage limits are published. It is currently in open beta and free to sign in with Google or GitHub and get credentials.
Is it open source and who is behind it?
Yes, the SDK is open source under Apache-2.0 on GitHub (fetchai/AEVS-sdk) and the product is built by Fetch.ai. It is clearly labeled as beta, so APIs and the explorer may change.
Does it have a privacy policy or terms of service?
Not at the time of review. There is no privacy policy or terms on the site even though it stores agent tool inputs and outputs, which is a gap to weigh if you handle sensitive data.