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

Authorize one agent action. Charge it once. Prove what happened.

An agent issues a customer refund through an internal MCP tool. The call times out, the agent retries, and without a boundary the refund runs twice. Someone pays in lost money, recovery time, or a customer problem. Put a number on that cost. If preventing it cannot justify this boundary, we will tell you.

Start a pilot by email Run the local proof

Paid, bounded pilot · one internal MCP tool · priced after fit is established · no self-serve rollout

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 autonomous agents and your consequential MCP (Model Context Protocol) tools. The first call executes and is charged once; a retry carrying the same idempotency key cannot dispatch again or debit again. Every completed call returns a signed receipt you can verify offline.

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 registered 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. But once it has committed to sending on the configured upstream path, it can no longer 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 had already done the work. Turning credits into invoices, settlement, or payment rails is out of scope by design, 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 sits between the agent and one tool, and becomes the only path to that tool once you close the tool's other routes. The agent decides what it wants; the operator decides what authority it holds.

00 / Operational problem

Agent intent is not authority—or evidence.

An agent can be correct and still exceed its mandate, retry an expensive call, or leave an operator unable to prove what ran. The gateway holds the authority at the resource boundary, so the agent's intent is checked against what it is actually allowed to do — before the tool runs.

The result is inspectable before, during, and after execution without asking you to replace your agent framework.

Built for agents. Controlled by operators. For the teams responsible for both.

  1. Before Bound the authority

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

  2. During Charge the call once

    The same 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. Here is the loop as the gateway actually ran it, shown in loop order: every request, every response, and the verifier's verdict, recorded from make prove-trust-plane and reproducible from a clone. The tool in the recording is a stand-in echo tool, not a refund tool; the permit, debit, receipt, and replay steps are the same for any governed action, and a configured upstream tool additionally gets a dispatch-claim record.

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 is a self-issued gateway receipt, published as a historical sample: it was issued on from a non-sensitive partner.echo call, and it is not customer traction. The bundle is paired with the exact 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…

Values are read from the published artifact, not typed into this page.

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 before treating issuer identity as independently established. 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 real operator, permission boundary, and retry or audit concern. Send the scenario by email. You get a written answer on whether the boundary fits, and if it does, we define the one action and walk it through permit → invoke → charge → receipt → replay → deny before discussing any broader rollout.

The pilot is paid, bounded to one tool, and priced after fit is established. We agree a setup fee and a separate recurring managed-service quote, with infrastructure and support scope stated in writing before work starts.

What the pilot includes

  • One partner-owned agent, one staging MCP tool, one consequential action, and one named partner engineer operating it.
  • A dedicated staging environment using synthetic or redacted data, with a written scope and end date.
  • An acceptance flow your engineer runs: repeat the request, confirm no second gateway dispatch or debit, test conflicts and denials, and verify the receipt offline.
  • Recorded onboarding hours, latency, infrastructure usage, and exception-handling effort.
  • A renewal decision at the end, with a named buyer, budget owner, and decision date.

Five things to include in your email

  1. The tool or action. What the agent calls, and what changes when it runs, for example a refund tool, a deploy trigger, or a payout call.
  2. What goes wrong on retry. What happens today when the call times out or the agent tries again.
  3. How you check it happened. How you currently find out whether the action ran, and whether it ran once.
  4. What one duplicate or unproven call costs. Estimate lost money, recovery hours and their cost, or a concrete customer consequence. Say what is measured and what is an estimate; if the cost is unknown, say so.
  5. Who owns the budget and when they decide. Name the decision owner and a target decision date.

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

One tool · one operator · one action. Email first; a call is available only when a scenario needs one. The source repository is public; run make prove-trust-plane from a clone to assert the whole loop locally. No API credentials, no signup.

Start a pilot by email Email 1@christophersellers.com Book a call if your scenario needs one Agent Middleware API calls are with Christopher Sellers.

Does avoiding duplicates justify the cost?

Take the refund example: each duplicate is one refund paid twice plus the hours spent clawing it back. Monthly actions × baseline duplicate rate × loss per duplicate × expected reduction = estimated monthly avoided loss. Use the loss you actually bear, including recovery labor, rather than the full transaction value. Count each cost once.

Expected reduction is an assumption about your whole adopted workflow, including the upstream tool, to validate in a pilot. It is not a gateway guarantee. These numbers stay in your browser and are not saved or sent to us.

Illustrative example: how a $35 threshold is calculated

100,000 actions/month × 0.1% duplicates × $50 actual loss × 80% reduction = $4,000/month in estimated avoided loss. With $2,800 in total monthly cost, the break-even loss is $35 per duplicate: $2,800 ÷ (100,000 × 0.001 × 0.8). At 0.01% duplication, the threshold rises to $350. These are illustrative assumptions, not our pricing or measured results.

04 / Machine discovery

Public pointers for agents and operators.

Machine-readable discovery — what an agent fetches before it ever calls a tool. Discovery is public. Protected actions still require an operator-issued API key and an applicable 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

Four unauthenticated GETs against the API origin; each opens the raw JSON in a new tab. Protected routes answer these same requests with 401 until an operator-issued key is presented.

05 / Honest limitations

What this proof does not establish.

  • Customer traction or production adoption
  • Production settlement or payment rails
  • Compliance-grade ledger storage
  • Exactly-once upstream side effects without upstream support
  • Universal governance across every agent framework

06 / Who is behind this

Built and run by one accountable operator.

Agent Middleware API is built and run by Christopher Sellers. The source repository is public; the product boundary and security limitations are also published from the API origin below.

Product wedge · Security limitations · Source repository

Bring one tool. Keep the evidence.

Email one governed action on a tool you already run. You get a written answer on fit, and if it fits, a receipt you can verify without us. A call is available only when a scenario needs one.

Start a pilot by email Run the local proof Book a call if your scenario needs one Agent Middleware API calls are with Christopher Sellers.