Guardrails and approval
Guardrails are the limits your agents cannot cross, whatever anyone tells them. We enforce them outside the agent: in its access rights, in read-only connections and in code. Where work needs a decision, we build the approval step, so the agent prepares the work and a person approves it in the system where the work happens. Every step is written to the logbook.
This is for you if
- Your agent's limits are written only in its instructions, and nothing stops it if it misreads them.
- You would let an agent prepare the work, as long as a person approves it before anything happens.
- Nobody can say which systems your agent can change, or what it could send outside the company.
What you leave with
- The result
- Limits that hold, and an approval step where you already work. The guardrails sit in access rights you control, in your systems and your own cloud. The approval step sits in the system where the work happens.
- The guardrails
- Each agent works under its own access with only the rights its job needs: read-only where it only reads, and no way to make a payment, delete a record or send anything outside the company.
- The approval step
- Each job is set at a stage: "You ask, the agent helps", "The agent prepares, you approve", or "It runs on its own, and you check the results". Money leaving the company, anything going outside it, a commitment, an unclear rule and a step the law gives to a person, such as a posting in the books, always go to a person.
- The logbook
- Every step, every approval and everything the agent was stopped from doing is written to the logbook, with its source and who approved it.
What we do, what you do
| We | You |
|---|---|
| Go through each job with you and write down its guardrails: what the agent may read, what it may change, and what it can never do. | Decide the guardrails, and the accounts and amounts each job may touch. |
| Give each agent its own access with only those rights, and enforce the limits in read-only connections and code. | Control the access: grant it, narrow it or withdraw it at any time. Where a step needs access, someone with admin rights grants it. |
| Build the approval step in the system where the work happens, so prepared work waits there for a person. | Approve, correct or reject the prepared work where you already work. |
| Test every guardrail with evals that ask the agent to do what it must not, and check that the system refuses. | Decide which repeated work may run on its own, and check the results. |
Worth knowing
"Never pay an invoice" in an agent's instructions is a rule, and a model can misread a rule or be talked around it. The text it reads can steer it too: an invoice or an email can contain words written to make an agent act. An agent whose access cannot make a payment has a guardrail, because the system refuses whatever the model asks. Guardrails and approval answer different questions. The stage decides how a person takes part in the work. The guardrails decide what can never happen, at any stage, and that is part of why repeated work can run on its own.
Your questions
- What does it look like in practice?
- At DuffBeauty, a beauty brand, the accounting agent works under one account of its own and reaches e-conomic through a connection that writes drafts only and can never book. Each call has a cap, imports run as a dry run first, and every call is logged. The external bookkeeper reviews the drafts in e-conomic and books them. Nothing is posted until a person approves it there.
- Do we have to approve every single step?
- No. Work that repeats, is written down and has a named owner can run on its own, and you check the results: fetching invoices, reading them, checking them and drafting the entry. In the invoice reader, a document that passes every check goes straight into the accounting system to be approved in a batch, and a flagged one comes back to the bookkeeper. Which steps need a person depends on the rules for the work. In a registered bookkeeping system, a person approves every posting, and one approval can cover a whole journal. Payments, anything sent outside the company, commitments and unclear rules always go to a person.
- Who decides the guardrails?
- You do. We write them down with you, set them up and test that they hold. The access that enforces them stays yours, and you can narrow it or withdraw it at any time.
- What happens when something changes?
- If something changes, it comes back to you for approval: a new supplier, a new system, a new rule, or a correction nobody expected. The agent then prepares and you approve, until you decide the work can run on its own again.
- Who is accountable for what the agent does?
- Your company is, through management and the person who approves the agent's work. That is why the agent works with its own access, so its drafts are marked as the agent's, why a person approves every posting, and why the logbook shows the source, the rule and the approval for each one.
- How do you know the guardrails hold?
- Evals ask the agent to pay an invoice, delete an entry or send an email, and check that the system refused. They run before the agent starts, and again after every change of model, rules or access.