attest — verification for AI agent artifacts

io.github.mrpkk由 GitHub 帳號 mrpkk 發布v0.1.1更新於 Nov 4, 2026

Verify artifacts produced by AI agents: schema, emptiness, provenance, authority.

發布方自己的服務:artifacts.boo

已驗證Streamable HTTP可網頁執行開發者工具安全與監控AI 與機器學習

概覽

AI 產生的概覽

遠端 MCP 伺服器,用來驗證 AI 代理產出的產出物(結構描述、空洞內容、來源與授權),並回傳附簽章的判定結果。

可以做什麼
  • 依四個層面驗證單一產出物:結構描述一致性、空洞內容訊號、與雜湊綁定的生成來源,以及是否有已簽章授權允許該動作
  • 一次呼叫批次驗證多個產出物,為每個產出物給出判定,並彙總通過、待複核與遭拒的數量
  • 回傳判定、信任分數、各層檢查結果、發現項目,以及可離線核驗的 Ed25519 簽章
  • 在設有託管橋的節點上,可選擇透過託管橋結算兩個代理之間的付費工作
適用情境
當代理要使用來自外部工具或其他代理的產出物,並希望在採納、據此行動或付款前先做檢查時適用。也適合需要在產出物遭拒時讓建置失敗的流程。
執行需求
遠端 Streamable HTTP 端點;免費額度不需安裝、SDK 或註冊。預付金鑰放在 X-ATTEST-ENTITLEMENT 標頭,按次付費使用 PAYMENT-SIGNATURE 或 X-PAYMENT。需要網路存取。
安裝前請注意
免費額度為每個用戶端每天 5 次檢查,超過後回傳 HTTP 402,需以 Base 上的 USDC 透過 x402 付費或使用預付金鑰,費用可能累積。送出的產出物會傳到第三方託管服務。README 揭露:未設定 ATTEST_SECRET 時,早期證明曾以硬編碼的開發金鑰簽章,因此舊簽章不應被信任。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 attest — verification for AI agent artifacts,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。

交給代理程式安裝

把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式,或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南,先向你展示發布者、端點和登入方式,經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。

閱讀 https://sourceweft.com/mcp/io.github.mrpkk%2Fattest/install.md,並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前,先告訴我它的發布者、端點和登入方式,等我確認。不要把 API 金鑰寫進命令或我會提交的檔案;問我金鑰應從哪裡取得。

檢視代理程式所依據的安裝指南

其他 MCP 客戶端

把它新增到你客戶端的 mcpServers 設定中。

{
  "mcpServers": {
    "attest-verification-for-ai-agent-artifac": {
      "type": "http",
      "url": "https://attest.rta.lat/mcp"
    }
  }
}

README

attest — trust layer for agent artifacts

[M8ven Score] [Listed on mcpservers.org] [mrpkk/attest MCP server]

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 →

Live: https://attest.rta.lat/demo · Receipts: https://attest.rta.lat/receipts · Offline verifier: https://attest.rta.lat/verify-offline · Docs: https://attest.rta.lat/docs · Refusal evidence for agents ($99 / 30 days): 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. No dependencies, 750 tests (746 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.

bash
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.

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 prepaid key, PAYMENT-SIGNATURE/X-PAYMENT for a per-call x402 payment.

Connect an MCP client

json
{  "mcpServers": {    "attest": { "url": "https://attest.rta.lat/mcp" }  }}

Claude Desktop, Claude Code, Cursor, Codex, VS Code and any other MCP client that supports remote Streamable HTTP servers work with that block as is.

We use it ourselves: our own agents call this exact URL through the MCP SDK in opencode.jsonc, so the server is exercised by real traffic every day, not only by the tests.

Tool reference

Both tools take plain JSON. No SDK is needed.

verify_artifact
fieldtyperequiredmeaning
artifactobject | array | stringyeswhat to verify
schemaobjectnoJSON Schema the artifact must satisfy
sourcestringnowhere the artifact came from; recorded in the verdict

Request:

