That example comes from a recent article by a payments leader at a major bank, published on 29 September under the title "A prompt is not a control", and its first line is the whole argument:
"A prompt expresses intent; it does not enforce authority."
Later it says where the fix belongs: "The authority check belongs between Decide and Execute." That's the exact spot Delegus was built for. We have no connection to the bank. We read the list and thought it was specific enough to test, so we did, item by item, with the commands you can run yourself.
Who is asking, for whom, and is it allowed#
The first requirement is an engine that sits outside the agent and checks three things before anything happens: the agent, the company behind it, and that company's mandate. In Delegus that's a single call the bank or service makes before it acts:
delegus verify --grant <grant> --proof <proof> --action <action>The agent signed the request with its own key. The company signed the permission. Delegus checks both against the exact action and answers yes or no. The command exits 0 on an allow and 2 on a refusal, and either way it prints a signed receipt that names the agent, the principal (the company) and the grant_id. Because Delegus belongs to neither side, the check is independent of both.
Before the money moves#
The article is firm that the decision has to be enforced before cash moves, through a path the agent can't get around. Here the bank's own system does the enforcing. It only executes on an allow, so an exit code of 2 means the payment never runs. If the agent works through an MCP tool server, the gateway simply never forwards a refused call.
There's a catch, and it's worth saying plainly. This protects the paths where the bank has put the check, and only those.
A record that stays with the transaction#
An auditor six months later needs more than "the system said yes". The article asks for the decision and its policy version to stay linked to the transaction, and the receipt is built for that. It carries grant_hash (the exact permission relied on), proof_hash and request_hash (the exact request), protocol and trust (the rules version and configuration), and transaction, which ties it to any earlier receipts it rested on.
Anyone holding a receipt can check it without an API key:
delegus receipt verify --receipt <receipt>Give it Delegus's published key document with --did-document and it runs entirely offline. For a whole chain of linked decisions there's delegus chain verify. A word on "policy", since it means different things to different people: here it's the signed permission and the rules version, not the company's written policy document.
When permission ends#
Every permission carries an end date, and anything asked after it is refused with GRANT_EXPIRED. Taking one back early is a single command:
delegus grant revoke --principal <company-did> --id <grant-id>It doesn't return until every later check, anywhere, will refuse, and those refusals read AUTHORITY_REVOKED. The record can't be quietly edited either. In production we write receipts and their evidence to storage that nobody can change or delete for seven years, us included, before we send the answer.
Another agent can't hand out more#
The last requirement is the subtle one. A message from another agent shouldn't be able to widen what the receiving agent may do.
In Delegus authority has exactly one source, a permission the company signed. A request can show that permission. It can't add to it. If one agent tries to pass its authority on to another, the check refuses it outright today (UNSUPPORTED_FEATURE). And when a later step leans on an earlier decision, that link can only add conditions. Wider authority takes the company's own signature, nothing less.
The part we only partly meet#
The article asks for exposure limits that count completed and pending payments across every agent working under the same mandate. Otherwise two agents can each stay under a limit that, together, they blow straight through.
What we have today is narrower, and we'll say it exactly: a spend limit per permission, counted when the agent is allowed to act. That limit can be a total, an amount per day, week or month, or a number of uses, and it's spent only once every other check has passed. We don't yet keep one running total across several agents or a whole company, and we don't hold room for a payment that's still in flight. That would take new protocol work.
So we'd rather ask than guess. How should exposure count across a company's agents? If you run payments, we'd like to hear your answer.
Why it matters that the check is neutral#
The bank says it is building its own agent runtime along these lines. For a bank's own agents, that's the right call. Delegus is aimed at a different case: an outside agent, acting for a corporate customer, arriving at a bank or platform it has never dealt with. There the check has to run on the customer's own signed permission, behave the same wherever it's asked, and leave a receipt that both sides can verify without trusting each other.
If you'd like to see it on your own agent, try delegus.ai/check. The rules are in the open specification.