Give the model a tool, not the ERP login

An operations head wants to ask, in plain words, which orders are stuck. The answer is in the ERP. The model cannot see it. The quick fix is to give the model an ERP account and let it run queries.

The model reads text it cannot trust

A model acts on whatever text it is given. A customer email, a pasted note or a clever question can ask it to read another customer's orders. If the model holds a login that sees everything, its own judgement is the only thing between that text and the data.

Scope it in the tool, not in the prompt

An MCP server sits between the model and the ERP. Each tool does one job, and the server decides what that job can reach. The model chooses which tool to call. It does not choose whose data the tool reads.

How TripGlide does it

TripGlide's assistant answers questions about one group trip. The server function checks the trip id and fixes it for the whole request, so the get_trip_data tool cannot be given a different one. The read runs with the member's own login. Email and contact details are dropped unless the member is the trip's owner or an admin. The OpenAI key stays on the server and never reaches the phone.

On an ERP, the same rule means the customer or the warehouse comes from the person's login, not from the chat. Reading an order can be a tool. Cancelling an order or issuing a credit note waits for a person to approve it.

Test it on a copy first

Point the MCP server at a test copy of the ERP before the live one. Ask it the questions your team will ask, and the ones an attacker would. Check that no tool can reach a record outside the person's scope. Only then connect it to production. Your ERP stays where it is.

The full TripGlide assistant, with its weather tool and its last turn, is in The assistant can only see this trip.

We build MCP servers on the systems a business already runs. See our AI automation work.

To add one person to your team instead, hire an ERP developer who knows your data.