How to Securely Give an LLM Access to ERP Data
how to securely give an LLM access to ERP data
Also searched as
- is it safe to connect ChatGPT to our ERP
- LLM access control for ERP data
- prevent prompt injection ERP AI agent
- private LLM for ERP data security architecture
Short answer
Treat the LLM as an untrusted component. Give it read-only access through a dedicated, least-privilege path that enforces the asking user's ERP permissions, validate and log every query it generates, require human approval for any write, and decide deliberately where the model runs. Security comes from the architecture around the model, not from the prompt.
Applies to: Any ERP integrated with an LLM assistant or agent, hosted API models or private open-weight models, cloud or on-prem.
How to build a secure LLM-to-ERP path
- 1Classify the data the model could reach: customer and supplier records, pricing and cost, personal data, and any export-controlled or contractually restricted technical data. Decide which classes are out of scope.
- 2Decide where inference runs. If data cannot leave your boundary, serve an open-weight model with vLLM or Ollama on your own GPUs or in a private cloud. If using a hosted API, confirm its data retention and training terms in writing.
- 3Create a dedicated read-only identity for the LLM path with access to approved views, not base tables. Never reuse an admin or integration account.
- 4Enforce the end user's permissions, not the service account's. Pass the user identity through and apply the ERP's role, site and company restrictions, or filter by equivalent row-level security.
- 5Constrain the query layer: allow only SELECT through a parser or a restricted tool set, set statement timeouts and row limits, and block system tables and functions.
- 6Treat retrieved text (documents, notes, supplier emails, descriptions) as untrusted input that may carry hidden instructions, and never let it trigger tools without checks.
- 7Require human approval for any write, and execute approved writes through the ERP's own API, not direct SQL.
- 8Log the user, question, generated query, rows returned and answer, retain logs per policy, and review them regularly.
The threat model for an LLM on ERP data
Four risks dominate. First, data exposure: the model returns rows the user should not see, either because the service account is over-privileged or because answers leak across users. Second, prompt injection: instructions hidden in data the model reads, such as a free-text field on a purchase order or a PDF, steer it to reveal data or call tools. Third, excessive agency: an agent with write tools takes an action no one approved. Fourth, data leaving your boundary through a hosted model API.
The OWASP Top 10 for LLM Applications names these classes, including prompt injection, sensitive information disclosure and excessive agency, and is a useful checklist for review. None of them are solved by telling the model to behave. They are solved by what the model is technically able to do.
Treat the model as you would an intern with a very persuasive tongue: it can be argued into things. Everything it can reach must already be safe to reach.
Access control that actually holds
The most common design flaw is a single powerful service account behind a chat window. Every user then effectively inherits that account's access. Instead, propagate identity: authenticate the user through your SSO, map them to their ERP roles, and apply those restrictions to every query, either through the ERP's own security or through database row-level security and views.
Expose approved views, not base tables. A view such as v_open_orders can hide cost fields from sales users and filter by site. It also gives the model stable, documented columns, which improves accuracy and shrinks the attack surface.
Constrain generation. Parse the generated SQL, reject anything but SELECT, reject multiple statements, enforce row limits and timeouts, and run it under a login that has no other privileges. Showing the user the query it ran gives an audit trail and lets them catch mistakes.
-- Read-only role limited to approved views (SQL Server example) CREATE LOGIN llm_reader WITH PASSWORD = '<from vault>'; CREATE USER llm_reader FOR LOGIN llm_reader; GRANT SELECT ON OBJECT::dbo.v_open_orders TO llm_reader; GRANT SELECT ON OBJECT::dbo.v_item_availability TO llm_reader; DENY SELECT ON SCHEMA::dbo TO llm_reader; -- then re-grant only approved views -- Add row-level security or per-user views for site and company scoping.
Where the model runs and what gets logged
For manufacturing, aerospace and defense data, where the model runs is a primary design decision. Open-weight models (Llama, Qwen, Mistral, Gemma, gpt-oss and DeepSeek class) can be served with vLLM or Ollama inside your network or an isolated cloud, so prompts and ERP rows never reach a third party. Hosted APIs can be acceptable for non-sensitive data if contract terms on retention, training use and regional processing are clear, and if your own compliance obligations allow it.
Your obligations remain yours. Export control rules such as ITAR or contractual flow-downs may restrict who and where data can be processed. An on-prem design makes it easier for you to meet them, but you still need your own controls, access reviews and records.
Log everything needed to reconstruct an answer: user, time, question, retrieved context, generated query, row count and response. Restrict who can read these logs, because they contain sensitive data, and set retention to match policy.
Common pitfalls
- !One admin-level service account behind the chat interface. Every user inherits its access and ERP role restrictions are lost.
- !Giving the model direct write tools. Excessive agency turns a wrong or manipulated answer into a posted transaction.
- !Trusting document and free-text content. Hidden instructions in supplier PDFs or order notes can steer the model.
- !Relying on the system prompt for security. Prompts are advisory, and can be overridden by crafted input.
- !Sending sensitive rows to a hosted API without reading the retention and training terms.
- !No query logging. Without records you cannot investigate a leak or show an auditor what the model accessed.
How an ERP-grounded AI assistant handles this
ERPray is designed around these constraints: read-only by default, the generated query is shown to the user, and ERP roles are respected. It can be deployed on-prem with open-weight models so prompts and rows stay inside your boundary, and any write-back is routed through human approval. Your own policies and review still determine whether a given deployment meets your compliance obligations.
Frequently asked questions
Is it safe to connect ChatGPT directly to our ERP?
Not by default. Safety depends on the access path, not the brand. A direct connection with a broad account risks over-exposure, and hosted processing means data leaves your boundary. If you use a hosted model, apply least-privilege views, per-user permissions, contractual retention terms and logging.
Can prompt injection be fully prevented?
No technique removes it completely. You reduce impact by limiting what the model can do: read-only access, approved views, no autonomous writes, output checks and human approval. Assume injection will sometimes succeed and make sure the worst outcome is still acceptable.
Should the LLM generate SQL or call predefined tools?
Predefined tools are safer and more predictable for common questions. Generated SQL is more flexible. A practical design uses both: tools for frequent, sensitive questions and constrained, read-only SQL generation over approved views for exploration, with every query shown and logged.
Does running the model on-prem make it secure?
It removes third-party data exposure but not the other risks. You still need least-privilege access, per-user permission enforcement, injection defenses, logging and approval for writes. On-prem inference is one important control among several.
Related
Data Platform for ERP Data: Replica, Warehouse or Lakehouse
Start with the smallest thing that removes reporting load from the ERP: a read replica or vendor replication feed. Add a warehouse or lakehouse when you must join ERP data with other sources, keep history, or serve many consumers. Put a governed semantic layer on top, because raw ERP tables are not a usable analytics or AI interface on their own.
CIO briefingBuild vs Buy for ERP Extensions: A CTO Decision Guide
Work down a ladder: configure the standard product, then buy a supported ISV add-on, then build outside the ERP core against its APIs, and only then modify in the core. Each step down raises upgrade risk and lifetime cost. Build only where the capability is a genuine differentiator or no product fits, and keep the code upgrade-safe and owned.
CIO briefingERP Integration Architecture: API vs iPaaS vs ETL
Choose by what the data does, not by tool preference. Use the ERP's own API (or its native bus) for transactional writes that must be validated by ERP business logic, ETL or change data capture for bulk analytical reads, and an iPaaS when you have many endpoints, need monitoring and retries, and lack the staff to run your own middleware. Most real estates need two of the three.
How-toHow to Run an ERP User Access Review (Quarterly Checklist)
An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.
How-toHow to Test ERP Backup and Disaster Recovery
A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items.
How-toERP Patching Cadence: How Often Should You Patch?
Patch the ERP stack in layers on different clocks: operating system and database monthly or quarterly, ERP vendor cumulative updates quarterly or semi-annually, and security fixes on an emergency path measured in days. Test every patch in a sandbox refreshed from production, with a scripted regression and a tested rollback.
AI for ERPAn Air-Gapped Private LLM for SyteLine, Built for Defense Suppliers
Deploy a private LLM on an air-gapped network alongside Infor SyteLine for defense suppliers: no internet egress, ITAR and CMMC-aware architecture.
AI for ERPAI for SAP S/4HANA, Running On-Prem or in Your Private Cloud
Run AI on SAP S/4HANA without sending ERP data to a public API. On-prem and private-cloud architecture, CDS views, OData, and honest deployment trade-offs.
Stuck on ERP + LLM security (vendor-neutral)?
Talk to engineers who work inside ERP + LLM security (vendor-neutral) every week, and who build private AI that answers these questions from your own ERP data.