Connect an AI Agent to Your ERP: What to Check First

To connect an AI agent to your ERP, give it the smallest access that supports one defined task, verify the data it will read, and put every write behind validation and approval. Work through the checks in that order: access, then data quality, then write safety. An agent that reads cleanly and writes cautiously can be widened later, while one that writes early is hard to unwind.

Key takeaways

• Start with a dedicated identity and a role scoped to one task, not a borrowed employee login or an administrator account.
• Let the agent read before it writes, and prove its reading is correct against records your team already knows well.
• Treat duplicates, inconsistent statuses and free-text fields as data quality risks that the agent will inherit and amplify.
• Make writes safe with drafts, validation, idempotency and approval for anything that posts, pays, approves or deletes.
• Name an owner, log every call, and test the off switch before go-live, not after the first incident.

Why does an ERP need more care than other connections?

An ERP is usually the system of record. Orders, invoices, stock, suppliers and ledgers all live there, and they reference each other. A wrong value in one record rarely stays in one place: it flows into reports, payments, reorder points and customer promises.

Most ERPs are also customized. Fields have local meanings, statuses follow your own process, and approval rules exist because someone once got burned. An agent that has never seen those conventions will read the schema literally, and the schema does not explain why a status called closed sometimes still has open lines.

Finally, an agent behaves differently from a script. A script does exactly what it was written to do. An agent interprets emails, documents and notes, then decides which tool to call. That flexibility is the value, and it is also why the boundaries around the ERP must be enforced by the system, not requested in a prompt.

Which access checks come first?

Decide what the agent is for before deciding what it can reach. A role description such as "match supplier confirmations to open purchase orders and flag mismatches" implies a short list of objects and actions. Anything outside that list should be denied by default, and the ERP, not the agent, should do the denying. The principle is covered in more depth in least privilege for AI agents, and the OWASP authorization guidance describes the same idea of deny by default and check every request.

Before connecting, confirm each of these:

• Dedicated identity: the agent has its own service account, so its actions are distinguishable from any person in the audit trail.
• Task-scoped role: the role grants only the objects, companies, warehouses or ledgers the task needs, and nothing inherited from a template.
• Read first: the first phase uses read-only permissions, with write permissions added one action at a time.
• Field-level exposure: sensitive fields such as bank details, salary data or cost prices are excluded unless the task truly needs them.
• Credential handling: secrets are stored in a managed vault, rotated on a schedule, and never placed in prompts, notes or agent memory.
• Separate environments: a test or sandbox instance exists, and its credentials are different from production credentials.
• Revocation: someone has actually tested disabling the account and confirmed the agent stops cleanly.
• Named owner: one person is accountable for the connection and reviews its permissions on a regular cadence.

The distinction between reading, drafting and sending carries over directly to ERP work. Read, draft and send are different permissions, and in an ERP the equivalents are query, create in a draft state, and post. Grant them as separate steps, each with its own review.

How do you check data quality before the agent reads anything?

An agent does not know which records your team quietly distrusts. If the vendor list holds three entries for the same supplier, the agent will pick one, and it may pick the one nobody uses. Data problems that humans route around become silent errors when an agent follows the literal data.

Run these checks on the slice of data the task touches, not on the whole ERP:

• Duplicates in master data: customers, suppliers and items that appear more than once, with different spellings or codes.
• Required fields: fields that the process depends on but that are often empty or filled with placeholders.
• Status meaning: what each status value actually means in practice, written down by the person who works with it daily.
• Units, currencies and dates: whether quantities, currency codes and date formats are consistent across records and entities.
• Stale records: open orders or inactive suppliers that were never closed and would look current to an agent.
• Custom fields: any field whose name no longer matches how it is used.
• Free-text fields: notes, memo lines and attached documents that may contain instructions, contact details or text pasted from outside.

That last item deserves attention. Anything an agent reads can influence what it does next, including text that a supplier or customer typed into a comment field. Keep those fields out of the agent's trusted context where possible, and treat their content as data, never as instruction. Prompt injection in business documents explains what to protect.

Then run a comparison test. Pick a set of real records, ask the agent to summarize or classify them, and have the process owner check the answers against what they know. Disagreements usually point to a data definition that needs writing down, not a model problem. Record those definitions in the tool descriptions so the agent receives them every time.

What makes writes to an ERP safe?

Write safety is a set of mechanisms, and prompts are not one of them. A sentence telling the agent to be careful does not stop a malformed call. Controls that live in the tool layer and in the ERP itself do.

Use this decision guide to sort every action the agent might take:

