The guardrail · human-in-the-loop
The checkpoint
billoquy is built so a person can delegate the reading of a bill without ever delegating theyes. An agent — or billoquy itself — can discover checks, run them, read the finding, and prepare the fix. Sending it is a separate act that only the person can perform, and that separation is enforced in four independent layers, not promised in a policy.
The one rule
billoquy prepares; the person approves
This is the canonical line the MCP server publishes to any connected agent as thebilloquy://approval-policy resource. An agent reads it up front. It is not a courtesy — it is a description of what the system will and will not let anything do.
Enforced in four layers
Approval is not something billoquy chooses to withhold from agents — there is no path that reaches it. Four separate mechanisms have to each be true, and no client, prompt, or token can flip any of them.
1 · No approve, file, send, or pay tool exists
The MCP surface is seven tools — list_checks, start_check,get_check, get_prepared_fix, start_fix_checkout,get_billing_portal, list_account. None of them approves, declines, files, sends, delivers, or pays. The interface the tools are built on does not declare those methods, so an agent cannot call one — there is nothing to call. See the MCP guidefor each tool's inputs and outputs.
2 · The edge refuses an agent's token
Approving, declining, revising, or reopening a prepared fix — and minting or revoking an agent key — all require a human token. An agent key, owner-scoped though it is, gets a403 at every one of those endpoints. The scope is derived server-sidefrom the session behind the token, never from anything the client sends, so no request can promote itself. This is the real gate: it holds no matter what any client, wrapper, or prompt does.
3 · Approval has exactly one channel
A prepared fix records how it was approved, and the only value that field accepts is a signed-in web session (approvedVia: "web"). The state machine has no agent approval path at all — an action reaches approved only when the account owner releases it from their own signed-in session. get_prepared_fix hands the agent the drafted artifact to read and an approval link for the person to open — nothing that moves it.
4 · The delivery worker refuses the unapproved
Even past every layer above, the worker that actually files or sends a fix checks the status first and does nothing unless it reads approved. An artifact that was never approved is never delivered — there is no code path that sends one.
Can and cannot
The complete division of labor between a connected agent and the person it acts for:
| An agent can | An agent can never |
|---|---|
| Discover the checks and the policy | Approve or decline a prepared fix |
| Start a check from a bill | File, send, or deliver anything |
| Read the finding and its citations | Pay |
| Preview the prepared fix | Mint or revoke an agent key |
| Hand off a checkout or approval link | Change its own scope |
Payment doesn't shortcut it
Paying is not approving. start_fix_checkout returns a Stripe-hosted checkout link for the person to complete themselves — the agent cannot pay. And once the person has paid and billoquy has drafted the fix, it still waits for their approval before anything is filed or sent. Money moving is never the yes; only the yes is the yes.
For the person you're acting for
If you have pointed an assistant at billoquy on someone's behalf — your own account, or a parent you help out — tell them the plain version: there is no send button they didn't press.The assistant can do the reading and the paperwork and lay the fix in front of them. Releasing it is theirs alone, and nothing about connecting an agent changes that.