For platform engineering, AI infrastructure, and security teams

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

Your agent invokes a costly tool. The request times out. Was it dispatched? Should the agent retry? Will the retry create another debit?

Put one scoped, budgeted boundary in front of the call. The same accepted idempotency key cannot create a second gateway dispatch or debit, and the terminal gateway outcome gets a signed receipt.

One internal MCP tool · fit and scope discussed privately · no self-serve rollout

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 middleware puts a narrow control point between the agent and one tool.

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

  1. Before Bound the authority

    Tool, wallet, budget, expiry, and operator-defined scope.

  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.

Start with the smallest action where permission, cost, or audit evidence matters.

  1. 01Discover
  2. 02Authenticate
  3. 03Authorize
  4. 04Invoke
  5. 05Meter
  6. 06Receipt
  7. 07Audit
  8. 08Govern

02 / Portable evidence

Inspect the receipt, then verify it offline.

This is self-issued live gateway proof, not customer traction. The published bundle comes from a non-sensitive partner.echo call and is paired with the exact public-key snapshot used by the offline verifier.

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 consistency check offline CLI

Download the portable receipt and matching key snapshot. 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.

Open proof and verification command

03 / Design-partner pilot

Start with one tool, not a platform migration.

Bring one internal MCP tool with a real operator, permission boundary, and retry or audit concern. We qualify fit, define the one action, and walk permit → invoke → charge → receipt → replay → deny before discussing any broader rollout.

04 / Machine discovery

Public pointers for agents and operators.

Discovery is public. Protected actions still require an operator-issued API key and an applicable scoped permit.

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