An agent should be able to say what it is allowed to do

The question that decides whether a system is safe to run against a real business is not how clever it is. It is: what is this thing permitted to change, and how would I know if it exceeded that?

Most systems cannot answer. The permissions are implicit in the code, distributed across whatever the developer happened to check, and discoverable only by reading everything. When something goes wrong, the honest answer to 'was it allowed to do that?' is 'we would have to look'.

We make authority an explicit part of every system, published on its own page, in the same five headings every time: what it can read, what it can write, what it may do conditionally, what is prohibited outright, and what it escalates instead of deciding.

What a grant actually is

A capability is a named unit of work — issue a receipt, cancel a receipt, produce a report. A grant is permission to invoke one. The grant is resolved from the operator's session on the server, never from the request body, and it is tested before any side effect runs.

That ordering matters more than it sounds. Authenticate, validate, authorise, claim, execute — in that sequence, with authorisation strictly before the first write. A system that writes first and checks after has no authority model; it has a hope.

When the grant is absent, the capability refuses and says which grant was missing. It does not silently do nothing, and it does not do a smaller version of the thing. A refusal is a legitimate outcome, and one the operator can act on.

Prohibitions are as important as permissions

Listing what a system may do is the easy half. The useful half is listing what it may never do, whatever the input says.

The receipts agent may never read its tenant scope from a request body, never repeat a side effect on a replayed idempotency key, and never resolve credentials from caller-supplied identifiers. Those three lines exist because each is a plausible way for a well-meaning caller to escalate their own privileges, and none of them is prevented by ordinary input validation.

The site-update agent may never keep an update whose post-check verdict is fail or review, never update without a database and file backup taken first, and never proceed when free disk space is below the configured floor. That last one is not a security rule. It is a rule about not starting an operation you cannot roll back.

It has to be checkable from outside

A claim about authority that can only be verified by reading the source is not much of a claim. Three of our twelve entries publish evidence anyone can check without taking our word for it; the rest currently rest on our own account, and we say so on the registry page rather than leaving the impression that all twelve are proven.

Here is one of the three. An agent that updates live sites was originally written with a flag that made rollback optional. Removing the flag would have broken existing callers silently — an old command line would keep running, with rollback quietly no longer happening. So the flag is still accepted, and does nothing:

--rollback-on-fail) ;; # Backward-compatible: rollback is now mandatory.

Verification is part of the system, not a phase after it

The receipts agent carries 230 passing contract and capability tests, a structural tenant-isolation test applied to every request model, and a production readiness gate that fails closed. The verdict logic in the site-update agent is covered by six tests that run in 62 milliseconds with no dependencies at all — deliberately, because a check that is slow or fragile is a check people start skipping.

None of this is sophisticated. It is ordinary engineering discipline, applied to a category of software that has been marketed for two years as though discipline were optional because the demo was impressive.

Autonomy should be proportional

How much a system decides on its own should follow from four things: how confident it can be, how reversible the action is, how much damage the action could do, and how much authority it was given. Not from how capable the underlying technology is.

An automation that sends a consignment deadline notice at three fixed points can run unsupervised forever — it sends the matching notice or nothing, and the worst case is an email. An agent that fulfils commerce orders has an explicit dry-run boundary before any live mutation, because the worst case is somebody's stock and somebody's money.

A human remains a valid architectural component. Routing a decision to a person is not a failure of the design; frequently it is the design.

What to ask a vendor

Ask what the system is prohibited from doing. Not what it does — what it cannot do, and what enforces that.

Ask what happens when it is uncertain. If the answer is that it proceeds with its best guess, you have found the failure mode before it found you.

Ask how you would check. If the only available answer is a demonstration, you are being shown behaviour, not authority.