Put a person in front of a consequential agent action
One decision, bound to one exact payload, spendable once. Nothing calls the agent back. The head of IT who has to say who authorised the refund The approval was somebody typing yes in a chat channel. Nothing binds it to the action that ran, and a slightly different call two minutes later is covered by the same yes.
A yes in a chat channel evidences nothing.
The person who typed yes is identified by whoever's account was logged in, and approving a category rather than this refund of £240 on this order is a standing licence for every refund afterwards. The failure that makes teams switch the gate off is quieter: an agent waiting on a human has no callback, so it re-submits, and the queue fills with duplicates of one decision.
4 steps, in this order.
Gate the few actions that deserve it
The ones that move money, delete data, deploy or contact a customer. A queue nobody reads turns a control into a delay with a rubber stamp.
Run the rule in shadow first
In shadow it raises no approval and parks no trace, so the interruption rate is a number you measured rather than a surprise your rota discovers.
Set a lifetime you will meet
Sixty minutes by default, one minute to seven days by policy. Expiry is terminal after approval as well as before it.
Teach the agent to resume
The refusal carries the trace id, a typed code, the approval id and a resume object: the payload must match, and the approval is single-use.
See how an approval binds the action and its execution context.
See what an approval is bound toBuilt for
- A small set of actions that move money, delete data, deploy something or contact a customer.
- Agents you can teach to resume: the client-side change is one catch block that re-sends the request.
- A rota that can answer inside the lifetime you set, which is sixty minutes by default.
Wrong for
- Anyone who expects approving to make the agent carry on. An agent that never retries leaves the action undone.
- Anyone who needs approver routing, an escalation path or a two-person rule.
- Anyone who needs the reviewer to see the payload. The action summary is capped at 240 characters.
One thing on the record
A build of this product salted the approval hash for a proposed tool call with the trace id, minted fresh on every attempt, so no approval raised on that path could ever be redeemed. It failed closed, and the documented feature had never once worked.
What replaced it is a stable execution-context envelope. Raise an approval, approve it, retry the identical request, and watch it redeem exactly once.
Where this is publishedThe approval is bound to one exact payload and its context.
The context half is in the hash because changing it after a human reviewed the action changes what was approved: an approval granted to an agent holding one set of roles must not survive that agent being granted more. What is excluded matters as much: request ids, trace ids and transport session ids never enter it, because a reconnect must not invalidate a decision somebody already made.
- The action
- The sanitised model request, or the tool name and its arguments, plus the contract identity where an effect contract governs the call.
- The subject
- Id, kind, team, tags and effective grants, normalised so ordering cannot change the hash. A permission added later produces a mismatch.
- The chain and the human
- The ordered delegation identities with each hop's grants, plus the on-behalf-of identity, the session id and tags, and the tier hint.
- Excluded on purpose
- Request ids, trace ids, credentials and generated transport session ids — everything that changes between proposing and redeeming.
Sample data in the real Token Observe interface, recorded from a local evaluation with a temporary database, a mock provider and one request. No live provider key was used.
What the reviewer sees is a summary, not the payload.
The action summary is the tool name (or the model name, on the request path) plus the policy's own reason, passed through the mask redactor and capped at 240 characters. No model-proposed arguments reach the approvals table or the approval webhook. Treat both at the sensitivity of trace content all the same: a policy reason is written by your organisation and can name a customer or an amount.
4 things this still does not solve.
- There is no approver routing. Any operator whose evidence scope covers the trace's team can decide any approval in it: no approver list, no escalation and no two-person rule.
- The reviewer reads a summary, not the payload, so somebody who skims approves what they were shown rather than what will run.
- Offline approvals on a developer seat cannot be single-use. A signed bundle records consumption as of issue, so within its freshness window one can be spent twice.
- Nothing pushes the decision to the agent. Approving is a permission the agent redeems by retrying, and the gate binds only the calls Token Observe sees.
Check the product limits alongside the job you want to do.
What we do not claimThe parts that do the work.
Human approvals
One human decision, bound to one exact payload, spendable once.
An approval takes effect only when the agent retries
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
Injection scoring is nine fixed patterns, not a model
MCP gateway
The half of an agent that moves money is a tool call, not a sentence. This is the checkpoint that call goes through.
A tool call routed around it is not governed here
Questions
Does approving in the console make the agent carry on?
No. Token Observe has no channel that reaches an agent; event delivery goes to webhooks, chat and email, which are human channels. An approval is a permission the agent redeems by repeating the identical request with the approval id attached, so clicking approve moves nothing until the agent tries again.
What happens if the agent changes the request after approval?
It is refused. The retry is canonicalised and hashed again, and a differing hash is refused as granted for a different action payload, with no execution and no partial credit. That covers the context too: a different on-behalf-of identity, or grants widened after the decision, both produce a different hash.
What happens if nobody decides in time?
The approval expires and the action does not happen. Expiry is applied lazily before the queue is listed and before any decision is written, and expiring the row and releasing the budget reservation are one transaction. The agent is then told a new approval is required rather than that it was refused.
Describe the version of this you have.
Say what your estate contains and which part of it worries you, and the reply will say where to start.