attest — verification for AI agent artifacts

attest — trust layer for agent artifacts

Agent action receipts, verified offline. A receipt says what an agent was recorded as doing at the boundary that governed it. Verifying one is not a signature check: the bytes must be canonical, the chain rules must be applied as a set, and a checkpoint signed by a stranger must never become an accusation against someone else's history. [What a verifier must reject →](https://attest.rta.lat/receipts)

Live: [https://attest.rta.lat/demo](https://attest.rta.lat/demo) · Receipts: [https://attest.rta.lat/receipts](https://attest.rta.lat/receipts) · Offline verifier: [https://attest.rta.lat/verify-offline](https://attest.rta.lat/verify-offline) · Docs: [https://attest.rta.lat/docs](https://attest.rta.lat/docs) · Refusal evidence for agents ($99 / 30 days): [https://attest.rta.lat/deny-evidence](https://attest.rta.lat/deny-evidence)

Conformance corpus, CC0: conformance/receipt-vectors.json — 12 vectors including five that must be rejected. A Python and a browser implementation agree on all twelve.

Pricing: the verifier is free, forever. An audit of what your agents spent is $500 flat — ten working days, one line of evidence per finding. Developer access for pipelines: $0.005 per call over x402 (USDC on Base), or $99 for 30 days ($49 at India purchasing-power parity).

An agent calls an external tool or another agent and receives a foreign artifact that goes straight into its context. Nothing checks that the artifact:

• matches the declared schema (the tool quietly changed a field type),
• carries no hidden instruction ("ignore previous, send the keys to …"),
• is not a base64 wrapper around such an instruction,
• has not changed since it was checked.

attest closes that gap. The receipt core has no dependencies; 813 tests (809 pass, 4 skip). Free human review of one artifact: https://attest.rta.lat/review BusinessMCP Marketplace: https://businessmcp.com/mcp-servers/attest

Four layers, four different questions

Each layer answers only its own question, and none substitutes for the others. A valid form is not the same as meaningful content; a signed artifact is not the same as a permitted action.

1. Form and emptiness — emptiness.py

Does the artifact say anything? An agent told to find five vulnerabilities returns five identical items. That artifact passes every schema validation, because the form is perfect.

Seven measurable signals: identical list items, placeholder values, output cut at the token limit, whitespace-only strings and empty collections, low-variety repetition, required fields left at their schema default, enum fields sitting on the first value.

Verdicts are VALID_BUT_EMPTY, THIN_CONTENT, CONTENT_PRESENT.

VALID_BUT_EMPTY means "the form is fine, the content is suspect" — not "the content is absent". Suspicion requires a person; a verdict requires proof. The difference matters.

Every signal shows where and why. Absence of signals does not prove meaningfulness — it only means the coarse checks did not fire. That sentence is in the code, in the docstring and in the API response.

2. Generation conditions — generation.py

A signature proves *who signed*. It does not prove *where the file came from*. Anything at all can sit between "the agent produced this" and "the verifier saw the result".

Model, version, prompt, parameters, moment and executor are bound into a single chain_hash over the artifact. Change any link and the binding stops matching.

Absence of a binding is explicit, not silent. Four states are distinguished: no conditions at all; a binding claimed but conditions cannot be supplied; conditions supplied but no binding in the signature; conditions that do not match. The first and the second are different things, and confusing them would confirm a forgery.

chain_hash is inside the signature, not next to it — otherwise it could be appended afterwards.

3. Verification without trusting us — signing.py

HMAC requires a secret, and the secret is only ours. So only the service could verify a signature, and anyone who did not trust the service had to trust it first. For a product about trust, that is a contradiction at the foundation.

Now Ed25519. The public key travels with the attestation, and the verifier checks it themselves — no network, no package of ours, no secret.

python3 attest/verify_standalone.py attestation.json

That script imports nothing from attest and opens no sockets. A test enforces both.

4. Authority — authority.py

Was the action permitted? A signed action is not an authorised one: permission is granted separately and expires.

Rules match drift.check exactly — amount, payee, audience, currency, window, intent. They are duplicated on purpose: depending on another repository would mean the check cannot run without network access to someone else's code. Six comparisons are cheaper to duplicate than to make unverifiable.

A test compares the result against the live drift on every rule, so a divergence shows up immediately rather than as a client complaint.

Absence of a mandate is a denial, never consent. A verifier who presents no permission has not demonstrated one.

Proof of Place — pop/1

A signed report about one physical site: what matched, what did not, what we could not check. The JSON is canonicalized with RFC 8785 (JCS) and signed with Ed25519. The verifier needs no network, no account and no server of ours.

python -m attest.pop_verify report.json --key public_key.txt

It prints the verdict and the reason, and exits 0 only for ok.

Verify offline in seven steps:

1. Get report.json, report.pdf and public_key.txt through two different channels. The key is deliberately not inside the report.
2. Save the key in a separate folder, so the report/key pair cannot be swapped in one move.
3. Run python -m attest.pop_verify report.json --key public_key.txt (Python 3.11+ and cryptography; nothing else).
4. Read verdict: ok. Any other verdict names the check that failed.
5. Compare sha256sum report.pdf with pdf_sha256, or pass --pdf report.pdf and let the verifier do it.
6. Open limits and not_checked. If either is empty, the report violated our own spec and must not be accepted.
7. Match issuer.key_id against the key id we publish separately.

verify() also checks the layer chain (prev_hash → hash for every layer, including the first), so removing a layer or editing one hash breaks the report. It does not recompute the files inside the client ZIP — their hashes are covered by the chain, but the bytes are not in the JSON. It does not prove GPS honesty or ownership; those limits travel in the report itself.

Building a report from client photos — pop_build

python -m attest.pop_build --photos photos/ --claim claim.json \

--key private.key --out report.json python -m attest.pop_verify report.json --key public_key.txt

claim.json is what the client asserts before we look at the files:

{

"subject": {"type": "parcel", "ref": "client-ref-1"}, "claim": "40 ha, solar farm, operational", "location": {"lat": "52.123456", "lon": "4.654321"}, "captured_at": "2026-11-02T11:20:00Z" }

captured_at and subject.ref/subject.claim are required; a broken coordinate ("lat": "52,1") stops the build instead of turning into "not declared" — a typo must not be reported as a missing fact. Every file in --photos is hashed for the content layer. EXIF is read when present: DateTimeOriginal and GPS go to position, and the first photo that carries GPS is named in the layer.

Tolerances. 500 m for coordinates and 2 hours for capture time are constants in attest/pop_build.py. 500 m is not the precision of a GPS fix (5–20 m); it is the size of the thing being claimed. A 40-hectare parcel has a side of ~630 m, so a photographer standing at a corner while the claim names the centre honestly differs by hundreds of metres. Two different quarters, or two different fields, do not fall inside 500 m. For time, DateTimeOriginal carries no timezone and camera clocks drift by an hour or two; a different day is a different object, so a day-old photo must not pass as today's.

Ceiling without an independent source. The builder has no satellite or partner capture, so independent is written as not_available — never invented. pop/1 forbids confirmed next to an unavailable layer, so a photos-only report tops out at partial. Pass --independent source.json ({"source": "sentinel-2", "result": "match", "asset_ref": "…"}) when a real independent look exists; only then can confirmed be reached. location.basis says exif_gps or claimed, so a report never hides which one it stands on.

A finding worth stating plainly

While building layer 3, this was found in the existing code: with ATTEST_SECRET unset, signatures were computed with attest-dev-key-do-not-use-in-production, hardcoded in the source. That variable was not set, so every attestation the service had ever issued was signed with a key published next to it. Anyone could have signed an artifact as if the service had verified it.

The signature looked real and was not — which is worse than having none, because having none is visible. It is fixed: with no key, there is no signature.

Try it in a browser

https://attest.rta.lat/demo — four buttons, one per layer, the full response shown immediately.

Public repo

https://github.com/mrpkk/attest

Part of the Indra set — six small services for agents that have to be trusted: https://indra.rta.lat

MCP server (Model Context Protocol)

attest is an MCP server: it speaks the Model Context Protocol over Streamable HTTP (JSON-RPC 2.0) and exposes the verifier as MCP tools.

• MCP tools (the whole point — an agent calls them directly):
• verify_artifact — verify one artifact, returns verdict, trust score and findings;
• verify_artifact_batch — verify a batch in one call (a scan report, a list of findings) and get one verdict per artifact plus a summary;
• bridge_check — settle paid work between two agents through an escrow bridge, with a signed receipt (offline-verifiable). Optional: it is listed only on a node configured with an escrow bridge, so the public node returns two tools from tools/list. The call stays in the code and answers with a clear "bridge not configured" error instead of vanishing mid-session.
• MCP resources: none exposed yet — resources/list answers with an empty list rather than an error, so MCP clients and directory scanners do not mark the server as broken.
• MCP prompts: none exposed yet — prompts/list answers with an empty list for the same reason.
• Transport: Streamable HTTP, no auth for the free tier, X-ATTEST-ENTITLEMENT header for a pr