For platform engineering, AI infrastructure, and security teams running MCP tools

Authorize one agent action. Retry with the same key, no new dispatch.

An agent issues a customer refund through an internal MCP tool. The call times out, the agent retries, and the refund runs twice. If preventing it cannot justify this boundary, I will tell you.

Start a pilot by email Run the local proof

Paid pilot · one internal MCP tool · production rollout by pilot · Try it free: get a demo key

governed loop · recordedmake prove-trust-plane · 
  1. POST /v1/permits
  X-API-Key: $OPERATOR_API_KEY
  Idempotency-Key: demo-permit-1
    permit_id
    permit-74d8473ec86c4b42
    allowed_tools
    ["trust-plane-echo"]
    max_credits
    25
    expires_at
    2026-09-08T08:03:18
    key_id
    demo-ed25519

    One tool, one agent identity, a budget, an expiry, signed by the operator's key. The agent cannot mint this for itself.

  2. POST /mcp/messages
  X-API-Key: $AGENT_API_KEY
    receipt_id
    rcpt-038c84a3d94d4a34
    outcome
    success
    credits_charged
    2
    ledger_entry_id
    60055228-a465-4d11-84c2-16b72ea26e3c
    permit_id
    permit-74d8473ec86c4b42

    The gateway dispatches, debits the scoped budget, and returns a signed receipt that names the permit and the ledger entry.

  3. POST /mcp/messages
  X-API-Key: $AGENT_API_KEY
    receipt_id
    rcpt-038c84a3d94d4a34
    outcome
    success
    credits_charged
    2
    ledger debits for this tool
    1

    Same receipt id, no second dispatch, no second debit. A timed-out client can retry without fear.

  4. b2a-verify-receipt --bundle receipt.json --keys trust-keys.json
    VERIFIED  rcpt-038c84a3d94d4a34
  signed by   demo-ed25519
  permit      permit-74d8473ec86c4b42
  tool        trust-plane-echo
  outcome     success
  credits     2 charged of 2 authorized
  at          2026-09-08T07:33:18.252834+00:00

    The SDK verifier checks the Ed25519 signature against the published key set. It never imports the gateway.

Recorded from a local gateway run, not the live API. Every line is a real request or a real response. Read the full recording.

Agent Middleware API is a transaction boundary between your agents and your consequential MCP tools. For a finalized request, a retry with the same accepted key and payload returns the original signed receipt instead of dispatching again. A new key is a new request.

The wedge today is metered calls. The underlying primitive is bounded authority for machine actions.

A credit is a closed-loop metering unit for the pilot on an operator-provisioned wallet, not payment rails. The gateway reserves the tool's credit price against the permit before anything runs, and writes at most one ledger debit per accepted idempotency key. A denied call is never charged; a call the gateway can prove never reached the tool is refunded. Once committed to sending on the configured upstream path, it cannot prove the tool did not run: a timeout or a crash from that point stays charged, and is never retried for you. Refunding an ambiguous call automatically would pay a caller to induce timeouts against a tool that already did the work. Credits never become invoices, settlement, or payment rails, and the pilot is priced separately, in writing.

The governed boundary An agent's tools/call passes through the governed boundary (permit, scope, budget and expiry, replay protection, signed receipt) before it reaches the tool. A dashed direct route from the agent to the tool is marked closed by the operator, so the boundary is the only path. AGENT decides intent tools/call GOVERNED BOUNDARY permit scope budget · expiry replay protection signed receipt authorized metered TOOL consequential action direct route: closed by the operator
The gateway becomes the only path once you close the tool's other routes.

00 / Operational problem

Agent intent is not authority or evidence.

  1. Before Bound the authority

    Agent identity, tool, scope, budget, and expiry.

  2. During Prevent a second debit

    One accepted request key cannot become a second debit.

  3. After Return portable proof

    A signed receipt links the governed call to auditable evidence.

01 / Governed path

One control loop from intent to evidence.

Discover, authenticate, authorize, invoke, meter, receipt, audit, govern, recorded from make prove-trust-plane. The tool in the recording is a stand-in echo tool, not a refund tool.

governed loop · recordedmake prove-trust-plane ·

  1. 01 · Discover

    The agent reads the manifest.

    GET /mcp/tools.json
  X-API-Key: $AGENT_API_KEY
    name
    trust-plane-echo
    creditsPerCall
    2
    unitName
    call
    requirePermit
    true

    Which tools exist and what each call costs. Discovery is public; nothing here can be invoked yet.

  2. 02 · Authenticate → 03 · Authorize

    The operator issues one scoped permit.

    POST /v1/permits
  X-API-Key: $OPERATOR_API_KEY
  Idempotency-Key: demo-permit-1
    permit_id
    permit-74d8473ec86c4b42
    allowed_tools
    ["trust-plane-echo"]
    max_credits
    25
    expires_at
    2026-09-08T08:03:18
    key_id
    demo-ed25519

    One tool, one agent identity, a budget, an expiry, signed by the operator's key. The agent cannot mint this for itself.

  3. 04 · Invoke → 05 · Meter → 06 · Receipt

    The call executes and is charged once.

    POST /mcp/messages
  X-API-Key: $AGENT_API_KEY
    receipt_id
    rcpt-038c84a3d94d4a34
    outcome
    success
    credits_charged
    2
    ledger_entry_id
    60055228-a465-4d11-84c2-16b72ea26e3c
    permit_id
    permit-74d8473ec86c4b42

    The gateway dispatches, debits the scoped budget, and returns a signed receipt that names the permit and the ledger entry.

  4. 05 · Meter, again

    The same idempotency key comes back.

    POST /mcp/messages
  X-API-Key: $AGENT_API_KEY
    receipt_id
    rcpt-038c84a3d94d4a34
    outcome
    success
    credits_charged
    2
    ledger debits for this tool
    1

    Same receipt id, no second dispatch, no second debit. A timed-out client can retry without fear.

  5. 06 · Receipt, offline

    The receipt verifies with no credential and no callback.

    b2a-verify-receipt --bundle receipt.json --keys trust-keys.json
    VERIFIED  rcpt-038c84a3d94d4a34
  signed by   demo-ed25519
  permit      permit-74d8473ec86c4b42
  tool        trust-plane-echo
  outcome     success
  credits     2 charged of 2 authorized
  at          2026-09-08T07:33:18.252834+00:00

    The SDK verifier checks the Ed25519 signature against the published key set. It never imports the gateway.

  6. 07 · Audit

    The ledger's event chain still verifies.

    POST /v1/audit/verify-chain
  X-API-Key: $AGENT_API_KEY
    valid
    true
    checked_events
    1

    Every event is hash-chained to the one before it. Edit a stored row and the chain breaks, which the demo also proves.

  7. 08 · Govern

    An out-of-scope tool is refused at the boundary.

    POST /mcp/messages
  X-API-Key: $AGENT_API_KEY
    error
    permit_tool_not_allowed
    receipt_id
    rcpt-f9f49fdda0294493
    outcome
    denied
    ledger_entry_id
    null

    The permit named one tool. Asking for another is denied before dispatch, receipted as a denial, and never charged.

