What permissions should an AI agent get in your ERP or CRM? A least-privilege checklist
Give an AI agent its own user, read and draft rights on the records its task needs, and no rights to submit, delete or pay. A checklist for ERP and CRM.
The short answer
Give each AI agent its own user in your ERP or CRM, with least-privilege permissions: read access to the records its task needs, the right to create drafts, and nothing more. Keep submit, cancel, delete, payment and permission changes with people. Log every action under the agent's name, cap its volume, and review its rights each quarter.
Key takeaways
- Every agent gets its own named user and role; an agent that borrows a person's login cannot be audited or switched off cleanly.
- The default grant is read plus create-draft on the document types the task touches, with submit, cancel, delete and pay held by people.
- In KPMG's survey of 204 leaders at US firms with $1 billion or more in revenue (28 April to 25 May 2026), 53% were deploying AI agents.
- In the same survey only 26% had full real-time visibility of AI operating costs, so volume caps belong in the permission design.
- Rights are widened one step at a time, after a review of the agent's log and exception rate, never because a demo went well.
In this article
Why agent permissions are a design decision, not an IT ticket
An AI agent's permissions set the worst thing it can do on a bad day. A person with broad rights uses judgement about which ones to exercise. An agent exercises whatever its instructions and its inputs push it toward, including a malformed email or a supplier invoice written to mislead it.
Deployment is already widespread among large firms. In KPMG's AI Quarterly Pulse, a survey of 204 US leaders at firms with $1 billion or more in revenue run from 28 April to 25 May 2026, 53% said they were deploying AI agents. The share orchestrating multiple agents rose to 18% from 9% the quarter before.1 Gartner's 2026 CIO and Technology Executive Survey puts deployment lower, at 17% of organisations, with the data period not stated.2 Either way, many agents are going live on systems that hold money, prices and customer records.
Our view: the permission design should be written before the prompt, and signed by the person who owns the process. The OWASP project's guidance on excessive agency in LLM applications covers the same principle from the security side: limit what an agent can call, what those calls can do, and whose authority they run under.3 This checklist applies it to ERP and CRM roles.
Give every agent its own user
Each agent needs its own named user, its own role and its own credentials. Never let an agent run under a person's login or a shared admin account.
A dedicated user does three jobs. It makes every record the agent touches show the agent as the author, so audits can tell agent work from human work. It lets you switch the agent off by disabling one user, without locking out a colleague. And it lets you grant rights to the task, not to whoever happened to set the agent up.
Store the agent's credentials in a secrets manager, rotate them on a schedule, and scope API keys to the agent's role. If your ERP or CRM supports it, restrict the agent user to API access only, so nobody can log in as it through the browser.
What should an agent be allowed to do?
Read what the task needs and create drafts. That is the default grant for a first agent, and most should stay there for their first months.
Most ERP and CRM platforms separate rights by action. ERPNext, for example, sets read, write, create, submit, cancel and amend rights per role and per document type.4 Other platforms use different names for similar controls. The tiers below map onto most of them.
Permission tiers for an agent
- Read the records the task needs
- Create and edit drafts
- Submit or post
- Cancel, amend, delete
- Pay, change prices, change permissions
Read: narrower than you think
Read access should cover the document types and fields the task uses, not the whole module. An invoice-matching agent needs purchase orders, receipts and the supplier record. It does not need payroll, bank details or every customer's history. Where the platform supports field-level or record-level rules, use them: hide bank account fields, and restrict records to the company or territory the agent serves.
Write: drafts, not transactions
Write access should end in a draft that a person submits. A draft sales order, a draft purchase invoice, a CRM task or a suggested field update can be checked and discarded. A posted journal entry or a sent quote cannot be quietly undone. Our guide to the controls an invoice agent needs shows the draft-and-submit pattern on a real document flow.
What should an agent never be allowed to do?
Five rights stay with people on any first agent, whatever the vendor's demo shows.
| Right | Why it stays with a person |
|---|---|
| Submit, post or approve | It turns a draft into a transaction others rely on |
| Cancel, amend or delete | It removes evidence and can hide an earlier error |
| Payments and bank details | A wrong change moves money out of the business |
| Prices, discounts, credit limits | Errors reach customers and margins at once |
| Users, roles and permissions | An agent that can grant rights can grant itself any right |
Our default list for a first agent on an ERP or CRM.
The last row matters most. Any agent that can edit roles has, in effect, every right in the system. Check for indirect routes too, such as an import tool or a workflow rule the agent can trigger that runs with higher privileges.
Approval gates, logs and volume caps
Permissions decide what an agent can do. Gates, logs and caps decide how much damage a mistake does before someone notices.
Approval gates
Route every draft to a named approver or an exception queue, with the agent's reasoning attached. The approver needs to see what the agent matched against and why it chose this value. A gate where people click "approve" on a hundred drafts without reading them is no gate, so keep queues small enough to read. Our escalation design for support agents covers the same handover logic for customer-facing work.
Logs
Log every read and write under the agent's user, with the input that triggered it, the model's output and the record it changed. Keep the log outside anything the agent can edit. When something goes wrong, the log is how you find every record the same fault touched.
Volume caps
Cap how many records an agent can create per hour and per day, and alert when it nears the cap. A loop or a flood of malformed inputs should hit a ceiling, not your month-end. Caps also control cost. In the KPMG survey above, only 26% of leaders had full real-time visibility of their AI operating costs (28 April to 25 May 2026).1 Our note on that survey covers the cost side in more detail.
When to widen an agent's rights
Widen rights one tier at a time, after reviewing the agent's log, its exception rate and its errors over a set period. Never widen them because a pilot looked good in a meeting.
The failure record argues for patience. Gartner predicted in June 2025, more than a year before this post, that over 40% of agentic AI projects will be cancelled by the end of 2027. It named escalating costs, unclear business value and inadequate risk controls as the causes.5 Least privilege is the cheapest risk control on that list.
Our view: an agent should earn the right to submit by showing a low, stable error rate on drafts, measured over weeks, with the owner's signature on the result. Even then, start with submit rights on low-value documents and keep payments with people. If you are still choosing which process to automate, our scoring model treats reversibility as one of its four inputs, for the same reason.
On our AI automation work, the agent's user creates and saves drafts and a role held by a person submits them. We design builds that way because it is the simplest control that holds up in an audit.
Sources
- KPMG, AI Quarterly Pulse Q2 2026: 204 US leaders at $1bn+ firms, 28 Apr–25 May 2026 (Jun 2026)
- Gartner, 2026 CIO and Technology Executive Survey (Apr 2026); data period not stated
- OWASP GenAI Security Project, LLM06:2025 Excessive Agency (2025)
- Frappe, ERPNext manual: role based permissions
- Gartner prediction (Jun 2025): over 40% of agentic AI projects cancelled by end of 2027(dated)
