What to write in an AI agent’s permission list before it goes live

Never run an agent under a staff member’s account. When something goes wrong, the audit log must show the agent, not Priya from the front desk. A separate login also lets you switch it off alone. No person gets locked out. Revoking it takes seconds.

Create the account with the least access the job needs. A booking agent needs to read the diary and create appointments. It does not need the customer’s payment history. A clean separation also helps the next audit, because the auditor can export every action the agent took in a quarter and read it as one continuous list.

Name it plainly, such as booking-agent, and tell the team that name appears in the history. Staff then spot its entries in the ticket history at a glance.

A tool is a function the agent may call. Keep each one narrow: look up an order by number, create a callback task, add a note. Avoid a general tool named update customer that can change any field. Too broad. Each tool should also validate its own inputs, rejecting an order number with the wrong number of digits instead of passing a guess along to the database.

Narrow tools give you narrow mistakes. That is the aim. If the refund lookup is read-only, no wording from a clever customer can turn it into a refund.

List every tool in the permission document, with what it reads, what it writes and which record types it touches. If a tool is not on the list, the agent does not have it.

Some actions are safe once and costly a hundred times. Put a ceiling on each. Maximum credit it may offer, maximum appointments it may move in an hour, maximum messages sent to one customer in a day. Counters should reset on a clock the agent cannot change, and the limit should be enforced in the tool itself rather than politely requested in the instructions.

Write the limit next to the tool, in the unit your team already uses. An amount in your currency or a count per hour is easy to check later. A vague phrase such as small refunds is not. Use numbers.

When a request goes over the limit, the agent should stop and hand over. It should not split one large request into several small ones.

Some things stay human, whatever the agent’s confidence. Write them down in full sentences. Cancelling a contract. Changing bank details on a supplier record. Replying to a legal notice or a complaint that mentions a regulator.

Add data to the list as well as actions. The agent should not read payroll files, medical notes or staff disciplinary records, even if it could reach them through a shared folder. A good test is a customer pasting an email that claims to come from the manager and orders the agent to ignore its rules and refund an invoice.

Test the list by trying to break it. Ask the agent to do each forbidden thing in plain words and in disguised ones. Record the result. Fix any gap before launch.

Say exactly when the agent passes the case to a person. Typical triggers are a refund ceiling being reached, a customer asking for a human, two failed attempts to answer or a topic on the never-touch list. Name each one.

The handover must carry context. The person receiving it should see the conversation, the tools already used and the reason for the transfer, so the customer never repeats themselves. Where your helpdesk supports it, tag handed-over tickets with the trigger name, so that after a month you can count which rule fires most often.

Sign the list off with the owner of the process, then run the shadow period with the agent proposing and a person approving. Change the list in writing, with a date, each time you widen its powers.