Five levels of authority, and the things no agent ever gets

Why this is middleware and not a prompt

A great deal of AI product safety is currently implemented as instruction: the system prompt tells the model what it must not do, and the model, being agreeable, mostly complies. That is an acceptable design for a chat assistant and an unacceptable one for something with write access to a general ledger.

The problem is not that models disobey often. It is that the failure is unbounded and undetectable. An instruction-based control has no enforcement point — nothing in the system can tell you whether the rule held, because there is no moment where the rule was evaluated as code. You find out from the consequences.

So authority here sits in the execution path, not in the context window. When an agent proposes an action, the proposal is a structured object — action type, target records, amounts, the policy it believes applies. That object is handed to a deterministic engine which evaluates it against the levels and rules configured for your tenant, and returns permit, hold-for-approval, or reject. The agent is not consulted about the outcome and cannot retry with a better argument.

What that gives you operationally

• A provable answer. For any posted transaction you can show which rule permitted it, evaluated deterministically, rather than inferring intent from a model output.
• A stable blast radius. The worst case for a misbehaving agent is bounded by its configured level, not by how persuasive its reasoning was.
• Separation of duties that survives. The agent proposing and the engine permitting are different systems with different failure modes. A bug in one does not silently grant the other.
• Testability. Permission logic is code, so it is unit tested, versioned, and reviewable — including by your auditor.

The four things no agent may ever do

These are not defaults that a determined administrator can lower. They are absent from the permission model entirely, which means there is no configuration that produces them.

• Release funds. An agent can prepare a payment run, select invoices, verify remittance detail, and queue it. A named human releases it, at any amount, at any confidence, forever.
• Close or reopen an accounting period. Agents drive the close checklist and tie the subledgers. Signing is an act of assertion by a person, and pretending otherwise would make the assertion worthless.
• Write to the general ledger directly. Every posting goes through the deterministic accounting engine that enforces balance, period state, and account validity. There is no agent-only path, not even for reversals.
• Modify its own permissions. Authority is administered in a surface agents cannot reach. An agent that could widen its own scope has no scope.

Where we recommend starting

Almost every customer should begin with everything at Level 1. The agents draft, your team reviews, and for the first four to six weeks the value is speed of preparation rather than autonomy. That period is also what builds the labelled corpus that makes the accuracy numbers real.

The first thing to move to Level 2 is usually invoice reminders inside a dunning policy, because the downside of an error is embarrassment rather than a misstatement. The second is bill posting for recurring vendors under a threshold — typically after that vendor has thirty clean drafts behind it, which most controllers set as a rule rather than judging case by case.

A reasonable steady state after a year, for a company between $10M and $50M, is Level 2 on accounts payable for known vendors under $2,500, Level 2 on dunning, and Level 1 everywhere else. That configuration removes most of the manual work while leaving every judgement call with a person. Nothing about the product pushes you further, and our pricing does not reward it.