Attest

io.github.dev-prathapPublished by GitHub account dev-prathapv0.1.0Updated Nov 3, 2026

Decide by policy, gate behind a human, verify by read-back, record a hash-chained ledger.

Overview

AI-generated overview

Attest is a local MCP verify server that lets an assistant gate agent actions behind human approval, read back from systems of record, and record a…

What you can do
  • Decide and gate actions: apply a policy to an agent action and pause for human confirmation, with approvers able to edit parameters before approving.
  • Verify outcomes: read back from Gmail, Google Workspace, Microsoft Graph, HubSpot, Notion, Linear or Slack and compare fields against the claimed result.
  • Record evidence: write each action to a hash-chained SQLite ledger with a stated verification level, plus signed checkpoints and exports.
  • Inspect the record: query ledger rows and their verification evidence, including which fields disagreed.
  • Integrate: use it as a zero-code MCP proxy in front of other servers, or via SDK decorators, HTTP gateway and framework adapters.
When to use it
Useful when an agent performs consequential external actions such as sending email, updating a CRM or moving money, and you need proof of what actually happened rather than a success message. Also fits teams that need an auditable, tamper-evident trail for compliance or incident review.
Requirements
Runs locally over stdio, installed from PyPI as attestlayer with uvx. Read-back needs OAuth or API tokens for the systems you want to check: GMAIL_TOKEN, GOOGLE_TOKEN, GRAPH_TOKEN, HUBSPOT_TOKEN, NOTION_TOKEN, LINEAR_API_KEY, SLACK_BOT_TOKEN. Optional settings include ATTEST_POLICY, ATTEST_LEDGER, ATTEST_CONFIRM_TIMEOUT and ATTEST_AUTO_APPROVE. A human approval channel (Slack, web inbox, webhook or console) is needed for gated actions.
Before you install
It stores a ledger of agent actions and may send hashes and previews to Attest Cloud if you use the paid cloud tier; the SDK alone keeps a local ledger. Read-back tokens are real credentials with access to mail, CRM and workspace data, so scope them narrowly. ATTEST_AUTO_APPROVE=1 disables human gating and is documented as development only. Approvers can edit action parameters, and those edits are recorded.

Installation

In SourceWeft

  1. Open Attest in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

Attest — prove what your AI agent actually did

[ci] [pypi] [npm] [docs] [license]

Decide → Gate → Verify → Attest. Your agent sends the email, updates the CRM, moves the money. Attest decides whether it may, gates it behind a human when it matters, reads back from the system of record to check it actually happened, and records tamper-evident evidence either way.

Attest never executes your action. Your tool does. That is why it works with any app and any framework on day one.

Your agent says it worked. Did it?

Two identical CRM writes, both reported success by the tool, both approved by a human:

console
$ attest ledger#2  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  unverified   a09e7641db12#1  2026-09-19 10:16:46  someweirdcrm.create → leads   ask  approved  verified     77a6d99a60f6

The second one read back clean. The first did not, and the ledger says which field disagreed:

json
{ "level": "unverified", "matched": false,  "evidence": { "compared": 4, "exists": true, "failed": ["stage"],    "fields": { "stage": { "want": "qualified", "got": "new", "ok": false } } } }

A trace would have shown two green steps. That gap is the entire product.

Install

bash
pip install attestlayer          # Pythonnpm  install attestlayer         # TypeScript — byte-identical ledger format
python
import attest
@attest.action(system="gmail", verb="send", target="to")def send_email(to, subject, body): ...
ts
import { Attest } from "attestlayer";
const at = new Attest({ agent: "followup-agent@v3", readers: { gmail: process.env.GMAIL_TOKEN! } });const sendEmail = at.wrap({ system: "gmail", verb: "send", target: "to" },                          async ({ to, subject, body }) => gmail.send({ to, subject, body }));

That is the whole change. The first external send now pauses for a human, and the ledger row says acknowledged, or verified once Attest can read back with the agent's own credentials (Attest(readers={"gmail": service})). Nothing else in your code moves.

Verification is layered, and it never overstates

Every row states exactly how much was checked. A check that could not run is never dressed up as a pass.

levelwhat it means
verifiedread back from the system of record, and the fields matched
verified-customyour own check ran and passed
acknowledgedthe action was accepted, but no read-back could run here
attested-onlyrecorded with no verifier available for this action
unverifieda check ran and contradicted the claim