json
{"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"verify_artifact",           "arguments":{"artifact":{"findings":[{"rule":"x","severity":"high"}]},                        "source":"nightly-scan"}}}

Response (one verdict, signed):

json
{"verdict":"accept","trust_score":0.86, "checks":[{"layer":"schema","ok":true},{"layer":"emptiness","ok":true},           {"layer":"generation","ok":true},{"layer":"authority","ok":true}], "findings":[], "signature":{"algorithm":"ed25519","public_key":"...","signature":"..."}}
verify_artifact_batch
fieldtyperequiredmeaning
artifactsarrayyesone verdict per element
schemaobjectnoapplied to every element
sourcestringnorecorded once for the batch
json
{"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"verify_artifact_batch",           "arguments":{"artifacts":[{"a":1},{"a":2}],"source":"batch"}}}

Response: {"verdicts":[...],"summary":{"accepted":1,"rejected":1,"total":2}}.

When the free tier runs out

The free tier is 5 checks per day per client. On the 6th call the server answers HTTP 402 with a body naming the limit, and a Payment-Required header carrying the x402 terms:

json
{"error":"free limit reached (5/5 per day)","free_remaining":0,"resets_at":"00:00 UTC", "x402":{"enabled":true,"network":"eip155:8453","asset":"0x8335...2913",         "price_atoms":5000,"pay_to":"0x..."}}

An MCP client sees that text as a tool error — nothing hangs and nothing is retried blindly. To continue, repeat the same call with PAYMENT-SIGNATURE (per-call x402, USDC on Base) or with X-ATTEST-ENTITLEMENT (a 30-day prepaid key). The free quota resets at 00:00 UTC.

Maintenance

Maintained and general-purpose, MIT-licensed. The hosted node at https://attest.rta.lat is production and is exercised daily by our own agents, so it is not a demo that rots. Breaking protocol changes get a major bump in CHANGELOG.md; issues and pull requests are reviewed. Security reports follow SECURITY.md.

Use it in CI

A one-off check in a browser does not protect a pipeline. This repository ships a composite GitHub Action: it verifies every artifact file and fails the build on a rejection. Pinned to v1 — release v1.0.0.

yaml
- uses: mrpkk/attest@v1  with:    paths: 'reports/*.json'    schema: 'schemas/scan.schema.json'   # optional    fail-on: reject                      # or 'any' to fail on violations too

Without Actions, the same check runs locally:

bash
python3 scripts/verify_artifacts.py 'reports/*.json' --fail-on reject

Exit codes: 0 all accepted, 1 a rejection or an error, 2 nothing matched. A network error or an exhausted free quota is reported as an error — never as "accepted".

Use it from your agent

json
{  "mcpServers": {    "attest": { "url": "https://attest.rta.lat/mcp" }  }}

That block is not a doc snippet — it is how our own agents call this server (the same public URL, no key, no signup).

Tools: verify_artifact, verify_artifact_batch. 5 free checks per day, then $0.005 per call over x402 (USDC, Base) or $99/30 days. India pricing: $49/30 days.

來源:README.md,提交 e29412b

工具

2

verify_artifact

Verify an AI agent artifact

Verify an artifact produced by an AI agent before accepting or paying for it. Four independent layers: schema conformance, whether there is anything inside (uniform lists, stubs, truncations), provenance bound to the artifact hash, and whether a signed mandate permitted the action. Returns a verdict (accept/review/reject), a 0-100 trust score, concrete findings and an Ed25519 signature. Rule-based, no LLM: the same artifact always yields the same result. Use before accepting work from another agent and before payment.

輸入參數schemasourceartifact必填

verify_artifact_batch

Verify a batch of AI agent artifacts

Verify several artifacts at once — a scan report, a list of findings, a set of tool descriptions. One call, one verdict per artifact, plus a summary of how many were accepted, need review, or were rejected. Use when an agent produced a batch (twenty findings from a security scan, for example) and each of them has to be checked before the work is paid for.

輸入參數schemasourceartifacts必填

版本歷史

2
  1. v0.1.1最新Nov 4, 2026
  2. v0.1.0Oct 15, 2026

評分

已滿足適用檢查項的 100%

該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。

  • 近 30 天內可連通必需25 分
  • 已宣告認證方式必需10 分
  • 已列出工具必需15 分
  • 描述必需15 分
  • 圖示10 分
  • 文件15 分
  • 授權條款10 分

其他 Artifacts 整合