Gateway time per governed call in this run: p50 67.3 ms, p95 83.7 ms over 100 fresh calls (in-process ASGI client, local SQLite, no network). Recorded on one machine, on the local governed-tool path with a stand-in echo tool and no upstream dispatch: a reference point, not a production number. The pilot records yours.

Recorded from a local gateway run, not the live API. Every line is a real request or a real response. Read the full recording.

02 / Portable evidence

Inspect the receipt, then verify it offline.

This self-issued gateway receipt is published as a historical sample from a non-sensitive partner.echo call on , and it is not customer traction. The bundle ships the public-key snapshot the offline verifier used. Verifying it proves that signature against that key; it is not a test of the deployment running today.

Published signed claims loading artifact
receipt
loading…
tool
loading…
charged
loading…
key
loading…
offline verifier · published sample receiptb2a-verify-receipt
b2a-verify-receipt --bundle receipt.json --keys trust-keys.json \
    --expect-issuer https://api.thisisatest.tech
VERIFIED  rcpt-9daf745e477d45ab
  signed by   railway-prod-ed25519
  permit      permit-c73a0b621c244831
  tool        partner.echo
  outcome     success
  credits     1 charged of 1 authorized
  at          2026-08-11T21:17:28.064620+00:00

The SDK verifier checks the Ed25519 signature with no API credential and no callback to the issuer. Authenticate the key snapshot through a trusted channel first. Download the artifacts and run it yourself.

03 / Design-partner pilot

Start with one tool, not a platform migration.

Bring one internal MCP tool, such as a refund tool, a deploy trigger, or a payout call, with a retry or audit concern. Send the scenario by email for a written answer on fit; if it fits, I walk the action through the full loop.

What the pilot includes

  • One partner-owned agent, one staging MCP tool, one consequential action, one named partner engineer.
  • A staging environment on synthetic or redacted data, with a written scope and end date.
  • An acceptance flow: repeat the request, confirm no second dispatch or debit, verify the receipt offline.

Five things for your email

  1. The tool or action. What the agent calls and what changes, for example a refund tool, a deploy trigger, or a payout call.
  2. What goes wrong on retry.
  3. How you check it happened. How you check whether the action ran, and ran once.
  4. What one duplicate or unproven call costs. Lost money, recovery hours, or a concrete customer consequence. Unknown is an acceptable answer.
  5. Who owns the budget and when they decide.

Use synthetic or redacted examples only. Never send production secrets, credentials, or customer data.

One tool, one operator, one action. Clone the public source repository to run make prove-trust-plane locally without live API credentials.

Start a pilot by email Email 1@christophersellers.com

Does avoiding duplicates justify the cost?

Take the refund example: each duplicate is one refund paid twice, plus recovery hours. Monthly actions × duplicate rate × loss per duplicate × expected reduction = estimated monthly avoided loss. Use the loss you bear, not the full transaction value.

Expected reduction is an assumption about your whole adopted workflow to validate in a pilot, not a gateway guarantee. These numbers stay in your browser and are never sent to me.

Illustrative example: how a $35 threshold is calculated

100,000 actions/month × 0.1% duplicates × $50 actual loss × 80% reduction = $4,000/month avoided. At $2,800 monthly cost, break-even is $35 per duplicate. At 0.01% duplication, the threshold rises to $350. Illustrative assumptions, not my pricing or measured results.

04 / Machine discovery

Public pointers for agents and operators.

Public discovery pointers need no key. Get a free sandbox demo key at /demo-key/ with no account needed. Production keys are issued to design partners. Governed tool calls require a key and a scoped permit.

Agent manifest GET /.well-known/agent.json Agent instructions GET /llms.txt MCP discovery GET /mcp/tools.json Live dependency status GET /health/dependencies

Three unauthenticated GETs open directly: the agent manifest, llms.txt, and dependency status. On production-like deployments, /mcp/tools.json returns 401 without a key. The local quickstart exposes the catalog without a key.

05 / Honest limitations

What this proof does not establish.

  • Customer traction or production adoption
  • Production settlement or payment rails
  • Compliance-grade ledger storage
  • Proof that upstream tools avoid duplicate side effects
  • Universal governance across every agent framework

06 / Who is behind this

Built and run by one accountable operator.

Built and run by Christopher Sellers.

Product wedge · Security limitations · Source repository

Bring one tool. Keep the evidence.

Start a pilot by email Run the local proof