Financial services
A refund is the reference case because an API returning 200 is not proof the customer got their money.
On this page
What is already on you
- 01
The actions are irreversible and externally observable
A refund, a payment instruction, a limit change, a ticket transition, a database write. Each has a counterparty who noticed, a ledger that recorded it, and a customer who can complain about it — which is what makes the model’s own account of what it did unusable as evidence. - 02
Third-party and outsourcing scrutiny arrives before the pilot does
A control that runs on your own infrastructure, holds no credential into your security stack, and sends the vendor nothing is a materially shorter review than a hosted control plane with a data-processing annexe. The counterweight is equally real: there is no independent certification to hand the same reviewer, and that has to be planned for rather than discovered. - 03
Somebody will ask what happens when the control itself fails
Governance here is inline and fails closed, so the failure mode is a stop rather than a silent bypass — which is the right direction for a control and is also an availability dependency you now own. There is no HA story, no replica and no clustering at this scale, and no availability commitment is offered. Whether your own resilience regime treats an inline governance gateway as a critical dependency is a question for your second line, not one this product answers for you; what it can do is give them the failure mode in writing before the pilot rather than after it. - 04
You will not stay on one model provider
Six upstreams are first-class, and policy equivalence across them is enforced by a table-driven test over every provider kind — because a rule that fires on one provider and not another is worse than no rule, and a multi-provider estate is exactly where a control quietly stops applying. - 05
Agentic commerce is arriving with liability questions attached
Machine-initiated purchasing raises counterparty, mandate, delivery, liability and settlement questions that a token budget does not answer. That work sits on the roadmap as a research experiment to be run with a design partner, and the governing rule is that Token Observe should govern the mandate and the outcome rather than become a payment processor.
The objections, in the words they are raised in
Not a marketing FAQ. These are the sentences this reader says out loud in a first call, quoted rather than softened, and several of the answers below concede that the limitation is real and name the person who has to accept it.
- 01· asked
We already run an LLM gateway with quotas, budgets and cost dashboards.
answeredThen keep it. Provider routing, retries, caching, quotas and cost dashboards are named as table stakes rather than the lead story in the product’s own roadmap, and the intended posture is to integrate above or beside a gateway rather than compete on connectivity. A gateway carries the request. What it does not carry is proof that the exact delegated authority and the resulting business effect stayed legitimate — that the refund an agent proposed was approved by a named person against that precise payload, that it dispatched once, that a separately pinned verifier then observed the ledger reach the expected state, and that a compensating action ran and was itself verified when it did not.
- 02· asked
Can you actually prove the payment happened, or only that you allowed it?
answeredIt can prove the run reached a verified terminal state, which is stronger than allowed and weaker than settled — and the difference is stated rather than blurred. A contract binds pinned action and verifier tools, an idempotency key pointer, postcondition queries with a bounded evidence age, invariants, failure conditions and, where compensation exists, a distinct pinned compensation verifier. Recovery bindings carry the client-known business key and cannot depend on an action response that may have been lost. Pending observations are retried within a bounded window, and stale or exhausted evidence never advances a terminal success state. The limits: this is durable at-most-one intent rather than distributed exactly-once, and a separately pinned verifier is not independent attestation.
- 03· asked
Our third-party risk team will require SOC 2 and a penetration test.
answeredNeither exists today, and no readiness score should be quoted at you either — the current decision record withdraws the earlier ones. What exists instead is a shorter review surface and permission to test it yourself. The product runs entirely on your infrastructure, holds no credential into your security stack, and sends the vendor nothing, which is checkable in about five minutes with two greps over the source and an egress watch rather than a questionnaire. The published licence sets thirty days to read, run and attack it before a purchase order exists, and permits publishing the findings with no gag clause — though that file is still a template awaiting counsel, so the window belongs in your executed agreement rather than in a repository quotation. What replaces the badge is signatures: the threat model names the CISO, the Data Protection Officer, the Head of Product and the engineering lead as the roles that must each record a dated acceptance of specific residual risks, and none of them counts as accepted until a named person dates it. A named date for a certification milestone your process requires is something an agreement can carry.
- 04· asked
Does this handle agent-initiated payments?
answeredNot as something you can buy today, and it would be easy to imply otherwise. Counterparty and marketplace allowlists, a human mandate, price, recurrence, geography and category ceilings, payment release conditional on verified delivery, disputes and attribution to agent and sponsor are all described as a research experiment to be run with a design partner rather than as shipped capability. What is shipped and usable now is the layer underneath: hard per-agent budget circuit breakers by request, hour, day and month; approvals bound to one exact payload, single-use and expiring; and effect contracts that verify a postcondition rather than trusting a success response.
If the objection that would actually decide this for you is not one of the ones above, that is the more useful question, and it is the one worth sending.
Talk it throughA governed refund, end to end
The reference case is deliberately mundane, because a mundane action with money attached is where the evidence problem actually bites. The agent proposes a refund. The policy matching that tool and those arguments requires a human rather than refusing outright, so the caller receives its provider’s own error envelope carrying a typed code, the trace id, the approval id and the single-use header to resume with. A named person reads the action summary and either approves it with a rationale or does not. The approval is bound to that payload hash: resuming with different arguments does not consume it.
If the tool is pinned as effect-required, the action cannot execute raw at all without an active valid contract — that classification is durable and independent of contract status, so removing the contract does not quietly re-open the direct path. Dispatch is leader-owned with fenced stage leases and a durable encrypted recovery context, so an ambiguous outcome recovers by verifying rather than by retrying the action. Only when fresh evidence matches every postcondition does the run become committed.
What you can hand somebody afterwards is a trace with its ordered events, an approval carrying the approver’s identity, timestamp and rationale, audit entries for every governance-plane change involved, and — where a signing key is configured — a canonical Ed25519 effect receipt for the terminal outcome, verifiable offline against a public key distributed through an independent channel. If no signing key is configured, the receipt endpoint returns a not-found rather than an unsigned trust claim, which is the right failure for a document whose whole value is its signature.
- Compensation is verified, not assumed
- Automatic compensation requires fresh evidence matching every terminal failure condition, and after the compensating call the run stays in a compensation-verifying state until fresh evidence matches every compensation postcondition. Partial execution and failed compensation are visible terminal states rather than swallowed errors.
- Business-key uniqueness
- Scoped by a keyed digest across agents and contract revisions, so two agents cannot both act on the same underlying business event by using different identifiers for it.
- Operator adjudication is an attestation
- Where automated verification cannot resolve a run, an operator records what they established. That is an attributable human attestation, not retroactive independent proof, and it never releases the used business key for replay.
What a third-party review is actually reviewing
The architecture removes most of the questionnaire. There is no vendor-operated component in the path, no telemetry, no phone-home and no licence callback; state lives in one database on your disk; egress goes only to the model providers, tool servers, webhook receivers, identity provider and anchor sink you configured. That is a contractual undertaking in the licence as well as a property of the code, and the consequence procurement cares about is that supplying the software does not itself create a processing relationship — while counsel still decides the roles created by evaluation, support and incident handling.
Licence compliance is self-certification, which is unusual enough to be worth knowing in advance: because the software reports nothing, the vendor has no visibility of your usage, no right to inspect your systems, and no right to require a metering component. One written certification per twelve months on notice is the whole mechanism.
The counterweight is stated in the same paragraph rather than a footnote. There is no SOC 2, no ISO 27001, no ISO/IEC 42001 certification and no independent penetration test. There is no multi-node high availability, replica or clustering, no point-in-time recovery — recovery is from a retained full snapshot — and no availability commitment. Residual risks are accepted in writing by named people rather than covered by a badge, and the design-partner gate requires exactly that before a pilot starts.
Where this sits beside the controls you already have
Identity systems prove who an agent is. Security platforms inspect its traffic. Gateways carry the request. None of those proves that the exact delegated authority and the resulting business effect stayed legitimate, and that is the only territory this product claims. The practical consequence for an architecture review is that the integrations are inbound: threat and asset verdicts from your security stack, egress and billing evidence pushed into the shadow-AI radar, identities federated from your directory, telemetry ingested over OTLP.
That direction is a security argument as much as a product one. The radar connectors hold no credential into your security stack; your stack pushes to them, so the worst a compromised install can do to your SIEM is stop receiving from it. It is both the shorter review and the smaller blast radius.
Two capabilities are worth naming for a multi-provider estate specifically. Policy equivalence across six first-class upstreams is enforced by a table-driven test over every provider kind, so a rule written once is a rule that fires everywhere. And typed failover distinguishes a rate limit or a timeout, which fails over, from a content-policy refusal, an authentication error or an invalid request, which do not — because a fallback chain that quietly launders a refusal into a success is a control failure disguised as resilience.
The parts of the platform this leans on
In the order they matter to this reader rather than the order the platform argues them, and each one carries its own stated limit on the page it links to.
Effect contracts
The action leaves once, and success is what a second pinned tool observed.
Human approvals
One human decision, bound to one exact payload, spendable once.
Spend controls
Hard USD ceilings, per-minute rate limits and a kill switch, all decided before the request leaves your network.
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
What is the buying trigger here?
A consequential, externally observable action that somebody will later have to prove: a refund, a deployment, an outbound email, a ticket transition or a database update. The definition of done the product is built against is the sentence a regulated firm recognises immediately — the action cannot be reported complete solely because an API returned success. If your agents only draft text for a human to send, the honest answer is that the flight recorder and spend controls are useful and effect contracts are not yet earning their keep.
Can an agent escalate its own authority by asking another agent?
No. Permissions are action-level and deny-by-default, explicit denies always win, and delegation chains intersect permissions at every hop — so agent A cannot obtain, by asking higher-privileged agent B, the thing A was refused. A forged delegation chain can therefore only narrow authority, never widen it. Tool calls re-check grants independently of tool listing, so an agent that can see a tool in a catalogue has not thereby been granted it.
How are budgets enforced, and what happens to an unpriced model?
Hard circuit breakers per agent by request, hour, day and month, with a kill switch scoped to one agent, a team or everything sitting above them and evaluated first. The sharp edge is metering rather than the ceiling: a model with no price row meters at zero, so an agent that carries any budget field is refused with a typed error before provider egress when its resolved target — or any reachable fallback — has no price. Without that rule an unmetered estate and an idle one look identical on every spend surface.
Is there evidence a policy will not misfire in production?
There is a mechanism rather than a promise. Every policy can run in shadow mode first, so you learn your false-positive rate on your own traffic before you block real work, and backtesting replays a candidate rule against retained traces. An optional gate refuses the transition into enforcement until a backtest of that exact rule digest has been run and acknowledged by a named person, with their name and the accepted figures copied into the audit entry. It is off by default, and it is a process control rather than a technical one.
What is the realistic first deployment?
One self-hosted deployment in your own VPC, roughly five to fifty agents owned by a single platform team, one or two model providers, a bounded set of pinned tools, shadow policies first and enforcement only after an acknowledged backtest — and a non-production-critical workload before anything whose outage would harm customers or regulated operations. That boundary is published as the maximum supportable scope rather than negotiated downwards later, and residual risks are accepted in writing before it starts.
Bring the objection that is not on this page.
Write to hello@tenhaw.com with what your agents do, which providers they call and what would have to be true for you to put something in front of them. James Rooney replies. You will get a straight answer about whether Token Observe fits, including when it does not.
no form · no qualification step · no sales desk · the other three ways in