How do you control what an AI agent is allowed to do?

Through bounds checked every time it acts, not through instructions it is trusted to follow. Define the agent's role scope, prove what it can do on your own cases, restrict which sources it may rely on, set your own limits, and keep a platform floor beneath everything. Each proposed action is checked against all five, and the lowest one decides.

What does "allowed" mean for an agent?

For a person, "allowed" is usually a job description plus system permissions plus judgement. For an agent, there is no judgement you can rely on, so "allowed" has to be explicit: this action, for this customer, up to this limit, on this evidence, at this moment. Our explainer on what "allowed" means for AI agents goes through it.

The answer for any action is one of four verdicts: allowed, held for a named person, refused because it is outside the agent's bounds, or withheld because the platform does not let any agent take it.

What are the five bounds?

Ordinary role-based access control covers the first bound in part. The others are what make agent control different: depth that must be earned, facts ranked by where they came from, and limits that apply to each action.

What are the practical steps?

1. Write the role. List the capabilities the agent needs and nothing more. Name the process owner.
2. Decide the hard exclusions. Some actions should be out of reach for any agent in your business. Our answer on what an AI agent should never be allowed to do gives a starting list.
3. Test each capability on your cases. The results set the depth: read, draft, execute within bounds, or move money.
4. Set your limits. Values, counterparties, segments and anything else your policy requires.
5. Register the sources. Systems of record first; anything from outside labelled as such.
6. Enforce at the moment of action. The platform checks every proposed action against all five before it reaches a system.
7. File every verdict. With the bound that decided.
8. Change through change control. Raising any bound needs evidence and a second approver; see how to run change control for AI agents.

Who decides?

Not the team that builds the agent, and not the vendor. The person who owns the business process decides the role and the limits, with risk able to challenge, because that person answers for the outcome. Our answer on who should decide what an AI agent is allowed to do sets out the roles.

A worked example

Take a utility's billing agent. Its role covers explaining bills, setting up payment plans and applying goodwill credits. Testing on past cases certifies explaining bills at depth 3 and payment plans at depth 2. Goodwill credits are certified at depth 4 up to 30. The utility's own limit allows credits up to 50.

A customer asks for a 40 credit after a missed meter reading. The role allows credits, the utility's limit allows 40, but the certificate stops at 30. The lowest bound decides: the credit is held for a supervisor, and the verdict names the certificate as the deciding bound. Had the customer asked the agent to switch off a neighbour's supply, the role scope would have refused it outright.

Which controls make the answer hold?

• Bounds live outside the model. The model proposes, the platform decides.
• The lowest bound wins, so no single generous setting opens a door.
• Depth expires. Certificates lapse and must be renewed with fresh evidence.
• The agent cannot change its own bounds.
• Every verdict filed, so you can show what was allowed and why.

The topic guide, agent governance is a bound, not a model, explains the reasoning in full.

Where Pryme fits

This is the minimum chain in Pryme: role scope, certificate, sources, your limits and platform guardrails, checked at the moment of action. Attest sets the agent's depth from your own cases. Its role sets a ceiling, and the lower of the two applies. Every verdict names the bound that decided.