AI ERP Integration: How to Give an Agent Least-Privilege Access to Your ERP

The safest AI ERP integration gives the agent its own ERP user with read rights and nothing else. Not the connector account you already have, not an admin key, and no write path at all until one specific, approved action needs one. The restriction lives in the ERP's permission system, where the agent cannot argue its way past it.

This is the pattern we used when we gave a governed agent live access to Odoo for a 52-branch jewellery group, and it is the step most AI ERP integration guides skip. The pages ranking for this query cover benefits and vendor roundups. None of them say which user the AI should log in as. That is the whole question.

What does least-privilege access mean for an AI agent on an ERP?

Least privilege means the agent holds exactly the rights its job needs and no more. For an agent that answers questions, that is read access to the models it reports on, scoped to the companies it reports across, with create, write and delete withheld at the permission layer rather than in its instructions.

The OWASP Top 10 for LLM Applications lists this failure as LLM06:2025, Excessive Agency, and breaks it into three causes: excessive functionality, excessive permissions and excessive autonomy. Its first prevention item is the one this post is about: "Limit the permissions that LLM extensions are granted to other systems to the minimum necessary in order to limit the scope of undesirable actions."

The distinction that matters is where the limit lives. A system prompt that says "never modify records" is a request. A user account that cannot modify records is a fact. We have written before about why a system prompt is not a governance control; the ERP user is where that principle becomes concrete.

Why should the agent's ERP user be read-only by default?

Because an ERP agent already carries two of the three ingredients for a data theft, and write access adds a worse failure on top. Read-only caps the worst case at disclosure of what the user can see. With write rights, the worst case is a posted journal, a changed bank account on a vendor record, or a deleted invoice.

Simon Willison, the creator of Datasette and a co-creator of Django, calls the combination of private data access, exposure to untrusted content and the ability to communicate externally the lethal trifecta: "If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker." An ERP agent that reads vendor emails, WhatsApp messages or uploaded invoices meets all three. You cannot remove the private data, since reading it is the job. What you can do is make sure the credential it holds cannot change that data, so a successful injection reads and does not post.

The price of getting this wrong is not abstract. IBM's Cost of a Data Breach Report 2026 puts the global average breach at USD 4.99 million, up 12% on the prior year and a record high. Verizon's 2026 Data Breach Investigations Report found that 31% of breaches now start with a software vulnerability, overtaking stolen passwords as the top way in, which still leaves credentials as the second most common entry point. An over-privileged API key sitting in an agent's environment is exactly that kind of credential.

Why not reuse the connector account you already have?

Because the account you already have is almost certainly over-privileged. Sync connectors are set up to make the integration work, not to be minimal, and nobody goes back to trim them once the nightly job runs clean. Handing that account to an agent inherits every right it was never meant to use.

This is what we found at Parakkat Group. The existing Odoo sync account, which only ever read data into the command centre, held full create, write and delete rights on invoices and journals (account.move), payments (account.payment), purchase orders and partner records. We did not assume this. We checked it with Odoo's check_access_rights call for each model and each operation, and every write came back allowed. The connector never used those rights. They were pure exposure, sitting in an environment file, waiting for the day that host or that file leaked.

Two decisions followed. The agent would get its own genuinely read-only user, and the sync account would be downgraded to read-only as well, because a service that never writes should not be able to. The second decision is the one most teams need and few make.

How do you create a read-only ERP user for an AI agent?

Create a dedicated internal user in the ERP, grant it read or reporting roles only, scope it to every company it needs to report across, and generate an API key for that user. The whole job takes an administrator about 15 minutes, and it is the entire security model. Here is the Odoo version.

• Create a new Internal User with a login named for the agent, not for a person. When the key rotates or the agent is retired, nobody's personal access is affected.
• In Access Rights, give Accounting the read-only or auditor level, never Accountant or Billing, which permit posting and editing. Give Inventory, Purchase and Sales a reporting or read-only user level, never a manager or officer role.
• Leave the Settings and Administration groups unticked. Nothing about answering questions needs them.
• In multi-company access, tick every company the agent should report on. At Parakkat that was all of the roughly 50 companies in the instance, matching the sync account's scope. Wide on read, zero on write.
• Generate an API key from Preferences, then Account Security, then New API Key. Odoo's own documentation is blunt about what that key is: "You should store the API Key as carefully as the password as they essentially provide the same access to your user account." The key is the user. That is why the user has to be read-only.
• Store the login and key in the agent's credential environment, never in a prompt, a skill file or a shared document.

