Resolve, read, invoke, receipt: the four calls a stranger&#39;s agent makes

When nothing matches, the answer says so

bash

curl -s "https://miscsubjects.com/api/dispatch?ask=zzzqqwx"

json

{ "count": 0, "best": null,
  "note": "No capability matched. GET /api/dispatch?registry=1 for the full list, or refine the words.",
  "registry": "https://miscsubjects.com/api/dispatch?registry=1" }

The parallel failure is a key that does not exist. Invoke catches it through didYouMean (functions/api/dispatch.js:1914-1925), which runs a bounded Levenshtein of edit distance ≤3 plus a substring pass over every key (nearestKeys, lines 1830-1836):

json

{ "error": "unknown_key", "attempted": "NOW_TIME", "ran": false,
  "did_you_mean": [ { "key": "NOW", "read": "https://miscsubjects.com/api/dispatch?key=NOW" } ],
  "fix": "You invoked a key that does not exist. Nothing ran. Use one of did_you_mean (GET its ?key= for the exact call), or GET ?ask=<what you want in plain words> to find the right one." }

ran: false is the load-bearing field. The response also carries an HTTP header: x-ms-agent-note: Do not tell the user this worked — nothing ran. A key far enough away from everything, such as CURRENT_TIME, returns an empty did_you_mean and a different fix string pointing at ?ask= and ?registry=1.

First-party: the resolver ranking a live query, 2026-07-25

Method: `curl -s "https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it"`. Twelve ranked candidates, `NOW` first by pin, with GITHUB_LIST_ISSUES at position two because the two-letter terms `is` and `it` are substrings of `issues`. Rerunnable by anyone with no credential.

Step 2 hands over one manual, not a schema

bash

curl -s "https://miscsubjects.com/api/dispatch?key=NOW&format=markdown"

4,423 bytes, complete, printed here with nothing removed but the token placeholders:

text

## §SELF — miscsubjects capability (paste without context)
**Principle:** Self-explaining payload — no external context required.
**Path:** OIP > NOW > NOW
**Capability:** `NOW` — Return the current time from the build clock in Pacific time
(America/Los_Angeles). WHEN_TO_USE: any object or model that needs the current date or time.
ARGS: none EX: [NOW][/NOW] OUTPUT: { now, today, time, zone, iso }
**RUN NOW (open this URL):** https://miscsubjects.com/api/dispatch?invoke=NOW&share=<TOKEN>
- **run it:** POST https://miscsubjects.com/api/dispatch {"key":"NOW","body":"<args>"}
- **inputs:** {"args":"none"}
- **outputs:** { now, today, time, zone, iso } — Pacific-offset ISO
- **auth · risk:** none · low
### What this token can do here (computed for: public)
- **contract** — GET …?key=NOW&format=markdown → this object's full contract
- **confirm** — GET …?confirm=INV_ID → public proof that an invocation happened
### Machine Contract
- Read this article first; do not infer the row shape from memory.
- If the call returns ran:false or proof.ok:false, read the receipt and repair the failed
  invocation instead of narrating success.
- If the token denies the call, report the denial exactly; do not switch to a broader action.
### Invocation, Ledger, Repair
- append-only ledger: https://miscsubjects.com/api/invocations?object_id=NOW
- receipt pattern:  https://miscsubjects.com/api/dispatch?receipt=inv_ID&share=<TOKEN>
- replay: POST /api/dispatch {"replay":"inv_ID"}
- repair: POST /api/dispatch {"key":"NOW","body":"corrected args","repairs":"inv_ID"}
### Troubleshooting
- **unknown key** — Use the did_you_mean links or ask URL; never guess another key.
- **argument/body mismatch** — Read inputs/example_args here, then retry with repairs: inv_ID.
- **expired or corrupted token** — Report token_expired/token_corrupted from the response.
- **tool returned ok:false / exit nonzero** — Do not call it sent. Read the receipt, fire a repair.

Five things are in there and each answers a question a cold agent would otherwise guess at. Inputs and outputs answer what do I send and what comes back. Run-now answers what if my only tool is opening a URL. The affordance block, headed "computed for: public", answers which of these moves will my credential actually survive; it is computed against the presented token, so an anonymous reader sees two operations and an owner sees nine. The machine contract answers what do I do when it fails, in imperative sentences aimed at a model rather than a person. Troubleshooting is the same four failures this page catalogues below, shipped inside every contract so the fix travels with the tool.

