How do you enforce an AI agent's limits at the moment of action?

Put a policy check between the agent and every system it can change, so no action reaches a system without passing it. The check reads the limits and the live state, such as today's running total, at the instant the action is attempted. If anything is missing or unclear, it fails closed. Every decision is filed with the limit that decided it.

Why does the moment matter?

Limits checked earlier go stale. An agent that checks its refund cap when it starts a conversation may issue three refunds before the conversation ends, each under the cap and together well over it. A limit checked when the agent's workflow was designed knows nothing about today's fraud alert.

The argument is set out in why enforcement must happen at the moment of action. In short: the only point where you know exactly what is about to happen, to whom, and in what context, is the moment it is about to happen.

Where does the check sit?

At the single path every action takes. In practice that means agents never call business systems directly. They call tools, and every tool call passes through an enforcement point that can stop it.

Our answer on how an agentic operating system enforces limits covers the architecture in more depth.

What are the steps, and who acts?

1. Systems owner: removes direct access. The agent holds no credentials to business systems. Evidence: the access review showing only the enforcement point can call them.
2. Process owner: writes limits as policy. Each limit is a rule the check can evaluate: amount, cumulative total, counterparty, segment, time window. Evidence: the policy version, approved.
3. Platform: checks each call against live state. Running totals, the customer's current status and the agent's current certificate are read fresh. Evidence: the inputs the check used.
4. Platform: fails closed. If a value cannot be read, the action is held, not allowed. Evidence: a held verdict naming the missing input.
5. Platform: rechecks at execution. For held actions approved later, the check runs again when the action is released, because the state may have changed. Evidence: the second verdict.
6. Platform: files the verdict. Allowed, held, refused or withheld, with the bound that decided. Evidence: the record entry.
7. Process owner: reviews refusals and holds weekly. Patterns show limits set wrong or attempts to work around them. Evidence: the review note.

A worked example

Take a payments firm whose agent processes merchant refund requests. The firm's limit: up to 500 per refund, 2,000 per merchant per day.

A merchant's system sends five refund requests in a minute, each for 450. The check reads the running total before each one. The first four pass, total 1,800. The fifth would take the total to 2,250. It is refused, and the verdict names the customer's limit and shows the running total used. Had the agent checked the limit only at the start of the batch, all five would have gone through.

Limits can also differ by merchant or customer segment; whether an AI agent's limits should be the same for every customer covers when they should.

What does the agent do, and what stays with people?

The agent proposes actions and receives verdicts. It cannot see or change the policy, and it should be told why it was refused so it can explain to the user or route the item. People set the limits, approve held items and review patterns. The playbook on enforcing an AI agent's bounds at the moment of action lays out the full process.

Which controls make the answer hold?

• One path to every system, through the check.
• Live values, not cached ones.
• Fail closed on missing data.
• Recheck at release for held items.
• The verdict names the bound, so you can tell which limit is doing the work.

This is what it means to govern the action, not the model. The topic guide, agent governance is a bound, not a model, sets out why.