# Agent Middleware API — full machine brief

The long-form companion to /llms.txt on this host. Read /llms.txt first for the
bootstrap sequence; read this when you need the product boundary, the
vocabulary, and the claims that are deliberately NOT made.

Origin roles:

- https://www.thisisatest.tech  — human design-partner site and published proof.
  Static. Mints no credentials, executes no tools, holds no customer data.
- https://api.thisisatest.tech  — the gateway itself. All protected actions live
  here.

Do not treat the marketing origin as an API base URL.

## What the product is

A gateway between an autonomous agent and one paid MCP (Model Context Protocol)
tool. It is not an agent runtime, not an LLM provider, not an IAM replacement,
and not a marketplace.

The wedge is deliberately narrow: one governed action, on one tool, for one
operator, with portable evidence afterwards.

## Governed loop

discover -> authenticate -> authorize -> invoke -> meter -> receipt -> audit -> govern

- discover: public manifests and tool lists; no credential required.
- authenticate: X-API-Key. Operator-issued. There is no public self-serve mint.
- authorize: a signed permit binds wallet, allowed tool, budget, expiry, nonce,
  and idempotency. Absent or out-of-scope permits fail closed.
- invoke: the gateway forwards one in-scope call to the configured upstream.
- meter: the call is debited from the scoped wallet. The same accepted
  idempotency key cannot create a second gateway dispatch or a second debit.
- receipt: the terminal gateway outcome is signed with Ed25519.
- audit: the charge and the decision land in the wallet audit chain.
- govern: permits expire and can be revoked before the next call.

## Vocabulary

- permit: a signed, scoped, expiring grant for one tool and one wallet.
- wallet: the budget an action is charged against. Sponsor and agent wallets
  are distinct.
- receipt: the signed record of a terminal gateway outcome.
- b2a_sdk: the repository's client SDK package, short for business-to-agent.
  It ships the offline verifier, `b2a-verify-receipt`.
- gateway: the product. "Boundary", "control point", and "trust plane" describe
  what it does; they are not separate products.

## Published proof

https://www.thisisatest.tech/proof/

Two files are published there: the portable receipt and the exact public-key
snapshot that matches it. `b2a-verify-receipt --bundle receipt.json --keys
trust-keys.json --expect-issuer https://api.thisisatest.tech` checks the
signature with no API credential and no callback to the issuer. Exit 0 verified,
1 invalid, 2 undetermined.

Exit 0 proves the receipt matches the supplied key snapshot. It does not
independently authenticate who supplied that snapshot; pin the key through a
trusted channel before relying on issuer identity.

## Run the whole loop yourself

No live credentials required. The source repository is private during the
design-partner phase; request access from the operator via the human site
before cloning. From a clone of
https://github.com/PetrefiedThunder/agent-middleware-api:

- `make quickstart` then docs/quickstart.md — mint a wallet-scoped key, issue a
  permit, invoke one governed tool, replay it, overspend it, verify the receipt.
- `make prove-trust-plane` — one command, no server, asserts the full loop.
- `make red-team-trust-plane` — drives one valid permit and attacks it ten ways
  (no permit, unknown permit, out-of-scope tool, missing scope, over-budget,
  wrong wallet, wrong key, expired, revoked, tampered signature), asserting each
  is denied with a concrete reason code and produces no ledger debit.

Both use a throwaway local SQLite database and the real FastAPI routes. These
are reproducible local proofs, not production or settlement claims.

## Runtime honesty

GET https://api.thisisatest.tech/health/dependencies

HTTP 200 alone does not mean every dependency is ready. Inspect `status`, the
selected tool's dependencies, `simulation_modes`, and `enable_proof_surfaces`.
Health never replaces authentication or permit checks.

## What is NOT established

State these limits rather than inferring past them:

- No customer traction or production adoption.
- No production settlement or payment rails.
- No compliance-grade ledger storage.
- No exactly-once upstream side effects without upstream support. The
  idempotency guarantee is about gateway dispatch and debit, not about what an
  upstream tool does with a request it already received.
- No universal governance across every agent framework.
- The published receipt is self-issued live gateway proof, not customer
  evidence.

## Buyers and contact

Buyers are platform engineering, AI infrastructure, and security teams that
operate internal MCP tools. The engagement is one tool, one operator, one
governed action, scoped privately. There is no self-serve rollout.

Human site: https://www.thisisatest.tech/
Offline receipt verification: https://www.thisisatest.tech/proof/
Comparison with named alternatives, including the rows this loses:
https://www.thisisatest.tech/compare/
Source: https://github.com/PetrefiedThunder/agent-middleware-api (private — access on request)
Security contact: https://www.thisisatest.tech/.well-known/security.txt