Other ERPs, same shape. Zoho Books and Zoho CRM issue OAuth scopes with separate READ and CREATE or UPDATE grants per module, so request READ scopes only. Tally has no per-user API permissions at all; its XML gateway accepts export and import requests from anything that can reach it, so the read-only boundary has to live in the connector, which sends export requests and has no code path that builds an import. We covered the connector side of each of these in our post on AI integration services for Odoo, Zoho and Tally.

If you would rather we set this up alongside your ERP administrator, this provisioning step is part of every engagement under our AI integration services, and it is finished before the agent sees a single record.

How do you prove the guardrail works before the agent goes live?

Attempt a write with the agent's credentials and confirm it fails. A guardrail you have not tried to break is a belief, not a control. The test takes minutes, produces a log line you can show an auditor, and should be repeated after every ERP upgrade or permission change.

Our smoke test on the new user does two things. First it reads something specific and useful, a single vendor's ledger for a date range, to confirm the scope is wide enough to do the job. Then it tries to create a record on each of the four models the old account could write to and expects "access denied" on every one. That denial is the guardrail proving itself. We also call check_access_rights for create, write and unlink on those models and expect a refusal across the board, because a permission granted by mistake will not announce itself.

Then the agent goes live with one small tool: query live Odoo, read-only, with a note on when to use it instead of the pre-built reports. That split matters for cost and speed. The six ERP reports we rebuilt for the group run from nightly rollups and open in about a second; the live tool is for the question nobody anticipated, on a field nobody added to the sync. The agent gets both and knows which to reach for.

What happens when a task genuinely needs a write?

It gets a separate, explicitly approved action with its own credential, never a write right on the agent's user. Reads stay free and instant. Anything that changes the system of record is drafted by the agent, waits for a human yes, and executes through a helper the agent does not control.

At Parakkat, Odoo is read-only for the AI permanently. The agent can manage store content and adjust advertising through the same drafts-then-waits pattern, and it cannot be persuaded past a permission it does not hold. Posting into the accounting system of about 50 companies from an assistant is a risk we keep closed by default. If a real write-back need appears, we build one named action for it, approved by the group's owner, rather than opening a path. The one-time-code gate that does this inside our own AI operating system is described in the Neogen AI OS case study, and the full command-centre build is in the Parakkat case study.

The pattern generalises past ERPs. Two identities, not one: a read identity the agent holds, and a write identity it can only ask for. Whether the write identity is a root-owned helper behind a forced command or an approval queue in a browser, the property is the same. The agent can see everything it needs and change nothing on its own.

Frequently asked questions

Does a read-only ERP user make the agent useless?

No. Nearly everything a founder or finance team asks is a read: which branches are below reorder level, what a vendor is owed, how this month's category sales compare with last. The agent answers all of it from a read-only user. The rare write is the exception, and it deserves a deliberate action rather than an open door.

Do we need our ERP vendor or implementation partner to do this?

Usually not. In Odoo, creating the user, setting access rights and generating an API key is an administrator task through the standard Settings and Preferences screens, with no code involved. If your Odoo is hosted by a partner who holds the only admin login, they do the 15-minute step and send you the login and key. The rest happens on the agent side.

Should the read scope be limited too, or only the writes?

Limit both. Least privilege applies to reads as well: if the agent's job is stock and sales, it does not need the Employees or Payroll modules, so do not grant them. Wide company scope is fine when the agent reports across every branch. Wide module scope is not.

What if our ERP has no per-user API permissions, like Tally?

Then the boundary moves into the connector. The connector should have no code that builds a write request, and the agent should only ever reach Tally through that connector. It is a weaker guarantee than an ERP-enforced permission, and worth saying so to your auditor, but it is still a fact about what the software can do rather than an instruction the agent might ignore.

How often should the permissions be re-checked?

After every ERP version upgrade, every module install and any change to the agent's role, plus a calendar check each quarter. Upgrades can add new groups or change what an existing role permits. Re-run the same smoke test and keep the output.

If you are planning an AI ERP integration and want the permission model settled before anything connects, talk to us. We will provision the user with your administrator, run the denial test in front of you, and hand over the log.