AI Agents

Human-in-the-loop by design: approval gates, budget caps, and audit trails for AI agents

Three controls turn an AI agent from a liability into an operable system: approval gates, hard budget caps, and structured audit trails. How to build each.

XISLABS Engineering6 min read
A team reviewing work together around a table with laptops, illustrating human review of automated output

An AI agent that can send email, move money, or edit records is a new kind of employee: fast, tireless, and with no instinct for when to stop and ask. The teams that run agents safely do not rely on the model to develop that instinct. They build three controls into the architecture: an approval gate for consequential actions, a hard cap on what the agent can spend or attempt, and an audit trail that records everything it did. This post covers what each control prevents, how to implement it, and where the line between "runs free" and "needs a signature" belongs.

Control one: approval gates

An approval gate is a queue between the agent's decision and the world. The agent proposes an action; a person accepts, edits, or rejects it; only then does it execute.

What it prevents. The irreversible mistake. A wrong email to a customer, a payment to the wrong vendor, a deleted record, a contract sent with the wrong terms. The model may be right 98% of the time, but the 2% is where the cost lives, and a gate catches it before it leaves the building.

How to implement it.

  • Model every action as a typed proposal with the full payload (recipient, amount, record ID, body) so the reviewer sees exactly what will happen, not a summary.
  • Route proposals into a queue with an owner, a service-level expectation, and a default of "do nothing" if nobody acts. Silence must never mean approval.
  • Let the reviewer edit in place. Reject-and-retry loops are slow; edit-and-approve keeps the human in control without restarting the task.
  • Make approval a recorded event with the approver's identity, a timestamp, and the diff between proposed and approved payloads.

Control two: budget caps

A cap is a ceiling the agent cannot cross: monthly spend, steps per task, tool calls per run, or records touched per day. When the ceiling is reached, the agent stops and a person is notified.

What it prevents. The runaway loop. An agent that retries a failing tool call, re-plans indefinitely, or fans out into hundreds of sub-tasks can produce a large bill or a flood of side effects in minutes. A cap turns a potential incident into a paused task.

How to implement it.

  • Set a hard monthly budget at the account level and enforce it in the execution layer, not in the prompt. The agent should stop automatically at the ceiling regardless of what it "thinks" it should do.
  • Add per-run limits on steps and tool calls so a single stuck task cannot consume the monthly budget.
  • Distinguish a stop from a warning. A warning at 80% is useful; the stop at 100% is the control.
  • Make the reset an explicit, logged decision by a named person, so raising a cap is as auditable as any other action.

Control three: audit trails

An audit trail is a structured, append-only record of every task, decision, and tool call: what the agent saw, what it chose, what it did, and what came back.

What it prevents. The unanswerable question. When something goes wrong, or when a customer, auditor, or regulator asks why an outcome happened, the trail is the only honest answer. Without it, teams reconstruct events from chat logs and guesswork.

How to implement it.

  • Log at the boundary of every tool call: the inputs, the outputs, the model version, and the task ID. Log the decision that led to the call as well.
  • Use a structure a non-engineer can read. The reviewer who approves actions should be able to follow the trail without a debugger.
  • Make it tamper-evident where the stakes justify it. Our on-premises surveillance product Eagle AI uses a hash-chained log so that any alteration is detectable; the same pattern applies to agents that act on money or records.
  • Design for rollback. Every write action should log enough to reverse it, and the trail should tell you which writes happened after a given bad decision.

Which actions need a signature

Most of an agent's work should run free. The line belongs where a mistake is costly or hard to undo.

  • Runs free: reading and summarizing, drafting, classifying, internal notes, retrieving records, proposing plans, updating its own working state.
  • Needs a signature: anything that leaves the business (customer email, public posts, vendor messages), anything that moves money, anything that changes a record of consequence (contracts, pricing, access rights), and anything that deletes.
  • Always capped: total spend, steps per task, and volume of any repeated action, regardless of whether it needs a signature.

Write this down as a table, and treat any change to the "runs free" list as one that needs its own approval.

How this maps to compliance expectations

Regulators and auditors tend to ask the same three questions in different words: could a person intervene, was the system constrained, and can you show what happened. Approval gates answer the first, caps the second, audit trails the third. Building them in means that human oversight and record-keeping obligations are satisfied by the system's normal operation rather than by a separate compliance project. It also lets security review happen on a real architecture rather than a promise.

What to do this quarter

  • List every action your agent can take and sort it into runs-free, needs-signature, and always-capped.
  • Build or buy an approval queue with a named owner and a default of no action.
  • Set a hard monthly budget and per-run step limits in the execution layer, and test that the agent actually stops.
  • Add structured logging at every tool boundary, with model version and task ID on every record.
  • Run a tabletop exercise: pick one bad outcome and confirm you can reconstruct it and reverse it from the trail alone.
  • Schedule a review of the action classification each time a new tool or integration is added.

How XISLABS approaches this

XISLABS designs, builds, and operates AI systems, with 74+ projects across 7 countries. Human-in-the-loop by design is one of our standing practices, alongside baselining the process, instrumenting the system, evaluating before launch, and operating after it ships.

Our product My Cloud Company is the worked example of this architecture. It is a managed team of AI agents per industry, with a managing agent and departments. Anything that leaves the business waits in an approval queue. Each client sets a hard monthly budget cap, and agents stop automatically at the ceiling. Every task, decision, and tool call is in the audit trail. Account access goes through each platform's own permission screen, so there are no shared passwords, and client data is isolated per client with human supervision throughout. Setup takes about 20 minutes.

For teams building their own agents, the same controls are standard components in our AI agent development and AI workflow automation work, and AI integration services cover wiring the approval queue and logging into existing systems. If you want to review where your agent's signature line should sit, contact us.

Sources

  • #human-in-the-loop
  • #ai-agents
  • #ai-governance
  • #audit-trail
  • #approval-gates
§ 01

Answers

Questions people ask about this

Does a human have to approve every action an AI agent takes?

No. Most work, such as reading, drafting, classifying, and retrieving, should run without review. Approval gates belong on actions that leave the business, move money, change consequential records, or delete data. Write the classification down and revisit it whenever the agent gains a new tool.

What is the difference between a budget cap and a spend alert?

An alert reports; a cap stops. A hard cap is enforced in the execution layer so the agent halts automatically at the ceiling regardless of the task it is in. Alerts at a lower threshold are useful, but only the stop is a control.

How do these controls help with regulation like the EU AI Act?

Regulators generally want to know whether a person could intervene, whether the system was constrained, and whether you can show what happened. Approval gates, caps, and structured audit trails answer those three questions as part of normal operation, which makes human oversight and record-keeping obligations far easier to demonstrate. This is general guidance, not legal advice.

§ 03

Keep reading

Related articles

§ 04 / Contact

Want help putting this into practice?

We build the AI agents, automation, and software behind ideas like these — scoped to a metric, shipped in weeks, operated after launch.

WhatsApp