Writing the never list: identify where AI agents should, start, and stop, acting

Philip Paz

VP of Technology

The AI risk conversation every financial institution is having

Our discovery process with a potential client inevitably includes questions about their business goals, existing technology infrastructure, and operational challenges. Recently, we’ve found that potential clients are increasingly interested in discussing AI risk. These conversations tend to center on two topics:

AI risk threshold: the actions an agent should never take without human approval
AI risk appetite: how far and how fast an agent can go with everything else

One common result of these conversations is a short, specific list of actions AI agents must never execute on their own.

Zennify CEO Michael Rouleau said as much when discussing the new opportunities Claudeforce affords for financial services:

“When your risk committee asks what (AI) could do to us, that’s the list they want, and it needs to be short.”

The goal isn’t to limit what AI agents can do. It’s to define and enforce the boundaries that allow them to do more safely.

Making the “never list” a priority.

When a CFO asks how we made an agent safe enough to approve, we can offer a rather safe answer: right now, the agent only reads. It can pull a client’s positions, holdings, cash balances, recent activity, and open service cases from Salesforce, then assemble everything an advisor needs before a client meeting. It doesn’t change anything, place trades, move money, update an address or beneficiary, or send the client a message. Each of those actions still belongs to a human representative.

For years, the line between what an agent could and couldn’t touch ran between the back office and the front office. Agents stayed in the back, focused on internal operations work like sentiment analysis on service calls, where a mistake stayed inside the institution and never reached a client. Anything client-facing, like advisor prep or direct client communications, was off limits.

We’re seeing that line slowly decay. But the new boundary isn’t simply between reading and writing. It’s about what an agent is authorized to access, what it can recommend, and what it is permitted to execute. Each of these requires its own controls, because even reading can introduce risk depending on the information being accessed.

AI agents are increasingly capable of taking action, but not every action carries the same level of risk. Creating a service case may be appropriate without intervention, while changing an account or executing a transaction may require explicit human approval. The distinction comes down to authorization, risk, and the controls surrounding each action.

“In financial services, you’d better be able to trust your agent all the time.”‍

Trusting an AI agent means trusting the controls around it. Even when an agent makes a mistake, the architecture should prevent it from executing an action it isn’t authorized to take. That’s why the never list has to be written before your team starts designing and building the agent. When you decide to reduce an agent’s responsibilities after it’s already launched, you’re retrofitting controls onto a live system, revoking tools the agent already uses, adding approval steps, and retesting workflows your team already relies on.

Who owns the never list?

Creating a never list is a process that requires input from both internal and customer-facing teams. Business leaders know where an agent would save the most time; examiners know which practices will draw regulatory scrutiny; risk and compliance leaders (such as a chief risk officer or chief compliance officer) understand regulatory exposure.

In practice, that means one working session with three teams in the room:

Business owners: Understand the workflow and where mistakes cost the most. Owns which tasks the agent takes on and where a person stays in the loop.
Risk or compliance leads: Understand what an examiner will ask. Owns which items go on the never list and how each one is documented for approval. Bring them in at the start, since they’re the people who get your agent approved.
Salesforce platform owners: Understand what your org’s permissions, sharing rules, and profiles already allow. Owns confirming which items Salesforce already blocks and which need new controls.

How to run the never list discovery process.

We frequently see otherwise similar financial institutions with entirely different appetites for AI risk. One institution asks what more it can automate. The other asks whether it needs to automate anything at all.

We typically open with a few questions:

Are you exploring what AI agents can do for your business, or investing to keep pace with competitors?
Why is now the right time to onboard an AI agent?
What does your timeline for moving an agent from prototype to production look like?

The answers usually show how an institution thinks about AI. Two organizations can face the same competitive pressure and still approach AI in completely different ways, depending on whether they see it as a line item to minimize or a capability to build on.

“If you treat AI as a cost, you won’t want to do much with it. If you treat it as an investment, we can build a real roadmap together.”

What items belong on the never list?

The most useful discovery conversations are about deciding where the agent can operate independently, where a person needs to approve an action, and where the boundaries should be absolute. Those decisions become the foundation for an AI roadmap the organization can confidently execute.

“Never, ever, ever let an agent make the final credit decision.”

We start with four action categories that AI should never act on:

Anything that moves money. AI should never execute trades, run automated trading or rebalancing without a person in the loop, transfer funds, issue disbursements, or grant fee waivers.
Anything that changes a record of fact. AI should never independently change sensitive records such as account identifiers, household relationships, beneficiaries, addresses, or KYC information without the appropriate verification and authorization. Some changes may be permitted through a controlled approval workflow, while others should remain entirely outside the agent’s authority. I've seen agents put two clients in the same household because they share a last name. A fuzzy match is not a family.
Anything that speaks to the client. AI should never give a client a personalized investment recommendation or market to clients using data you haven't unified into a single client view.
Any decision a regulator expects a person to own. AI should never make the final call on credit decisions, suitability, or exceptions to policy.

Don’t forget to consider user permissions when adding list items. AI should never grant access, change a user’s role, or edit sharing rules that protect your data. If an agent can change those controls, it can work around every other item on the list.

Assigning a permission level to each item.

Once the never list is defined, assign each action to one of three categories:

Prohibited: The agent cannot execute the action under any circumstances within its assigned role. For example, an agent that prepares advisors for client meetings is never connected to the trading system, so it has no way to place a trade.
Approval required: The agent can prepare or recommend the action, but execution requires approval from an authorized person. For example, an agent spots $25,000 in excess cash in a client’s account and writes a recommendation to the client record, but the advisor decides whether to act on it.
Permitted: The agent can execute the action independently within defined permissions, policies, and operational limits. For example, an agent can open a service case and route it to the right team without waiting for sign-off.

Salesforce permissions, identity controls, and tool-level authorization work together to enforce those boundaries. Salesforce permissions provide an important foundation: if an advisor’s profile can’t edit a client’s beneficiary, an agent working on that advisor’s behalf shouldn’t be able to either. But an agent’s effective access also depends on how the integration is configured. When an agent operates through an MCP server or integration user, we must ensure that the appropriate user identity and authorization rules are enforced before an action is executed.

Map your agent's guardrails before they go live.

The never list isn’t simply a document describing what an agent shouldn’t do. It’s a set of boundaries that must be translated into permissions, approval workflows, and enforceable technical controls, because telling an agent not to take an action is very different from ensuring it can’t.

If you're scoping a first headless agent, write the never list before the code. That’s where our Headless Access offering starts: it allows agents to securely access Salesforce data outside the Salesforce UI, while preserving applicable Salesforce authorization controls and enforcing additional access policies at the integration and tool layers. When you're ready to add narrow writes behind a named approver, Headless Production is the next step.

Check out our Change Appetite Matrix for a deeper look at where your institution’s appetite sits. When you’re ready to start your own never list, talk to our team.