How to decide which actions no AI agent may take

Start with the actions a person must answer for personally. An action belongs on the "no agent" list if it cannot be undone and could cause serious harm, if the law or a regulator expects a named individual to take it, or if it would let an agent change its own controls. Executives sign it; every agent refuses it.

What is the "no agent" list, and who owns it?

Most decisions about agents are local: which capabilities this agent has, at what depth. A few should not depend on local judgement. Signing a regulatory return, filing a suspicious activity report, dismissing an employee, changing an agent's own permissions: these should be refused for every agent, whoever builds it and whatever the business case.

The chief risk officer usually owns the list, with the general counsel and the chief operating officer as co-signatories. Business owners propose and challenge entries. Who holds this power, and why it should not be the vendor or IT, is discussed in who should decide what an AI agent is allowed to do?

Which tests put an action on the list?

• Irreversible and harmful. The action cannot be undone, and a wrong one would seriously harm a customer, an employee or the firm. See which AI agent actions are irreversible?
• Personal accountability. A rule, regulator or court expects a named person to have made the decision, such as attesting to a filing or signing a contract that binds the firm.
• Self-control. The action would let an agent change its own limits, approve its own work, alter its own record or grant itself access.
• Credential handling. The action exposes or changes passwords, keys or authentication factors.

An action that fails only on volume or value usually belongs on a hold, not on the list. The difference between holds and absolute limits is covered in how to decide which actions an AI agent may take without a person.

What are the steps, and who acts at each one?

1. Agent, depth 1: inventories actions. It reads the connectors and permissions of every agent and lists every distinct action they could take across your systems.
2. Person, each business owner: adds actions agents do not yet have but plausibly will, so the list does not lag behind.
3. Person, risk lead: tests each action against the four criteria and proposes entries, with the criterion that applies.
4. Person, general counsel: reviews legal entries, deciding where law or regulation requires a person.
5. Person, chief risk officer, chief operating officer and general counsel: sign the list.
6. Person, platform owner: encodes the list as refusals in every agent's role scope and in the onboarding template for new agents.
7. Agent, depth 1: is tested against the list. Each listed action is attempted in a test environment, including attempts phrased indirectly or embedded in documents.
8. Person, risk lead: reviews the list at least yearly and whenever a new system is connected.

What evidence should each step leave?

• Inventory: a dated list of actions per system, generated from connectors.
• Anticipate: owners' additions with the expected date the capability arrives.
• Test criteria: each proposed entry with its criterion and a one-line reason.
• Legal review: counsel's notes on each legal entry.
• Sign: the signed, versioned list.
• Encode: configuration exports showing each listed action refused for every agent.
• Test refusals: test records showing each attempt refused and the verdict naming the role-scope bound.
• Review: a dated review record, even when nothing changed.

What typically ends up on the list?

As an illustration, a bank's list might include: filing suspicious activity reports; signing regulatory returns; issuing or revoking credentials; changing any agent's permissions or depth; deleting or editing audit records; dismissing or disciplining staff; entering contracts that bind the firm above a set value; and approving its own or another agent's held actions. A different firm will have different entries, but the self-control entries should appear everywhere.

The list should also cover data, not only actions. An agent that may not see a category of data cannot misuse it; how to decide which data an AI agent may see applies the same discipline to reading.

What should you measure?

• Refusals against the list in production. Each one means an agent tried a listed action and should be investigated.
• New actions inventoried but not yet assessed.
• Agents whose role scope does not include the current list version. The target is none.
• Days since the last review.

Where does it usually go wrong?

The list lives in a policy document. Nobody encodes it, so agents are bound only by what their builders remembered. A list that is not enforced at the moment of action does not exist for the agent.

It is too long. Everyone adds their worries, and the list blocks routine work, so teams seek exceptions. Keep it to actions that pass the tests.

Exceptions creep in. A team argues that its case is special. The point of the list is that it has no exceptions; anything that truly needs one belongs on a hold instead.

Indirect routes are missed. An agent barred from changing permissions raises a ticket asking another system to do it. Test for indirect attempts, not only direct ones.

Where Pryme fits

In Pryme, your list becomes part of each agent's role scope and your own limits, so listed actions are refused and the verdict names the bound. Separately, a small set of actions is withheld at the platform floor for every agent at every depth, whatever any customer configures. See agent governance is a bound, not a model.