How do you set permissions for an AI agent?

Write each permission as a complete sentence: this agent may do this action, to this depth, on these records, within these limits, because of this evidence, until this date. One sentence per capability. If you cannot fill in every part, the permission is not ready. The agent never sets or extends its own permissions; its owner does, through change control.

Why aren't system roles enough?

System roles answer "which screens and tables can this account reach?". For a person, judgement fills the gap between reach and appropriate use. For an agent, nothing fills it. A billing role that lets a person adjust any invoice works because the person knows not to. An agent with the same role will adjust whatever its reasoning suggests.

So an agent's permissions need more parts than a person's. System access is one part. The others say how far, for whom, under what limits, and for how long.

What are the parts of a permission?

Depth is certified per agent and needed per action. An agent can read accounts at depth 1, draft letters at depth 2 and apply small credits at depth 3, all at once. We explain why in depth is certified per agent and needed per action.

What are the practical steps?

1. Define the role scope. List the capabilities the agent needs for its job and nothing more. Our guide on setting an AI agent's role scope covers how.
2. Write the permission sentence for each capability. Fill every part in the table.
3. Start low. New capabilities begin at depth 1 or 2 until testing supports more.
4. Test, then grant. Run the agent on your own past cases for each capability and set depth from the results.
5. Put permissions into the enforcement layer, where they are checked at every action, not into the agent's instructions.
6. Set expiry. Permissions lapse and must be renewed on fresh evidence; why an AI agent's permissions should expire gives the reasoning.
7. Change only through change control, with the owner and a second approver for any increase.

Can the agent request or change its own permissions?

It may report that it lacks a permission, for example "I could not complete this because I cannot update payment dates". It must not grant, extend or widen its own permissions, directly or by asking another agent to act for it. Our answer on whether an AI agent should be able to change its own permissions explains why that line is absolute.

A worked example

Take a housing association's repairs agent. Its owner writes four permissions:

• Read repair history for the tenant in the conversation, depth 1, no expiry beyond the agent's own review cycle.
• Book routine repairs into contractor slots, depth 3, for repair types on the approved list, up to two bookings per tenant per week, on evidence from 1,000 past requests, for 90 days.
• Draft letters about repair delays, depth 2, a person sends.
• Mark repairs complete, depth 2, a person confirms after the contractor's report.

A tenant asks the agent to book a gas safety check. Gas work is not on the approved list. The booking is refused on the limits part of the permission, and the request goes to the repairs team with the tenant's details.

Which controls make the answer hold?

• Every part filled in before a permission goes live.
• Permissions checked at the moment of action.
• Increases need evidence and a second approver.
• Expiry enforced automatically, with depth dropping if renewal fails.
• The agent cannot change its own permissions.

The topic guide, agent governance is a bound, not a model, explains how permissions fit among the bounds every action meets.

Where Pryme fits

In Pryme, role scope sets the capabilities, Attest sets the depth of each from your own cases, and your limits narrow it further. The role sets a ceiling; evidence sets the depth; the lower applies. Certificates lapse after 90 days.