The field-by-field definition of the row that generates this block is in what a directory row is. What is relevant here is the size: 4,423 bytes for one capability, fetched only when a capability has been chosen. The 876-row registry is 1,606,794 bytes.

First-party: one capability contract, 4,423 bytes, 2026-07-25

Method: `curl -s "…?key=NOW&format=markdown" | wc -c` → 4423. Compare `curl -s "…?registry=1" | wc -c` → 1606794 over 876 rows. The measured ratio between reading one contract and loading the catalogue.

Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud

Step 3 runs it, and the denial names which of five things went wrong

NOW needs no credential to read, but every invocation is authenticated. There is no anonymous write plane.

bash

curl -sS -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" \
  -H "content-type: application/json" \
  -d '{"key":"NOW","body":""}'

Real response, trimmed:

json

{ "ok": true, "ran": true, "kind": "invocation_result", "trace": "t_06myig2y",
  "result": "{\"now\":\"2026-07-25T22:02:44-07:00\",\"today\":\"2026-07-25\",\"zone\":\"America/Los_Angeles\"}",
  "cost": 0,
  "proof": { "ok": true, "did": "DONE — NOW", "invocation_id": "inv_yu9ni6w7y9",
             "confirm": "https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9",
             "receipt": "https://miscsubjects.com/api/dispatch?receipt=inv_yu9ni6w7y9" },
  "invocation": { "actor": "owner:terminal-key",
    "fingerprints": { "algorithm": "sha-256",
      "input":  "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "output": "db21d92eaed3b25df5e97a1e72f9a70c5b2db351197db71c388f4e98e08b0b3b",
      "contract": "b359611ee57c925ee9e4d93b80f2a4533dd214c61c45b77f694c2650e917c977" } } }

body is a pipe-joined positional argument string: "" when the capability takes none, "open||30" for a three-argument row. The same two fields invoke every row in the catalogue.

A share token is a row, a clock and a use count, and it can only ever shrink

The owner mints a scoped link instead of handing out the master key:

bash

curl -s -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?mint_share=1&scope=row:NOW&ttl=1&purpose=article-measurement"

That returned fingerprint cap_ae711ea248b13828, scope row:NOW, risk_ceiling: low, expires_at: 2026-07-25T21:37:47-07:00, and contract pin b359611e…. The response states the rule: this row token fails closed if the current object contract no longer has this fingerprint. Editing the capability revokes every token minted against the old version of it, automatically.

The token also explains itself to whoever holds it, at ?explain=1&share=<TOKEN>, and the delegation law it publishes is the macaroon rule: a holder may mint only an equal-or-narrower child; child uses are reserved from the parent; payload ceilings inherit or shrink; every invocation validates all ancestors. Birgisson and colleagues described the underlying construction as credentials that "embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests."

Google Research / NDSS

The construction the share-token rules restate: a holder may mint only an equal-or-narrower child, and every invocation validates all ancestors. Reading this explains why scope_mismatch is a first-class denial rather than a generic 403.

↗ research.google.com

Every denial, measured live against that token:

What was presented	Response	HTTP	Why it is a distinct string
nothing at all	`token_corrupted`, `can_act: false`, `ran: false`	401	no anonymous invoke plane exists
the token, invoking `NOW` (in scope)	`ok: true`, actor `cap:cap_ae711ea248b13828`	200	the allowed case
the token, invoking `TIME_NOW` (out of scope)	`scope_mismatch` + `"This token is LIVE, but it is not allowed to invoke TIME_NOW… it is not expired."`	401	scope failure is not a clock failure
the token with its last 6 characters cut	`token_corrupted` + `"almost always because the link was TRUNCATED or altered on copy-paste"`	401	truncation is the common cause and is not expiry
the same token 76 seconds after a 60-second TTL	`token_expired` + `"Your token is EXPIRED. Nothing was sent or run."`	401	expiry is recoverable by minting; truncation is recoverable by re-copying

Separating token_corrupted from token_expired is a deliberate cost. The function that does it, tokenDead (functions/api/dispatch.js:1928-1942), runs a second signature parse purely to tell the two apart, because a model told "your token went bad" will mint a new one when it should have re-copied the link. Every denial also carries x-ms-agent-note: Do NOT tell the user it worked — it did not.

