A finance team built an AI agent, an AI assistant that carries out several steps in a row on its own. It reads invoices and purchase orders in the ERP, the enterprise resource planning system at the core of purchasing, invoices, and payments; finds items where amounts or supplier details don’t match; and hands the exceptions to finance staff. To save effort during testing, it used one finance employee’s account. Queries worked and changes worked, until someone asked: “Was this supplier’s bank detail changed by the employee or by the AI?” The log showed only the same employee account, so nobody could answer.

In July 2026, AWS published an approach for using AI agents to handle exceptions in ERPs such as SAP. Its design centers not on the model but on identity: when the agent works autonomously, it signs in with its own service account; when a person steps in, the system switches to that person’s verified identity. Every action is denied by default and only explicitly allowed ones go through; when an amount crosses a threshold or the AI’s confidence is too low, it emails the responsible person, marks the case as awaiting human input, and stops. Every step is written to a log that can only be appended to, never modified or deleted.

The approach carries over to any system: once AI can act on financial data, it needs its own identity, so logs can show which actions AI took and which a person approved.

Reuse the employee’s account and the log can’t tell who acted

With a borrowed employee account, the “actor” in the log no longer matches who actually acted. An employee starts the agent, and the agent checks purchase orders, reads invoices, and updates case status. Afterward you see only “so-and-so performed three actions,” without knowing which the employee asked for, which follow-up steps the agent chose, whether a human confirmation appeared before data changed, or whether the agent attempted actions that were denied.

Revoking access gets harder too. You may want to stop only the agent, but because it shares an identity with the employee, you’d have to interrupt the employee’s normal work along with it.

Separate identity, deny by default, escalate above thresholds

Separate identity: the system must be able to authorize, disable, and query this identity on its own; adding “Bot” to a display name doesn’t count. Tie the identity to one purpose, such as “accounts payable invoice exceptions,” rather than an AI account shared across the finance department; name an owner who can approve permissions, handle alerts, and disable the identity; and use machine credentials that can be rotated and revoked, never an employee’s password.

Deny by default: forbid everything first, then allow necessary actions one at a time. AWS’s example allows reading any purchase order but posting journal entries only under $50,000. According to AWS’s official documentation, its authorization rules deny any request that matches no permit, and explicit forbid rules always override permits.

Escalate above thresholds: spell out when the agent must stop and hand off to a person, such as amounts above a materiality threshold, changes to supplier bank details, or the AI judging its own confidence too low. When handing off, include the basis and a recommendation, not just “please confirm.”

For why identity must be confirmed by the system rather than claimed in conversation, see Before AI Support Can Change Accounts, Identity Must Come From the System, Not the Chat; for switching permissions at each stop across multiple systems, see When an AI Agent Works Across Systems, It Needs a New Key at Every Stop.

Advertisement

Start with a read-only trial on a small batch of exceptions

Don’t let the agent change production data from the start. Pick a small batch of exceptions that have already been handled, have it run through them read-only under its own identity, and compare its judgments with how finance staff actually handled them. Then check whether the logs separate agent actions from human ones and whether denied attempts are recorded. Once all of that is visible, open up change permissions one at a time.

A separate identity doesn’t make the judgment right

A separate identity makes responsibility traceable, but it can’t guarantee the agent judges correctly. Set thresholds too high and risks slip through; too low and every case goes to a person, defeating the automation. Thresholds should be set by the finance owner according to the company’s materiality standards, with the share of escalated cases reviewed regularly.

Also, this article is about an approach, not a recommendation for a specific product. Implementation differs across ERPs and identity systems; what matters are the two principles: “you can tell who did it” and “nothing not allowed can happen.”

AI handoff card

We plan to let an AI agent handle exceptions in our ERP (such as invoice mismatches or payment exceptions), and want to design its identity and permissions first.
The method comes from this article: https://boosterminiclass.com/en/posts/erp-agent-separate-identity-deny-by-default/
Its view: an AI agent shouldn't use an employee's account, or the logs can't tell whether a person or AI acted and you can't stop just the AI. Give the agent its own identity, deny all actions by default and allow them one at a time, and have it stop and hand off to a person when amounts cross a threshold or its confidence is too low.

First ask me: which kind of exception the agent will handle, which data it will read, which data it might change, and which account it's being tested with now.
Then:
1. Lay out the agent's identity design: purpose name, service scope, owner, credential type, and rotation method;
2. Write a deny-by-default permission list: explicitly allowed read and change actions, the conditions for each (such as amount limits), and explicitly forbidden actions (such as changing supplier bank details);
3. List the situations where it must stop and hand off to a person, and what information to include in the handoff;
4. Design a read-only trial: which batch of already-handled cases to use, what to compare, and what the logs must show.
Mark threshold amounts as "decided by the finance owner" rather than setting numbers yourself.
Advertisement

Share

Share this mini class

If this lesson helps untangle a work bottleneck, share it with someone deciding how to use AI.

References