Connecting an AI assistant to a production system used to mean a bespoke integration per assistant and per system. That has changed, and the change is worth understanding before the security conversation, because most of the anxiety in that conversation is about architecture, not about models.
What MCP changed
The Model Context Protocol was published by Anthropic in November 2024 and has since been adopted well beyond it. It addresses a combinatorial problem: each pairing of an assistant with a system it might read from is a separate integration.
MCP defines a common interface. A system exposes its capabilities once - resources that can be read, tools that can be called, prompts that can be reused - and any client speaking the protocol can use them. The client is the assistant; the server sits with the system being exposed.
For an operation running an ERP the practical consequence is mundane and large: asking a question of production data stops requiring a report to be built first. Which quantities of this part are reserved, which devices in this arrival are still awaiting triage, what the return rate on this model has been - these become questions, not tickets.
Permissions belong on the server, not in the prompt
The single most important architectural point is where access is decided. What the assistant can see and what it can change are set by the system exposing them, not by instructions given to the model.
This is the only arrangement where the answer to what can this thing touch does not depend on the model behaving well. A permission expressed as an instruction in a prompt is a request; a permission enforced by the server is a boundary. The distinction matters more as assistants get better at following instructions, not less, because a system whose safety rests on instruction-following has no floor.
In practice that means access is mapped to the profiles the ERP already has. A user who cannot see supplier pricing does not gain it by asking an assistant, and the assistant inherits the caller permissions instead of holding its own.
Read and write are separate decisions
Reading production data and acting on it are different risks and deserve different answers. Most of the value arrives with read access alone: questions answered, exports produced, analyses that previously required someone to build a report.
Write access is where a mistake stops being a wrong answer and becomes an operational event. The defensible pattern is to route write actions through human validation - the assistant prepares the change, a person confirms it - and to record the action in the audit trail like any other change, with the fact that it originated from an assistant visible in the record.
It is worth deciding this deliberately instead of inheriting it. An integration that is read-only by design is a much smaller conversation with a security team than one that is read-write with conventions around it.
Grounding, and why answers need sources
Connecting to a system is one half. The other is where answers about procedures come from. Retrieval-augmented generation answers a question by first retrieving relevant passages from your own documents, then generating from those passages rather than from model memory.
Quality is decided by retrieval far more than by the model. If the right passage is not retrieved, no model can produce a correct answer from what it was given. And if the corpus contains three versions of a procedure, the system will faithfully answer from the wrong one - which makes document control part of the system, not a prerequisite someone else handles.
The honest test on a shop floor is whether an answer carries its source. A technician needs to know which procedure, which revision, and whether it applies to the model in front of them. An unsourced answer is not usable at a bench, however fluent it is.
Four questions to settle before connecting anything
Where is the data processed, and under what terms? Cloud, self-hosted or local are different answers, and the one that fits depends on your clients contractual requirements more than on your own preference.
Is your data used to train a model? This is a contractual question with a yes or no answer, and it should be answered in writing, not inferred.
What can the assistant change, and does a human confirm it? If the answer is that it can change anything and nobody confirms, the integration is not ready regardless of how well it performs.
Is assistant activity in the audit trail? An action taken through an assistant is still an action. If it is not recorded with the same completeness as one taken through the interface, the trail has a hole in it exactly where questions will eventually be asked.