Only a contradiction earns unverified. Missing credentials, a read-only scope or an unsupported verb degrade to acknowledged, because "we could not check" and "it did not happen" are different facts.

Where it plugs in

surfacehow
Decorator / wrapper@attest.action(...) · at.wrap(...)
LangGraphtool node wrapper, gate as a graph interrupt
OpenAI Agents · Claude Agent SDK · CrewAI · DeerFlowadapters in attest/
MCPzero-code proxy in front of any server, plus a verify server
HTTP gatewaypoint outbound traffic at it, no SDK at all
API onlyPOST the descriptor yourself

Human confirmation lands where the team already works: Slack, the web inbox, a webhook, a LangGraph interrupt, or the console. Approvers can edit the parameters before approving, and the edit is recorded.

The record itself

Hash-chained ledger, SQLite locally and Postgres per organisation in the cloud. Signed checkpoints let you prune old rows and still verify the chain. Optional Ed25519 signing, and external anchoring to a file, a git repo or an HTTP endpoint. Exports: JSON, CSV, the IETF draft-sharif-agent-audit-trail JSONL format, and an EU AI Act event-log pack.

Overhead is roughly a sixth of a millisecond per action, measured in benchmarks/ (published numbers).

Try it locally

bash
python examples/unknown_app.py                         # an app Attest has never seen, L1 → L3ATTEST_AUTO_APPROVE=1 python examples/langgraph_agent.pycd deploy && cp .env.example .env && docker compose up  # cloud API :8400 + dashboard :3400

Attest Cloud

The SDK is MIT and works standalone with a local ledger. Attest Cloud adds the shared ledger, the confirm inbox, versioned org policy, agent keys and compliance exports. Your vendor tokens never reach it: read-back happens in your process with your own credentials, and only hashes and previews are sent. Self-host it from deploy/, or read DEPLOY.md.

Install channels

wherehow
PyPIpip install attestlayer → attest, attest-mcp, attest-mcp-server, attest-gateway
npmnpm install attestlayer
MCP Registryio.github.dev-prathap/attest (verify server) · io.github.dev-prathap/attest-proxy (zero-code proxy)
Smitheryattestlayer/attest
Claude Desktopattest-<version>.mcpb on the latest release
Dockerghcr.io/dev-prathap/attest-api · ghcr.io/dev-prathap/attest-dashboard

Documentation

Full docs at dev-prathap.github.io/ATTEST — quickstart · verification levels · policy · read-back recipes · ledger & exports · hardening

Repository

pathwhat
attest/Python SDK — descriptor, policy, ledger, verification ladder, gates, adapters, MCP proxy, CLI
packages/attest-ts/TypeScript SDK — same canonical hashes, fixture-tested against Python
cloud/Attest Cloud — FastAPI + Postgres: orgs, keys, policy versions, ledger, confirm inbox, exports
dashboard/Next.js dashboard — ledger drill-down, confirm inbox, policy and keys
examples/unknown app, LangGraph, OpenAI Agents, MCP config, API-only, cloud
deploy/Dockerfiles and compose
benchmarks/what the layer costs per action
docs/documentation site source, plus design notes
bash
pytest -q && (cd cloud && pytest -q)     # 355 + 37 offline testspytest tests/live                        # 8 live suites; need real credentials, skipped without them

Contributing

Read-back recipes are the easiest place to start: each one teaches Attest how to confirm a write in one more app, and needs nothing but that app's read API. See CONTRIBUTING.md, and SECURITY.md for reporting a vulnerability.

Principles

  • We never execute your action. Your tool executes; we decide, gate, verify and record.
  • Coverage is universal. Verification depth is layered and stated honestly on every row.
  • Open-source SDK under MIT. Paid cloud for the shared ledger, inbox, policy and exports.

Design notes

The thinking behind the product, kept in the open: vision · product · universal adapter · architecture · market · build plan · decisions · phase plan

Lineage

Attest's core mechanisms are extracted from two working codebases: DO (policy engine, read-back verification pairs, evidence ledger) and DeerFlow (tool receipts, verification patterns, MCP and chat-channel adapters), which run against real Gmail, Slack, HubSpot, Notion, Linear and Google Workspace. Attest ships its own live suites for those systems in tests/live/; they need real credentials and are skipped without them.

Source: README.md at commit a694329

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.0LatestSep 19, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts