Build the agent's ERP role from its job, not from an existing staff role. List the transactions the job needs, grant only those, split read access by module and entity, and run your segregation-of-duties check on the result. Then give each permitted action a depth on the platform, so the ERP decides what is possible and the platform decides what is allowed.
Why do ERP connections end up over-permissioned?
An ERP holds most of a company's finance and operations in one system: ledger, payables, receivables, purchasing, inventory, often payroll. Its roles are broad by design. A standard "accounts payable clerk" role may include dozens of transactions, from viewing invoices to editing suppliers. When an agent needs access, the quickest route is to copy a staff role, or to give the integration user wide rights "for now". Both leave the agent able to do far more than its job.
That matters more for an agent than for a person. A person with excess rights rarely uses them. An agent with excess rights may be instructed, by a cleverly worded document or a mistake in its brief, to use them. The OWASP Top 10 for LLM applications names excessive agency as a risk for exactly this reason.
The ERP security or controls lead owns the role design. The process owner for each module, such as the accounts payable lead, decides what the agent's job requires. The financial controller signs off segregation of duties. The wider finance position is in AI agents for finance: books you can audit.
How do you build the role, step by step?
- Person, process owner: writes down the agent's job. For example: "capture supplier invoices, code them, match them to orders, route for approval".
- Person, ERP security lead: maps the job to transactions or interface calls. Only those the job needs. Everything else is excluded by default.
- Person: splits read access. By module (payables, not payroll) and by entity (the companies the agent serves). Read access is where over-permissioning hides, because it feels harmless. It is not: an agent that can read payroll can be asked about salaries.
- Person: restricts fields. Where the ERP supports it, block write access to sensitive fields within allowed transactions, such as supplier bank details within supplier maintenance.
- Person, financial controller: runs the segregation-of-duties check on the agent's role, treating the agent as a user like any other.
- Person: sets the depth each action needs on the platform. The ERP role is the outer limit; the platform sets how far the agent may go inside it.
- Agent, depth 1: runs read-only first against live data, proposing actions without taking them.
- Person: enables writes as the agent is certified to the depth each needs.
Which actions should get which depth?
| ERP action | In the role? | Depth | Stays with a person |
|---|---|---|---|
| Read payables, orders, receipts | Yes | 1 | Nothing |
| Read payroll or HR modules | No | None | Payroll team |
| Create invoice records | Yes | 3 | Rejected captures |
| Code and match invoices | Yes | 3 | Exceptions |
| Create purchase orders | If the job needs it | 2 or 3 | Approval |
| Approve purchase orders or invoices | No | None | Approvers |
| Create or edit suppliers | No | None | Supplier master team |
| Post journals | No | None | Accountants |
| Release payments | No | None | Payment authorisers |
| Change configuration or users | No | None | ERP administrators |
Creating purchase orders deserves its own design; see letting an AI agent create purchase orders in your ERP.
What does segregation of duties mean for an agent?
The same as for a person. No single user should be able to complete a sensitive process from start to finish: create a supplier and pay it, raise a purchase order and approve it, post a journal and approve it. Your controls team already has a list of conflicting pairs. Run it against the agent's role.
There is one difference. If two agents each hold one half of a conflicting pair, and an orchestrator coordinates them, the conflict is back. Check combinations across agents that can work together, not just each role alone.
What stays with a person?
Approvals, supplier changes, journals and payments, in almost every setup. Also the role itself: the agent cannot request more rights, and any change to its ERP role goes through the same access request and approval as a person's would. Include the agent in your periodic access reviews.
How do you revoke access?
Remove a transaction from the role and that action stops in the ERP. Withdraw the capability on the platform and the agent stops attempting it, even though the ERP would still allow it. Lock the integration user to stop everything. A lapse, or a certification run that clears no depth, drops the agent to depth 1 the same day. Test each level before go-live.
What is recorded?
The ERP's change log records every write by the integration user. The platform files a verdict for every attempt, allowed or not, with the bounds checked and the one that decided. Refused attempts are often the most informative entries: an agent repeatedly trying an action outside its role suggests either a brief that needs fixing or input that is trying to steer it.
Where does it usually go wrong?
The role is copied from a person. It carries years of accumulated rights. Build from the job.
Read access is granted to "everything in finance". Then a support question about an invoice becomes a route into payroll data.
Interface users bypass the user interface's checks. Some ERPs enforce approval rules in screens but not in their interfaces. Test that the interface enforces what you expect.
Ticketing and ERP agents share a user. Keep integrations separate per system; the parallel guidance is in connecting an AI agent to your ticketing system without over-permissioning it. Which systems an agent can reach is covered in which accounting systems an AI agent can connect to.
Questions people ask
Is a read-only ERP connection safe?
Safer, not safe. It still exposes data, and an agent that can read everything can disclose everything. Scope reads as carefully as writes.
Can one agent work across several ERP entities?
Yes, with entity scoping in the role. Grant each entity explicitly, and check segregation of duties per entity.
How often should the agent's role be reviewed?
With your regular access reviews, and whenever the agent's job changes. A new capability should never arrive by quietly widening the role.