Integrating an LLM with an ERP system without exposing all of its data comes down to designing narrow, purpose-built tools instead of a single broad connector. Rather than giving the model a generic query interface over the entire ERP database, define individual tools for specific business questions, such as checking a single order's status or looking up a product's stock level, each returning only the fields that task actually needs rather than a full table or record dump. Backing these tools with read-only database views or filtered API endpoints, instead of direct table access, allows field-level masking for sensitive data like pricing or personal information before it ever reaches the model's context. Access should also be scoped to the requesting user's own ERP role, so someone in customer service cannot pull financial data meant only for finance, mirroring the access controls the ERP already enforces for human users. This tool-by-tool, least-privilege approach takes more upfront design work than a single passthrough API but dramatically reduces what a prompt injection or a misused query could expose. Nanobase AI designs ERP integrations this way by default rather than granting broad data access for convenience.
Classify before you build a single tool
Data minimization starts before any tool code is written, with a classification pass over the ERP fields a proposed assistant might touch. A simple four-tier classification, public, internal, restricted and regulated, applied to each field or table in scope, makes the later masking and scoping decisions mechanical rather than argued case by case during implementation. Skipping this step tends to produce tools built around whatever fields were easiest to query rather than what a specific business question actually required, which is how over-exposure creeps in.
A technique catalog mapped to what each one stops
| Technique | What it does | Risk it mitigates |
|---|---|---|
| View-based scoping | Expose a database view with only needed columns, not the raw table | Accidental exposure of unrelated sensitive fields in the same table |
| Field-level masking | Redact or partially hide values like pricing or personal data at the source | A tool bug or overly broad query still can't surface the raw value |
| Tokenization / pseudonymization | Replace identifying values with reversible tokens before reaching the model | Personal data appearing in model context, logs or provider telemetry |
| Response allow-listing | Define exactly which fields a tool's output may include, reject anything else | A backend change accidentally adding a new sensitive field to a response |
| Row limits and pagination caps | Cap how many records a single call can return | Bulk exfiltration through a single broad query |
| Ephemeral context handling | Don't persist ERP data in chat history or logs beyond the session's need | Data lingering in storage longer than the business purpose requires |
Response allow-listing is the technique most often skipped, since it is easy to assume a query already scoped to the right view is safe, when a later change to that view or an upstream join can silently widen what a tool returns.
Why role-based scoping still needs these techniques underneath it
Scoping access to the requesting user's own ERP role is necessary but not sufficient on its own. A user's role might legitimately include access to a wide report used once a quarter, and if a tool exposes that entire report to a casual conversational query, the assistant surfaces far more than the specific question needed even though the access is technically authorized. The techniques above narrow what gets returned per question, on top of the broader role-based boundary of what could be returned in principle, and both layers matter independently.
Sequencing the minimization work
- Classify fields and tables in scope using a simple sensitivity tier before designing any tool.
- Build tools against views scoped to the specific business question, not the underlying table.
- Apply field masking or tokenization at the database or middleware layer for anything in the restricted or regulated tier.
- Define an explicit response schema per tool and reject or strip any field not on that list before it reaches the model.
- Set row limits appropriate to the question, a single order lookup needs one row, not a full customer history dump.
- Review logging and session storage to confirm ERP data doesn't persist longer than the interaction requires.
Frequently asked questions
Does tokenization break the assistant's ability to answer follow-up questions?
Not if implemented consistently, since a token can be de-tokenized back to the real value only at the point of final display to an authorized user, while the model itself reasons over the token, meaning follow-up questions referencing the same entity still work correctly.
How is this different from just using role-based access control?
Role-based access control governs what a user, and by extension the assistant acting for them, could reach in principle. These techniques additionally shape what specifically comes back from any single tool call, which matters because a single authorized query can still return more than the specific question needed without this extra layer.
Is this level of care necessary for a small pilot with a handful of users?
Yes, arguably more so, since pilots often get less security review than a full rollout while still touching real production data; building these habits into the pilot phase is considerably cheaper than retrofitting them after the assistant has already scaled to more users and tools.
How Nanobase AI helps
Nanobase AI designs ERP integrations around this full technique catalog by default, combining view scoping, field masking and response allow-listing rather than relying on role-based access alone for convenience. GDPR and KVKK data minimization requirements this approach supports are covered in eu-ai-act-gdpr-kvkk-compliant-llm-checklist, and SAP-specific rollout phasing is covered in integrate-llm-with-sap.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.