First-party: the contract names token failure recovery

The public capability contract tells a cold caller to preserve the server's separate token_expired and token_corrupted errors. The dated scope_mismatch, truncation and expiry responses remain in the body as runtime observations; no bearer token is published.

Denied attempts are ledgered under the fingerprint before the 401 is returned (functions/api/dispatch.js:3497). A denial is evidence, not silence. That is the point of the signed denial receipts euan21 built into Capframe: "revocable, signed denial receipts (HMAC-SHA256)."

1.▲Show HN: Capframe – capability tokens for AI agent tool calls

discuss by euan21

revocable, signed denial receipts (HMAC-SHA256).

1.▲Comment on: Ask HN: How are you enforcing permissions for AI agent tool calls in production?

discuss by kxbnb

The audit trail piece is critical too. Being able to answer "why was this blocked?" after the fact builds trust with teams rolling this out.

Step 4 exists because an agent asked to prove its own work invented the proof

This is the strongest argument on the page and it is not this system's argument. In a controlled two-condition experiment reported on Hacker News in March 2026, an agent running without runtime enforcement "fabricated an audit record — invented a governance event that never happened and presented it as compliance evidence." The fix the authors shipped was structural rather than behavioural: write the audit record from the engine, not from the agent, and chain it with SHA-256.

1.▲Comment on: Agent Runs Code You Never Wrote

discuss by zippolyon

fabricated an audit record — invented a governance event that never happened and presented it as compliance evidence.

That is the design here. The receipt is written by the dispatcher after the runner returns, in the same code path that produced the result, and the acting model has no write access to it. The alternative is an agent that reports success and produces no record. Sidk24 described that state after an agent modified 47 files and broke a build: "there is no structured trace, no cost attribution per task, no permission audit trail, and no session replay." Four missing things; the receipt object below carries all four.

1.▲Comment on: observability for AI agents (author comment)

discuss by sidk24

there is no structured trace, no cost attribution per task, no permission audit trail, and no session replay.

Two routes read it, and the split matters.

Public confirmation, no credential:

bash

curl -s "https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9"

json

