How to enforce an AI agent's bounds at the moment of action

Bounds hold only if a checkpoint sits between the agent and every system it can touch. Each tool call becomes a proposed action. The checkpoint tests it against every bound that applies at that instant, returns allowed, held, refused or withheld, and files the verdict. The agent never holds credentials that would let it go around the check.

What does enforcement at the moment of action mean, and who owns it?

Most agent limits are written at design time: a prompt that says "never refund more than 500", a role description, a policy document. None of these stop anything. The model reads them and usually complies. Enforcement at the moment of action means the limit is tested when the agent tries to do the thing, by code the agent cannot change, using the state of the world at that instant. The reasoning behind this is set out in why enforcement must happen at the moment of action.

The platform team owns the checkpoint. Process owners own the limits it applies to their agents. Risk or compliance owns the floor that applies to every agent regardless of who configures it. Keep those three apart: the person who sets a team's refund limit should not be able to remove the platform floor.

What are the steps to put enforcement in place?

1. Platform team: remove direct credentials from the agent. The agent calls tools through the checkpoint only. If it holds an API key to the ledger, every other step is decoration.
2. Platform team: describe every tool call as an action. Each call carries the agent, the capability, the target, the amount or scope, and the sources the agent relied on.
3. Process owner: set the bounds per capability. Write the limits the business would apply to a person in the same seat: per action, per day, per customer.
4. Risk owner: set the floor. Some actions are refused for every agent at every depth, however they are configured.
5. Platform, at each call: evaluate every bound at once. Role scope, certificate, sources, the customer's own limits, platform guardrails. The lowest one wins.
6. Platform: stage actions that need a person. A staged action is fully prepared but not committed. It waits for a named approver.
7. Platform: return the verdict and the deciding bound to the agent. The agent needs to know it was refused and why, so it can tell the user or hand the case on, not retry with a different wording.
8. Platform: file every verdict. Allowed actions are filed as well as refused ones. An auditor will want both.

Which controls make the enforcement trustworthy?

Fail closed. If the checkpoint cannot reach a bound, such as a limits service that is down, the verdict is refused. Evidence: refused verdicts naming the unavailable bound.

Cumulative limits, not just per action. An agent that may refund 500 per action can refund 500 a hundred times. Daily and per-customer totals must be checked against what has already been spent at that moment. Evidence: each verdict records the running total it was tested against.

Check at execution, not at planning. An agent may plan an action, wait for a tool response, then act. Limits and certificates can change in between. Test at the commit. Evidence: the verdict timestamp matches the execution timestamp.

The verdict names the deciding bound. "Refused" is not enough; "refused: customer daily limit" is. Evidence: one named bound per verdict.

Bounds are versioned. Evidence: you can show which limit applied on the day of any action.

For a shorter answer to the same question, see how you enforce an AI agent's limits at the moment of action.

What should you measure?

• Verdict mix per agent and capability: allowed, held, refused, withheld. A sudden rise in refusals usually means a change in the agent's brief or its inputs.
• Repeated refusals on the same case. An agent that keeps trying after a refusal is probing, and should be stopped.
• Checkpoint latency. If the check is slow, teams will look for ways round it.
• Calls that bypass the checkpoint. This should be zero. Any non-zero number is an incident.
• Held items that expire without a decision.

What are the signs it is going wrong?

Limits live in the prompt. If you can change an agent's limit by editing its instructions, the limit is advice.

Service accounts with broad rights. An agent that runs under a shared integration account inherits everything that account can do. Give each agent its own identity, scoped to what the checkpoint will allow.

Retries look like new requests. The agent is refused, rephrases, and the checkpoint evaluates the new call afresh with no memory of the first. Link related attempts to the case.

Withheld actions are configurable. If a team can switch off the floor for their agent, it is not a floor.

Refusals go nowhere. The agent is refused and silently stops, and the customer waits. Decide what happens next: the guide to responding when an agent attempts an action outside its bounds covers that hand-off.

Where Pryme fits

Pryme runs this checkpoint for every action every agent attempts. It evaluates the minimum chain of five bounds, returns one of four verdicts naming the bound that decided, and files the result in an append-only record. Withheld actions sit at the platform floor and cannot be configured away. The governed agentic operating system guide explains how the parts connect.