# How to Securely Give an LLM Access to ERP Data > Source: https://netray.co/erp-help/cto-secure-llm-access-to-erp-data > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind cio ## System it-leadership ## Erp ERP + LLM security (vendor-neutral) ## Module AI Security and Governance ## Query how to securely give an LLM access to ERP data ## Alternate Queries - 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 ## Applies To Any ERP integrated with an LLM assistant or agent, hosted API models or private open-weight models, cloud or on-prem. ## Steps ### How to build a secure LLM-to-ERP path **Items:** Classify 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. Decide 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. Create a dedicated read-only identity for the LLM path with access to approved views, not base tables. Never reuse an admin or integration account. Enforce 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. Constrain 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. Treat retrieved text (documents, notes, supplier emails, descriptions) as untrusted input that may carry hidden instructions, and never let it trigger tools without checks. Require human approval for any write, and execute approved writes through the ERP's own API, not direct SQL. Log the user, question, generated query, rows returned and answer, retain logs per policy, and review them regularly. ## Sections ### The threat model for an LLM on ERP data **Body:** 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 **Body:** 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. **Code:** -- Read-only role limited to approved views (SQL Server example) CREATE LOGIN llm_reader WITH PASSWORD = ''; 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Is it safe to connect ChatGPT directly to our ERP? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms secure LLM access ERP, ChatGPT ERP data security, LLM ERP read-only access, prompt injection ERP, private LLM ERP, on-prem LLM ERP data, AI agent ERP permissions, LLM row level security, ERP AI governance, text to SQL ERP security --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json