• Create in a draft state: allowed early, with logging, because a person or a rule must still release the record.
• Update low-risk fields such as notes, tags or follow-up dates: allowed after testing, with sampled human review.
• Update quantities, dates that drive commitments, or supplier and customer master data: allowed only with validation and an approval step.
• Post, approve, pay, release, cancel or delete: human approval every time, until the process owner decides otherwise in writing.
• Anything irreversible or affecting the ledger: keep outside the agent's tools entirely at the start.

Around that guide, add four mechanisms. First, validation: the tool checks that required fields exist, values fall in expected ranges and referenced records are real before it calls the ERP. Second, idempotency: if the agent retries after a timeout, the ERP must not create a second purchase order or a second invoice. Idempotency for AI agents covers the pattern, and Stripe's documentation on idempotent requests is a clear example of how a provider defines it. Third, limits: cap how many records the agent can touch per run and per day, so a mistake stays small. Fourth, a stop switch: a single action that suspends all writes while leaving reads and logs intact.

Tool design matters here too. Narrow tools such as "create draft purchase order line" are safer and easier to test than a general "run any ERP operation" tool. Anthropic's guidance on writing tools for agents makes the same point: clear inputs, clear outputs and descriptive errors help the agent recover without guessing. See also AI tool contracts.

Should the agent use the API or the screen?

Prefer the ERP's supported API or a vendor-maintained integration whenever one exists. An API gives you typed inputs, explicit permissions, predictable errors and an audit trail that matches the system's own. Browser automation, where the agent clicks through the user interface, can reach functions that have no API, but it inherits the fragility of screens and often needs broader credentials.

If browser automation is the only option, tighten everything else: a dedicated account, a restricted role, a recorded session log, and no access to approval or posting screens. The trade-offs are laid out in API vs browser automation for AI agents.

Also check what happens when the ERP is slow, down or in maintenance. The agent should stop and report, not retry in a loop or fall back to another path that skips a control.

What does a safe first rollout look like?

Here is an illustrative scenario, not a real case. A distribution company wants an agent to match supplier confirmation emails against open purchase orders and flag differences in quantity or delivery date.

The team begins with read-only access to open purchase orders for one purchasing group. They compare the agent's matches against ten orders the buyer knows by heart, and they discover that a status field is used two different ways. They document the meaning and add it to the tool description. Next, the agent is allowed to write a flag into a notes field and to create a draft change request, nothing more. A buyer reviews each draft for a trial period. Only after the review shows consistent results does the team consider letting the agent propose a date change, still requiring approval before the ERP updates.

The same sequence works as a general plan:

• Define the single role and the records it touches, in writing.
• Create the dedicated identity with read-only access in a test environment.
• Run the data quality checks on the relevant slice and write down status and field definitions.
• Run the comparison test with real records and a person who knows them.
• Add draft-only write tools with validation, idempotency, limits and logging.
• Test failure cases: expired credentials, duplicate submissions, missing fields, ERP downtime.
• Move to production with the same scope, human review on every write, and a tested stop switch.
• Review the logs on a schedule, then widen permissions one action at a time.

If credentials expire during any of this, the agent should stop and ask, as described in what an AI agent should do when a connection expires. Before go-live, run the items in the acceptance checklist for AI agent integrations.

How does Be Human handle an ERP connection?

Be Human treats the ERP connection as part of the agent's operating setup, not a one-time installation. A first engagement defines one useful role, the records and tools it needs, the approval boundaries and an observable success criterion. Access is scoped to that role, writes start as drafts, and approvals stay with your people. Under managed operations, Be Human can monitor the integration, run recurring evaluations, review permissions, maintain the connection when the ERP changes and respond to incidents, with the changes controlled and documented.

Frequently asked questions

Should the agent connect to production or a test copy first? Start with a test or sandbox copy so you can try failure cases without consequences. Then move to production with the same narrow, read-only scope, and add writes only after the comparison tests pass. Make sure the test credentials cannot work against production.

Do we need to clean all our ERP data before connecting an agent? No. Clean and define only the slice of data the agent's task touches, since a full cleanup can delay the project without improving the first role. Document the definitions that matter, such as status meanings and custom fields, and extend the cleanup as the agent's scope grows.

Which ERP actions should an agent never perform alone? Posting to the ledger, approving or releasing payments, deleting records and changing bank or master data should require human approval, at least at the start. The agent can prepare the draft, gather the evidence and explain its reasoning, so the approver decides quickly with full context.

Who should own the connection inside the company? One named person, usually the process owner or an operations lead, should be accountable for scope, review and the stop switch. IT or a provider can maintain the technical side, but the business owner decides what the agent may do. Write this down as part of the role definition.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.