To give an AI (artificial intelligence) agent safe access to your ERP (enterprise resource planning) system, grant it the narrowest access that does the job: read-only views instead of whole databases, drafts instead of postings, and a human approval for anything that changes money, stock or master data. Data Department, an applied machine learning consultancy in Istanbul, designs agent architectures on this principle for manufacturers, distributors and retailers.
Why is an agent different from a normal ERP user?
An AI agent is software built around an LLM (large language model) that can decide which tools to call: run a query, read a document, create an order. That ability is what makes it useful. It is also what makes it risky.
A human user reads instructions from their manager. An agent reads instructions from any text it processes: emails, supplier PDFs, web pages, the output of other tools. If one of those texts contains a hidden instruction, a broadly connected agent may follow it. The OWASP (Open Worldwide Application Security Project) Top 10 for LLM Applications 2025 lists prompt injection as the first risk and "excessive agency" (more permissions or autonomy than the task needs) as the sixth.
The practical conclusion is simple. Treat an agent like a new employee on their first day. Give it a badge that opens the doors it needs, not a master key to the building.
What can go wrong with broad access?
Most failures we see in agent pilots are not dramatic attacks. They are ordinary design shortcuts:
- The agent connects with a shared administrator account, so every action looks like it came from IT (information technology).
- It can query every table, including payroll and customer bank details, because nobody defined a smaller scope.
- It can post documents directly, so a misread quantity becomes a real purchase order.
- Nothing records which prompt, which data and which tool call led to an action.
Each shortcut saves a day in the pilot. Each one makes the agent impossible to approve for production.
What does "a badge, not a master key" mean in practice?
Sort every capability the agent needs into one of four tiers before you connect it to anything:
| Tier | What the agent may do | Example in an ERP | Control |
|---|---|---|---|
| Read | Query curated, read-only views | Open orders, stock by warehouse, delivery dates | Dedicated database views, row-level filters |
| Draft | Prepare a record without posting it | A draft purchase requisition or a draft customer reply | A person reviews and posts |
| Act with approval | Execute after a named person confirms | Change a delivery date, release a blocked order | Approval step in the workflow, logged |
| Never | Not available to the agent at all | Payments, master-data changes, user rights, deletions | Not exposed as a tool |
Most useful ERP agents live in the first two tiers. If a use case needs the "never" tier, it is usually not an agent use case.
How should read access be designed?
Do not point the agent at the production database. Create a small set of views that answer the questions users actually ask, with clear column names and business definitions. An NL2SQL (natural language to SQL, structured query language) assistant that works on three well-documented views gives better answers than one that guesses its way through hundreds of raw tables.
Apply the requesting user's permissions, not the agent's. If a sales manager in one region asks a question, the agent should see only what that manager may see. Use a read replica or reporting database where possible, so a badly formed query cannot slow down order entry.
Which actions need a human approval?
A useful rule: anything that sends, pays, deletes or changes a master record needs a human click. The agent prepares the action and explains why; a named person approves it in the ERP's normal workflow.
This is not a temporary training-wheels measure. For high-impact actions it is the right permanent design. The agent saves the time spent gathering information and preparing the record. The person keeps the accountability.
How do you make agent actions auditable?
Give the agent its own identity in the ERP and in every connected system, separate from any human user and from IT service accounts. Then log, for every action:
- who asked (the human user) and on whose behalf the agent acted;
- which tool was called, with which parameters;
- which data the agent read before deciding;
- who approved the action, and when.
With this log you can answer "who did this, and why?" in minutes. Without it, one unexplained change can end the project.
Checklist before connecting an agent to your ERP
- [ ] The agent has its own identity, not a shared or administrator account.
- [ ] Read access goes through named, documented views, not raw tables.
- [ ] The user's own permissions limit what the agent can see.
- [ ] Every write action is a draft or requires approval by a named person.
- [ ] Payments, master data, user rights and deletions are not exposed as tools.
- [ ] Every tool call is logged with user, parameters, data read and approver.
- [ ] Text from emails, documents and web pages is treated as data, never as instructions.
- [ ] You have written down the worst thing this agent could do with the access it has.
If the last item makes the team uncomfortable, reduce the access before the pilot, not after. A free 30-minute AI opportunity review is a reasonable place to test an agent design with someone outside the team. Our generative AI assistants and agents page describes how we build these systems, and our article on document AI in manufacturing covers the document side.
Frequently asked questions
Can an AI agent post transactions in our ERP directly?
Technically yes, but we do not recommend it for anything that affects money, stock or master data. Let the agent prepare a draft and let a named person post it in the normal workflow.
Is read-only access always safe?
It is much safer, not automatically safe. Read access can still expose salaries, prices or customer data, so limit it to curated views and apply each user's own permissions.
Does the agent need its own user account?
Yes. A separate identity lets you restrict its rights, switch it off without affecting anyone else and trace every action back to the agent and the person who asked.
Where should we start with an ERP agent?
Start with a read-only question-answering use case on a few curated views, such as order status or stock availability. Add draft and approval steps only after users trust the answers.