{ "kind": "public_receipt/v2", "confirmed": true, "ok": true,
  "status": "PROVEN_MATERIAL_RESULT",
  "headline": "NOW produced material output at 2026-07-25T22:02:44-07:00.",
  "identity": { "invocation_id": "inv_yu9ni6w7y9", "actor": "owner:terminal-key",
                "disclosure": "Owner/CLI/legacy actor label; no bearer credential is exposed." },
  "integrity": { "fingerprints": { "algorithm": "sha-256",
      "input": "e3b0c442…b7852b855", "output": "db21d92e…e08b0b3b" },
    "tamper_rule": "Changing the recorded input, output, contract or lineage changes its
                    fingerprint or chain commitment." },
  "execution": { "private_payload_boundary": "Request and response content remain in the scoped
    forensic receipt. This public object exposes cryptographic fingerprints and navigable proof only." } }

An unknown id returns confirmed: false and "No such invocation — it did not happen." at HTTP 404. The negative is as citable as the positive.

First-party: the receipt for the invocation this page walks, 2026-07-25

Method: POST {"key":"NOW","body":""} with an owner key, take `proof.invocation_id`, then GET `?confirm=<id>` with no credential at all. The confirmation is openable by any reader of this page and returns the same SHA-256 output fingerprint quoted in the body.

Forensic receipt, credentialed:

bash

curl -s -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?receipt=inv_yu9ni6w7y9"

json

{ "kind": "receipt",
  "story": "owner:terminal-key invoked NOW → {\"now\":\"2026-07-25T22:02:44-07:00\"…} at 2026-07-25T22:02:44-07:00.",
  "receipt": { "id": "inv_yu9ni6w7y9", "trace_id": "t_06myig2y", "object_id": "NOW",
    "actor": "owner:terminal-key", "material": true, "waste": false,
    "tokens_in": 0, "tokens_out": 0, "cost_usd": 0,
    "event_id": "a2443e09-113e-44df-8718-848a98d11740",
    "request_full": "", "response_full": "{\"now\":\"2026-07-25T22:02:44-07:00\",…}",
    "replay_of": null, "repairs": null, "repaired_by": "inv_sbeb4t5ao2",
    "authorized_by": { "actor": "owner:terminal-key",
      "note": "not a recorded capability token (owner key, cli, or legacy share) — no token provenance record" } },
  "verbs": { "replay": { "method": "POST", "body": { "replay": "inv_yu9ni6w7y9" } },
             "repair": { "method": "POST", "body": { "key": "NOW", "body": "<corrected args>",
                                                     "repairs": "inv_yu9ni6w7y9" } } } }

Without a credential that route returns 401 with "receipt needs an owner access key, admin cookie, read/act token, or the exact scoped token that created this invocation." A tenant token reading another tenant's receipt gets tenant_receipt_isolation at 403.

RFC 9110: HTTP Semantics — safe and idempotent methods

The clause that licenses writing a receipt on a read: logging every request separately does not make a safe method unsafe. Directly relevant to `?confirm=` and to replay, which re-fires without being a retry.

[Subtask] feat(mcp-server): structured per-tool-call audit logging attributed to principal

request_full and response_full hold the bytes, not a summary. A summary of a failed call is somebody's opinion about the failure; the payload is the failure. The Apache Gravitino project reached the same field list from a different direction: "Emit a structured audit record for every MCP tool invocation, capturing the calling principal, tool name, and allow/deny outcome." Rafaself's gateway contract reached the opposite conclusion about bodies, specifying "structured audit logging for MCP tool calls without exposing credentials, signed request data, raw AWS responses, or CloudWatch log message contents." Both are defensible and they genuinely conflict. Gravitino's record is an operational audit trail; rafaself's is a cross-cutting log with an explicit non-goals list, designed to be safe to ship to CloudWatch. The split here follows neither: the public object is fingerprints-only, which is rafaself's position, and the credentialed object is full bytes, which is what debugging needs. The boundary is authorisation, not redaction.

apache/gravitino

An Apache project shipping the receipt step in code: an AuditLogger with timestamp, principal, tool, outcome and error_type, an AuditMiddleware in the chain, and acceptance criteria covering both allow and deny records. Positive, closed. Independent convergence on the same field list.

rafaself/aws-mcp-gateway

Add sanitized audit logging contract for MCP tool calls

The opposite conclusion about payload bytes: one JSON event per call with duration, tool name, outcome and error code, and an explicit non-goals list barring request/response bodies. Positive, closed — and a genuine disagreement with Gravitino, published here as a disagreement.

Replay repeats the input; repair supersedes it

Both are POST verbs on the same endpoint, both write new receipts, and they do different things to the lineage graph.

bash

curl -s -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
  -d '{"replay":"inv_yu9ni6w7y9"}'

Returned inv_53l71tl1i0 with replay_of: "inv_yu9ni6w7y9" and a link back to the source receipt. Replay reads the recorded request body out of the ledger event and re-fires the same object with the same input (functions/api/dispatch.js:3355-3370); the caller supplies no arguments. {"replay":…, "key":…} together is rejected: "replay and key are mutually exclusive" at HTTP 400. An unknown id is "unknown invocation" at 404. Replay also requires authority over the source receipt and its object, not just the object.

OpenTelemetry

OpenTelemetry — Traces

The existing model sidk24 proposes adapting instead of inventing a new one. Useful contrast: a span is an observation of work, a receipt is an addressable object with lineage and an authorisation boundary.

↗ opentelemetry.io

bash

curl -s -X POST https://miscsubjects.com/api/dispatch \
  -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
  -d '{"key":"NOW","body":"","repairs":"inv_yu9ni6w7y9"}'

Returned inv_sbeb4t5ao2 with repairs: "inv_yu9ni6w7y9". Then, re-reading the original receipt afterwards:

json

{ "id": "inv_yu9ni6w7y9", "replay_of": null, "repairs": null, "repaired_by": "inv_sbeb4t5ao2" }

The back-link is written after the new invocation logs, by linkRepairedBy (functions/api/dispatch.js:3482-3484). Nothing is mutated or deleted: the bad receipt keeps its bad payload and gains a pointer to its successor.

The Idempotency-Key HTTP Header Field (IETF draft)

The client-supplied approach to duplicate suppression. This dispatcher instead derives its key server-side from caller, capability and body over a 400 ms window, so a client that knows nothing about idempotency still cannot double-fire a burst.

↗ datatracker.ietf.org

	replay	repair
body you send	`{"replay":"inv_ID"}`	`{"key":…,"body":"corrected","repairs":"inv_ID"}`
input used	the recorded one, read from the ledger event	the new one you supply
forward edge on the new receipt	`replay_of`	`repairs`
back edge written on the old receipt	none	`repaired_by`
idempotency collapse applies	no	no
what it is for	reproducing a result, testing a fix to the runner	superseding a wrong call without erasing it

Repair is the reason did_you_mean and the argument-mismatch guidance both say retry with repairs: inv_ID so lineage closes: a corrected call that does not name what it corrects leaves a dangling failure in the ledger.

First-party: lineage after a replay and a repair of the same invocation

Method: POST {"replay":"inv_yu9ni6w7y9"} → inv_53l71tl1i0 with replay_of set; POST {"key":"NOW","body":"","repairs":"inv_yu9ni6w7y9"} → inv_sbeb4t5ao2 with repairs set; then re-read the original forensic receipt and observe repaired_by=inv_sbeb4t5ao2. The linked public repair confirmation exposes the forward lineage without exposing payload bytes.

The whole loop, copy-paste, ending in a URL anyone can open

bash

# 0. one credential, never printed
export TERMINAL_KEY="<your key>"

# 1. RESOLVE — plain words in, keys out
curl -s "https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['best']['key'])"
# -> NOW

# 2. CONTRACT — read it before calling it
curl -s "https://miscsubjects.com/api/dispatch?key=NOW&format=markdown"

# 3. INVOKE — and capture the receipt id
INV=$(curl -s -X POST https://miscsubjects.com/api/dispatch \
        -H "x-terminal-key: $TERMINAL_KEY" -H "content-type: application/json" \
        -d '{"key":"NOW","body":""}' \
      | python3 -c "import json,sys; print(json.load(sys.stdin)['proof']['invocation_id'])")
echo "$INV"
# -> inv_yu9ni6w7y9

# 4. RECEIPT — public proof, no credential
echo "https://miscsubjects.com/api/dispatch?confirm=$INV"
curl -s "https://miscsubjects.com/api/dispatch?confirm=$INV" \
  | python3 -c "import json,sys; d=json.load(sys.stdin); print(d['status'], d['headline'])"
# -> PROVEN_MATERIAL_RESULT NOW produced material output at 2026-07-25T22:02:44-07:00.

The URL that last block prints is openable by anyone, forever, with no credential: <https://miscsubjects.com/api/dispatch?confirm=inv_yu9ni6w7y9>.

Six failures, their exact strings, and what to do about each

Every string below was produced by a live call, not transcribed from documentation.

Symptom	Exact response	HTTP	Cause	Fix
Key does not exist, close to a real one	`{"error":"unknown_key","attempted":"NOW_TIME","ran":false,"did_you_mean":[{"key":"NOW",…}]}`	404	key guessed from memory instead of read from `?key=`	fire one of `did_you_mean`, then re-invoke with `repairs` set to the failed id
Key does not exist, close to nothing	`"fix":"No capability by that name. GET ?ask=<what you want> or ?registry=1 for the full list."`	404	wrong vocabulary entirely	go back to step 1
Argument or body mismatch	contract field `"argument/body mismatch" — "Read inputs/example_args here, then retry with repairs: inv_ID so lineage closes."`	200 with `ok:false`	positional pipe args in the wrong order or count	re-read `inputs` in the contract; re-fire with `repairs`
Token cut on copy-paste	`{"error":"token_corrupted","can_act":false,"ran":false,"problem":"Your token failed its signature check — almost always because the link was TRUNCATED…"}`	401	truncated URL, not an expired one	re-copy the entire link including the tail after the final dot
Token past its clock	`{"error":"token_expired","can_act":false,"ran":false,"problem":"Your token is EXPIRED. Nothing was sent or run."}`	401	TTL elapsed	owner mints a fresh scoped link
Token live but wrong row	`{"error":"scope_mismatch","fingerprint":"cap_ae711ea248b13828","note":"This token is LIVE, but it is not allowed to invoke TIME_NOW…"}`	401	attenuated token used outside its allow-list	ask for a wider link; never substitute a different capability
The tool itself failed	`{"ok":false,"ran":true,"result":"ERR:fn:D1_QUERY:D1_ERROR: no such table: no_such_table: SQLITE_ERROR"}`	200	the runner executed and returned an error	read the receipt, correct the body, fire a `repairs` call
Upstream HTTP error	`{"ok":false,"ran":true,"result":"ERR:http:404:{\"message\":\"Not Found\",…}"}`	200	remote API rejected the shaped request	same — the receipt holds the upstream body verbatim
Ran, produced nothing	`{"ok":true,"ran":true,"proof":{"ok":false,"did":"FAILED — "},"material":false}`	200	empty result, e.g. a KV key that does not exist	`proof.ok` tracks material output; `ok` tracks absence of an error string. They disagree here on purpose

ok is computed as !shaped && !failed, where failed is the regex /^(?:ERR(?::|$)|PROVIDER_ERROR(?::|$))/ over the result string (functions/_lib/object_contract.js:2191-2193). ran is !shaped; it distinguishes a real execution from a {"shape":true} dry run, which returns the fully-composed outbound payload and fires nothing.

RFC 9457: Problem Details for HTTP APIs

The standard this system does not follow. Its errors are bespoke JSON with `error`, `ran`, `problem` and `fix` fields rather than a `type`/`title`/`detail` problem document — a real interoperability cost, named here rather than hidden.

Every one of those failures still writes a receipt. inv_swzanrzqjo is the D1 error above; it is a real, permanent, addressable record of a call that did not work, with material: false. Outcomes include failure, or the ledger is a highlight reel.

First-party: failure receipts, three shapes, 2026-07-25

Method: invoke D1_QUERY against a missing table. The private result carried `ERR:fn:D1_QUERY:D1_ERROR: no such table: no_such_table: SQLITE_ERROR`; this public confirmation records that it ran, produced no material output, and remains auditable without exposing the payload.

What the loop costs, measured

Ten samples per endpoint from the same Mac in the Pacific timezone to the production Cloudflare edge, on 2026-07-25. The five calls below are the published harness. INV is the harmless NOW receipt id created by the runnable loop above.

bash

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  'https://miscsubjects.com/api/dispatch?ask=what%20time%20is%20it'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  'https://miscsubjects.com/api/dispatch?key=NOW&format=markdown'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  -X POST 'https://miscsubjects.com/api/dispatch' \
  -H "x-terminal-key: $TERMINAL_KEY" -H 'content-type: application/json' \
  -d '{"key":"NOW","body":""}'; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  "https://miscsubjects.com/api/dispatch?confirm=$INV"; done

for i in $(seq 10); do curl -s -o /dev/null -w '%{time_total} %{size_download}\n' \
  -H "x-terminal-key: $TERMINAL_KEY" \
  "https://miscsubjects.com/api/dispatch?receipt=$INV"; done

Step	min	median	max	response bytes
1 resolve `?ask=`	62.3 ms	66.7 ms	82.0 ms	12,332
2 contract `?key=…&format=markdown`	54.0 ms	97.9 ms	150.1 ms	4,423
3 invoke `POST {key,body}`	784.9 ms	940.3 ms	2,761.0 ms	15,675
4a confirm `?confirm=` (public)	58.5 ms	98.3 ms	1,770.5 ms	15,009
4b receipt `?receipt=` (credentialed)	66.0 ms	81.6 ms	114.5 ms	12,971

The median read step stayed between 66.7 and 98.3 milliseconds. The 940.3-millisecond invocation median was more than nine times the slowest read median. A POST does the work, then writes the invocation row, writes the ledger event, computes three SHA-256 fingerprints, and finalises the idempotency key before responding. Resolve + contract + invoke + public confirmation sums to 1,203.2 milliseconds at the medians; invocation accounts for 78.1% of it.

That overhead is at the high end of what the literature reports for enforcement layers, because it is doing more than policy evaluation. AgentWall, which intercepts and evaluates but persists asynchronously, measured "average decision latency is 0.198 ms and the p95 latency is 0.745 ms" over 14 policy tests. Agent-Sentry's deterministic provenance checks are single-digit milliseconds; its LLM-judge layer costs about 1.2 seconds per call, which is why it fires on only a small residual. The right reading: sub-millisecond is achievable for a decision, while this measured durable call took 940.3 milliseconds. Persistence and the runner are the combined cost; this harness does not isolate their shares.

AgentWall: A Runtime Safety Layer for Local AI Agents

Harness: 14 policy scenarios against a policy-enforcing MCP proxy, 92.9% enforcement accuracy. Sets the floor for what interception costs when the record is not durably persisted in the request path — two to three orders of magnitude below the ~800 ms this system spends writing one.

Agent-Sentry: Bounding LLM Agents via Execution Provenance

Harness: AgentDojo and AgentDyn. Layers a cheap deterministic provenance check under an expensive LLM judge, invoking the judge only on the residual — the design that makes per-call enforcement affordable, and the reason a model in the decision path is a latency choice rather than a requirement.

Cloudflare's published Workers Standard price is "10 million included per month +$0.30 per additional million" requests, with duration not billed. Four requests at the marginal rate is 4 × $0.30 / 1,000,000 = $0.0000012 per complete loop, or $1.20 per million loops. The D1 side is "First 25 billion / month included + $0.001 / million rows" read and "First 50 million / month included + $1.00 / million rows" written; each invocation writes an invocation row and a ledger event, so two writes, so $0.000002 per loop at the marginal rate. Total marginal cost of resolve + contract + invoke + receipt, with the receipt durably stored: about $0.0000032. Below the included tiers it is zero.

Cloudflare Workers pricing — Standard usage model

The rate card the per-loop arithmetic on this page uses. Positive: duration is not billed on Standard, so the four requests are the whole compute charge.

Cloudflare D1 pricing — billing metrics

The storage half of the loop cost: each invocation writes two rows, which is where the $0.000002 term comes from.

First-party: latency of each step, 10 samples per endpoint, 2026-07-25

Method: the five ten-sample curl loops published verbatim in the cost section, run from the same Mac in the Pacific timezone against the production edge. Every sample returned HTTP 200. The result is a first-party measurement attached to the exact endpoints measured, not a vendor performance claim.

What it replaces is the other way to make 876 capabilities reachable: put their definitions in the model's context. That comparison, with its own measurements, is 891 tools, zero tool schemas, and the projection of this same catalogue into MCP is MCP as a projection. The relevant number for this page is the one on the resolve step: a ?ask= response is 12,332 bytes and is fetched once, at the moment a capability is needed, by an agent that had zero of the catalogue loaded a second earlier.

Four honest weaknesses

Four round trips happen before any work does. For a single call that is roughly 600 ms of latency spent on discovery and reading before the invoke even starts. An agent that already knows the key skips straight to step 3, and any agent doing more than one call with the same capability should. The loop is a cold-start protocol, not a per-call tax; nothing enforces that, and a naive agent will re-resolve every time.

The resolver can miss and does. It is substring scoring with about twenty hand-pinned intents. Anything outside the pin list is at the mercy of term overlap between the user's words and the row's description, which is precisely the failure ToolRet quantified: even a strong general-purpose retriever managed nDCG@10 of 33.83 on tool retrieval, and worse retrieval measurably lowered downstream task pass rates. A miss here is visible in the ranked list, and the agent can reject it. It is still a real miss.

A model still has to decide correctly. Nothing in these four steps prevents an agent from reading the right contract and then choosing the wrong capability, or supplying plausible-looking wrong arguments. The receipt makes that visible afterwards. It does not prevent it. aderix put the general version of this sharply: "If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight." The runtime answers here are the risk ceiling on the token and the owner gate on high-risk rows. Both are real, and both are narrower than a general solution.

1.▲Comment on: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

discuss by aderix

If an LLM hallucinates in production and decides to execute a destructive tool defined in SKILL.md (like dropping a table or issuing a Stripe refund), a Git PR approval process doesn't help you mid-flight.

Nobody else implements this. ?ask=, ?key=, ?confirm=, ?receipt=, replay and repairs are the shapes one system chose. An agent that has internalised MCP will look for tools/list and tools/call. The specification says a client "SHOULD" keep "a human in the loop with the ability to deny tool invocations", leaving the record entirely to the implementation. Convergent work exists and is not compatible: Capframe splits the same loop into find, bind and guard with a public JSON Schema wire format; Rampart evaluates "every shell command, file operation, and MCP tool call … against your rules before it executes" behind a hash-chained trail; socket-link/ampere proposes to "enable agents to discover, select, and invoke MCP server tools through the existing Tool sealed interface, with tool availability emitted as events"; jithinraj's demo "emits a signed, portable receipt per tool call (JSON you can verify offline)". Four groups, four wire formats, one shape. Until one of them is a specification rather than a repository, a stranger's agent has to read the contract to know the shape. That limitation is the argument for step 2.

Model Context Protocol

Model Context Protocol specification — Tools (2025-06-18)

The spec an agent trained on MCP will look for: tools/list to discover, tools/call to invoke. It mandates no record of either, leaving step 4 entirely to implementations — which is why four projects have four incompatible receipt formats.

↗ modelcontextprotocol.io

1.▲Show HN: Rampart – Open-source firewall for AI agents (v0.8)

discuss by trevxr

Every shell command, file operation, and MCP tool call gets evaluated against your rules before it executes. Denied actions never run.

1.▲Show HN: Verify and trace OpenClaw tool calls (runnable demo)

discuss by jithinraj

emits a signed, portable receipt per tool call (JSON you can verify offline)

socket-link/ampere

[Ampere] Dynamic tool discovery and invocation for MCP

A discover-select-invoke-emit loop behind one uniform interface, with MCP tools sitting alongside local functions. Positive, closed. Same four beats as this page's loop under different names, which is evidence the shape is convergent and the wire format is not.

kxbnb, arguing for a proxy enforcement point outside the agent's context, named the thing all of these are actually for: "The audit trail piece is critical too. Being able to answer \"why was this blocked?\" after the fact builds trust with teams rolling this out." That question has an address here. It is ?confirm=, and it needs no credential to ask.

Evidence · 28 sources · swipe →chain 7521600511b0 · verify chain · provenance

1 / 28

Cloudflare Workers pricing — Standard usage model

The rate card the per-loop arithmetic on this page uses. Positive: duration is not billed on Standard, so the four requests are the whole compute charge.

Cloudflare D1 pricing — billing metrics

The storage half of the loop cost: each invocation writes two rows, which is where the $0.000002 term comes from.

Model Context Protocol specification — Tools (2025-06-18)

OpenTelemetry

OpenTelemetry — Traces

↗ opentelemetry.io

Model Context Protocol

↗ modelcontextprotocol.io

RFC 9110: HTTP Semantics — safe and idempotent methods

RFC 9457: Problem Details for HTTP APIs

The Idempotency-Key HTTP Header Field (IETF draft)

↗ datatracker.ietf.org

Google Research / NDSS

Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud

↗ research.google.com

AgentWall: A Runtime Safety Layer for Local AI Agents

Agent-Sentry: Bounding LLM Agents via Execution Provenance

Retrieval Models Aren't Tool-Savvy: Benchmarking Tool Retrieval for Large Language Models

arXiv / ACL Findings

1.▲Comment on: Agent Runs Code You Never Wrote

discuss by zippolyon

fabricated an audit record — invented a governance event that never happened and presented it as compliance evidence.

1.▲Comment on: observability for AI agents (author comment)

discuss by sidk24

there is no structured trace, no cost attribution per task, no permission audit trail, and no session replay.

1.▲Show HN: Capframe – capability tokens for AI agent tool calls

discuss by euan21

revocable, signed denial receipts (HMAC-SHA256).

1.▲Show HN: Rampart – Open-source firewall for AI agents (v0.8)

discuss by trevxr

Every shell command, file operation, and MCP tool call gets evaluated against your rules before it executes. Denied actions never run.

1.▲Show HN: Verify and trace OpenClaw tool calls (runnable demo)

discuss by jithinraj

emits a signed, portable receipt per tool call (JSON you can verify offline)

1.▲Comment on: Show HN: GitAgent – An open standard that turns any Git repo into an AI agent

discuss by aderix

1.▲Comment on: Ask HN: How are you enforcing permissions for AI agent tool calls in production?

discuss by kxbnb

The audit trail piece is critical too. Being able to answer "why was this blocked?" after the fact builds trust with teams rolling this out.

apache/gravitino

[Subtask] feat(mcp-server): structured per-tool-call audit logging attributed to principal

rafaself/aws-mcp-gateway

Add sanitized audit logging contract for MCP tool calls

socket-link/ampere

[Ampere] Dynamic tool discovery and invocation for MCP

First-party: the resolver ranking a live query, 2026-07-25

First-party: one capability contract, 4,423 bytes, 2026-07-25

First-party: the receipt for the invocation this page walks, 2026-07-25

First-party: the contract names token failure recovery

First-party: lineage after a replay and a repair of the same invocation

First-party: failure receipts, three shapes, 2026-07-25

First-party: latency of each step, 10 samples per endpoint, 2026-07-25