Inside your perimeter. Nothing of yours leaves it.

Agentic Terminal runs as an MCP server in your infrastructure, operated by your team or by ours. There is no hosted tier, no account to create, and no tenancy on our side to be in scope for your review.

01 · CUSTODY

It holds nothing worth stealing

No funds, no signing keys, no credentials. The enforcement point reads the mandate it enforces and holds no key that could issue, alter or re-sign one. There is no store on our side to protect and no lookup for us to gate.

02 · PATH

It is not in your payment path

The control sits at the boundary that already holds your credential, before an instruction exists. A refusal anywhere an agent can route around it is advice rather than a control, which is why the enforcement point is the boundary and not a report on one.

03 · INDEPENDENCE

What it produces outlives it

If Agentic Terminal disappeared tomorrow, every credential it issued would still verify, because verifying one never involved it. The verification itself needs nothing from us. This is the operational surface around that property, not a substitute for it.

Where money moves on someone else's behalf.

Wherever three parties exist, these controls have something to bind. Where only two do, they mostly do not. The three are: whose money it is, who is authorised to move it, and who may need proof of what was authorised.

01Third-party claims administrators
02Benefits and warranty administrators
03Fund administrators
04Managing general agents
05Escrow agents
06Outsourced accounts payable

Anywhere authority to disburse is delegated, written down, and audited. The same three parties appear on the asset side: a fund or its general partner, an administrator processing capital calls and distributions on its behalf, and a depositary or auditor obliged to verify. Each of the three can check independently, and none of them has to trust the other two or involve us.

What is built, what is designed, what is only specified.

Three columns, in the same words agenticterminal.io uses, so a reader comparing the two pages is comparing one register rather than two vocabularies. A capability moves between columns by being built, never by being described differently.

Built and tested
  • The enforcement core.
  • An approvals surface: approve and deny over an API and a command line, with pending approvals that survive a restart.
  • Decision records, signed and independently verifiable from the file alone.
  • Lightning enforcement, demonstrated on mainnet at a node's own signing boundary, against a client written specifically to bypass it.
  • Revocation, enforced at verification and exercised against real revoked entries.
Designed, not built
  • The console. It is a design, and not a screenshot of a surface that exists.
  • Bank payout and card rails, both in scope for launch.
  • Authentication of the status list itself on the delegation path.
  • The console's automated revocation path. In the current deployment a credential is marked revoked by hand.
Specified, not built
  • Principal-as-issuer.
  • Requiring a decision record at the payment boundary. No published schema version carries the field, and nothing on a payment path refuses a payment for lacking one.
  • Suspension, as distinct from revocation. A suspended credential still verifies.

Revocation appears in two columns, and both entries are correct

They describe different layers, so neither contradicts the other. At the protocol layer it is built: verification refuses a credential whose status entry is set, and refuses just as firmly when the list cannot be fetched or decoded. The machinery was exercised end to end against the deployed service on 7 August 2026: create a list, allocate an index, set a bit, serve it, verify it, and both refusals. Un-revoking was refused as terminal.

At the console layer it is not: the automated path an operator would use to drive that machinery is designed and not built, so in this deployment a credential is marked revoked by hand. The guarantee a counterparty gets is the protocol one. The convenience an operator gets is the part that is missing.

One further limit, stated because it bounds the first paragraph: the status list's own signature is not yet checked on the delegation path, so that guarantee is currently as strong as control of the address serving the list, and no stronger.

Three things this page owes you, which it did not carry before today

The Lightning demonstration was signed by a demo key. 200,000 sat was denied against a 100,000 sat ceiling at the node's own signing boundary, with local balance available and a live channel to the destination, and a 10 sat payment to the same destination over the same channel settled in the same session. That is what makes it a policy decision rather than a routing or liquidity failure. The mandate for it was signed by a demo key generated on the box, not by our production issuer.

The payout rail has an adapter and no processor. No payment has been made on the bank payout or card rails. The claim that one mandate spans rails is a claim about the policy model, not a report of payments made.

Principal-as-issuer is specified and not built. Mandates are signed by our issuance service on the principal's behalf today. The credential names the principal; the signature over it is currently ours.

Open primitives. Operated surface.

The line between the two is not open versus paid. It is primitive versus operation.

Observer Protocol

Open infrastructure

Free, open source, self-hostable. The verification logic is public and anyone can implement it, extend it, or run it themselves. It does not custody funds, execute payments, or control access.

W3C DID and VC standards
Credential issuance and verification
AIP behavioural specification
MIT licensed, self-hostable, rail-agnostic
Agentic Terminal

Operated surface

How an institution operates the protocol: who may request authority, who may grant it, and what record that leaves. Observer Protocol is the foundation. Agentic Terminal is the business.

Request and approve as separate acts
The approvals queue
Decision records and audit export
Evidence operations

We are taking a small number of design partners.

We are working directly with a small number of organisations who disburse on someone else's behalf and need this control to exist before they can widen what their agents are allowed to do. If the status section above reads as the shape of your problem rather than a list of gaps, that is the conversation we want.