Is it safe to connect AI to your ERP?

It can be. The standard controls are well known: the AI reads with the permissions of the person asking, starts read-only, needs a person's approval before writing anything, and logs every question and answer. Two things matter beyond those. An AI that reads supplier invoices, settlements and emails can be steered by text inside them, so the step that reads documents should be kept apart from any step that acts. And in a read-only setup, the likeliest harm is a confident wrong answer that a manager acts on, which makes answer accuracy a safety issue as well as a quality one.

What the usual answer says

The usual advice is least-privilege access, strong authentication, read-only access first, full logging and approval rules for sensitive actions, on top of an enterprise-grade provider, encryption and certifications such as SOC 2 or ISO 27001. That is sound, and certifications audit the credential and access controls behind many real incidents. What the advice rarely covers is software that reads text and may act on it.

Instructions hidden in data

The Open Worldwide Application Security Project, OWASP, ranks prompt injection first in its 2025 list of risks for language model applications. Indirect injection happens "when an LLM accepts input from external sources, such as websites or files". On prevention, OWASP says "it is unclear if there are fool-proof methods of prevention for prompt injection".

AgentDojo, a benchmark published in 2024 by Edoardo Debenedetti and colleagues, tests agents "that execute tools over untrusted data". Building on it with a fictitious banking agent and synthetic conversations, Meysam Alizadeh and colleagues reported in June 2025 that simple injected instructions succeeded in around 20% of attacks across 16 tasks and around 15% across 48, on models available then. They also found that "some defenses reduce ASR to zero", though none of the benchmark's built-in defences fully prevented leakage across the board, and that most models avoided leaking highly sensitive data such as passwords.

For a timber business, the external files are the daily paperwork: supplier invoices, buyer settlements, contractor emails, PDFs from mills. The design rule that follows is to separate the steps. Extract fields from documents into records, check them, and only then let anything that answers questions or acts see them, so text in a document is treated as content and never as an instruction.

Reading too much, doing too much

OWASP's entry on excessive agency names three root causes: "excessive functionality; excessive permissions; excessive autonomy". An assistant built to answer questions about stock does not need to create purchase orders. Give each function only the access it needs, and add write actions one at a time, each with its own approval.

The likeliest harm is a wrong answer

In a read-only, question-answering setup, injection can at worst skew an answer. A more common failure is an answer that is simply wrong: a definition that doesn't match the business's, a unit error, stale data. A manager who acts on it has been harmed as surely as by an attack. So a safe setup also shows which records each answer used, so it can be checked, and is tested on questions whose answers are already known before anyone relies on it.

Practical risks: licensing and load

Two questions come up before any security review. ERP licences may treat access by third-party software as indirect use that needs licensing, so check the terms with the ERP vendor. And heavy querying can slow the live system. Connecting the AI to a copy of the ERP data that refreshes daily, rather than to the live system, avoids the load and keeps the first project read-only by design.

Questions for the vendor

Ask whether text from a document can reach any step that acts. Ask what the AI can write, and who approves it. Ask it to show which records an answer used. Ask how it performed on questions with known answers. And ask for a sample of the logs, then read a day of them.

When it doesn't apply

AI used only on public information, with no connection to business systems, carries none of these risks, though staff pasting in private data is its own risk. Read-only reporting assistants that never read external documents carry much less.

Quarri's security page sets out how customer data is isolated, encrypted and audited.

Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.