Why Does an AI Agent in an ERP System Need Its Own Identity?

A shared human account mixes three types of records

An ERP system usually already knows which employee signed in, what data they queried, and which changes they submitted. The problem arises when an AI agent uses the employee’s account: The “operator” in the logs no longer represents the party that actually took the action.

For example, a finance employee signs in and starts the agent. The agent first queries a purchase order, then reads an invoice, and finally updates the exception case status. If every request uses the same human credentials, the records will show only that “John Wang performed three actions.” They will not reveal:

• Which task John Wang personally requested.
• Which subsequent steps the agent selected on its own.
• Which step only read data and which step changed ERP data.
• Whether a human confirmation screen actually appeared before the change.
• Whether the agent attempted any denied operations.

This affects more than incident investigation. It also makes access revocation difficult. You may want to disable only the agent, but because it shares an identity with an employee, your only option may be to interrupt the employee’s normal work as well.

If you have not yet identified which answers an agent’s authorization records should preserve, use Four Authorization Questions for AI Agents: Identity, Permission, Reason, Consequence to break each operation into four verifiable fields.

Step 2: Start with deny by default, then define each allow condition

Deny by default means that any action not explicitly included in an allow rule will not be executed. An agent must not acquire adjacent permissions on its own simply because they “might be needed to complete the task.”

Do not just write, “The agent can handle accounts payable exceptions.” That statement covers querying invoices, reading supplier data, changing payment statuses, replacing bank accounts, and releasing payments, all of which carry very different risks. Authorization rules must specify four parts: object, action, condition, and exit.

The numbers in the table are sample thresholds for a pilot and should not be treated as formal policy for every company. For an actual deployment, adjust them according to workload, data sensitivity, and the existing approval process. However, each rule must still contain a number, field, or status that the system can evaluate. Do not merely write, “Send high-risk cases to a human.”

Permissions should also be separated by action. Reading, drafting, marking, and making official changes should not be bundled together. If your team is designing this boundary, see Always-on AI assistants must learn when to stop before they can be connected to primary accounts to further distinguish among “may read,” “may prepare,” and “must wait for human confirmation.”

Step 4: Make human escalation a workflow, not just a notification

Many teams implement “human intervention” as an email or chat message while the agent continues executing subsequent steps. A real human escalation must stop the workflow in a recognizable state until a designated person makes a decision in the ERP or approval system.

You can use the following text-based decision tree to review each exception:

The agent proposes the next ERP action
├─ The rules do not explicitly allow it
│  └─ Deny it, record the attempt, and do not automatically retry under another identity
├─ The rules allow it, but it crosses a human boundary
│  └─ Pause the case, generate a summary of the differences, and send it to the designated role for approval
│     ├─ Approved: complete the specified action using the original execution ID
│     └─ Denied or timed out: end the execution without making subsequent changes
└─ The rules allow it, and it does not cross a human boundary
   └─ Execute it and record the input, rule result, and values before and after the change

At a minimum, the human approval screen should show the action the agent wants to take, the differences before and after the data change, the reason it was triggered, the rule that applies, and the subsequent actions that will occur after approval. Showing only “Allow the AI to continue?” forces the approver to consent blindly.

You must also prohibit a common failure path: after the agent is denied, it retries using the human triggerer’s identity. If that fallback exists, separate identities and deny-by-default rules lose their purpose.

Minimum Pilot: Choose Just One Exception and Two Actions

For the first round, do not let the agent handle the entire accounts payable process. Choose one exception that occurs often enough but does not require direct payment, such as “the invoice amount does not match the purchase order.”

Limit the pilot to two actions:

1. Read the invoice amount and purchase order amount for the assigned case.
2. Generate a discrepancy summary and send the case to a human review queue.

Use a dry run during the pilot, meaning the agent tests the process without actually modifying production data. Prepare at least 20 historical cases with known outcomes, including normal matches, amount mismatches, missing purchase orders, cross-company codes, and attempts to read unauthorized fields.

Consider allowing the first low-risk write action only when all the following results can be verified directly from the logs:

• All 20 cases identify both the agent identity and the person who triggered it.
• Every request involving cross-company codes or unauthorized fields is denied.
• Every case escalated to a human stops at the approval point without executing subsequent steps on its own.
• Every denial records the rule number and reason.
• After the agent identity is disabled, it cannot continue through a human account.

The first write action could simply add a “waiting for human review” status. Do not jump directly from read-only access to modifying the vendor master record or releasing payments. This lets the team verify that identities, rules, and logs are genuinely connected before expanding the scope of impact.

Everyday four-panel comic

1. A finance professional gives the AI assistant one assigned invoice folder.
2. Holding that folder, the assistant begins reaching toward other locked records.
3. The professional immediately lowers a boundary and directs it back to the original folder.
4. The assistant places only that folder in the human-review tray; all other records remain locked and await separate authorization.