Giving AI Agents Access to Business Systems Safely

MCP, the Model Context Protocol, is the standard plug that lets an AI assistant read from and act inside your ERP, hotel system, or database. Connecting it safely comes down to four rules: start read-only, keep every tool narrow, make a human approve anything that writes, and log every call. The protocol helps, but those controls live in your server, not in the spec.

What is MCP, in plain terms?

Think of a restaurant menu. The kitchen decides what can be ordered; the waiter can only order what is on the menu. An MCP server is the menu for one of your systems. It publishes a list of tools (actions such as "check room availability" or "create a draft invoice") with a description and the inputs each one accepts. The AI agent reads the menu and orders from it.

Anthropic introduced MCP in November 2024. It has since become the common way to plug AI assistants and coding agents into other software, so most vendors pitching "AI for your ERP" in 2026 are talking about an MCP server whether they say so or not. The current revision is the 2026-07-28 specification. Two of its changes matter for anyone running one:

• Stateless core. The opening handshake and the session header are gone; every request stands on its own. Anything a tool needs to remember between calls now travels as an explicit ID, and the spec's security guidance says plainly that possessing such an ID must never count as being logged in.
• Readable headers. HTTP requests must now carry Mcp-Method and Mcp-Name, so a gateway or firewall in front of your server can see which tool is being called and block or rate-limit it without parsing the body.

The menu analogy also shows where the risk sits. Whoever writes the menu decides what the agent can do. If the menu has an item called "run any SQL you like", that is what you have handed over.

Why is connecting an AI agent riskier than a normal integration?

A normal integration calls your system the same way every time; a developer wrote each call. An agent decides at run time which tool to call and with what inputs, based on text it has read. That text includes the tool descriptions themselves, and those can be poisoned.

The spec knows this. Its tools chapter says there "SHOULD always be a human in the loop with the ability to deny tool invocations", and that clients must treat tool annotations (labels such as "read-only" or "destructive") as untrusted unless the server itself is trusted. Note the word should: a recommendation, not a requirement every client meets.

Three kinds of failure have already happened outside the lab:

Microsoft's incident response team summed up the shift in a 30 June 2026 post: "A prompt injection against an agent can trigger an action." A summariser that reads a bad email writes a bad summary. An agent connected to your PMS (the property management system that holds a hotel's reservations) that reads a bad email might change a booking. I covered the inbox side of this in prompt injection for messaging agents; this article is about the other end, the systems the agent can touch.

Step 1: Start read-only, and enforce it in the database

The first version of any MCP server for an internal system should only read. Availability, stock levels, open invoices, maintenance history: there is plenty of value in an agent that can answer "which rooms are free on the 20th and what did we charge last weekend?" without anyone opening three screens.

"Read-only" has to be true in the system, not just in the tool's description. A label saying the tool only reads is a hint the model may or may not respect, and the spec itself says not to trust such labels blindly. In practice:

• Give the MCP server its own database user with SELECT permission only, ideally on a few views (saved, pre-filtered queries) built for the purpose rather than on raw tables.
• Leave out columns the agent has no reason to see: guest ID numbers, card fragments, staff salaries. A view without them cannot leak them.
• Cap result sizes. A "list reservations" tool that can return 50,000 rows is an export tool with a friendlier name.

If someone poisons the tool description or the prompt, the worst outcome is the agent reading something it was already allowed to read. That is a far smaller incident than an edited reservation.

Step 2: Build narrow tools, not a "run anything" tool

The fastest way to connect an agent is a single generic tool: execute_sql, or call_api(endpoint, body). It is also the most dangerous, because the menu now contains every action your system supports.

Narrow tools trade a little development time for a much smaller blast radius (the amount of damage one mistake can cause). For a hotel PMS:

Notice the third row. Letting the model choose the recipient is how data walks out the door. When the recipient, the account, or the amount can be derived from a record, derive it on the server and do not accept it as input.

Tool names, inputs, and descriptions are a contract with every agent that uses them. Rename a tool or change what an input means and agents start calling it wrongly, exactly as a partner integration breaks when an API changes without notice. Version them the way you would any integration contract.

Step 3: Use each person's permissions, not one master key

A common shortcut is to give the MCP server one powerful service account and let everyone's agent use it. The result: a front-desk clerk's assistant can see the finance reports, because the server can.

Tie every call to the person behind it. The agent acting for the front desk should see what the front desk sees in the PMS today, no more. The MCP spec supports this directly. A server may return a different tool list depending on the caller's authorization, so the night auditor's agent can be offered tools the housekeeping supervisor's agent never sees.

Two rules from the spec's security guidance are worth giving to any vendor building this for you:

• No token passthrough. "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server." A server that takes whatever login token the client sends and forwards it to your ERP makes it impossible to tell later who did what.
• Start with the smallest permissions. Begin with a basic read scope (a scope is a named set of permissions inside a login token) and ask for more only when a privileged tool is first used. Broad scopes such as admin:* turn one stolen token into access to everything.

Step 4: Require approval before anything writes

Once the read-only version has earned trust, add writing, but route every write through a person. The safest pattern is for write tools to create a draft rather than change the record: a pending rate change, a draft purchase order, a proposed reply. A human then approves it in the application they already use.

Why approve in the PMS and not in a chat pop-up? Because the agent cannot fake a click in your own application. The 2026-07-28 spec does let a tool pause mid-call and ask the user for input, which is useful for confirmations, but that request still passes through the AI client. An approval recorded in your system, under the approver's own login, is evidence you can audit later.

Not every action needs the same gate. A simple tiering works:

The last row matters most. Some actions should simply not be on the menu.

Step 5: Log every call and keep an off switch

The spec requires servers to validate inputs, enforce access control, rate-limit calls, and sanitise outputs; clients are advised to log tool usage for audit. Do not leave the logging to the client. Your server should record, for every call: who the user was, which tool, the inputs, how many records came back, and the approval ID if there was one.

Two operational habits pay off quickly:

• Per-tool rate limits, a cap on how often each tool may be called. Because Mcp-Name now travels in a header, a gateway can allow 200 availability lookups an hour but only 10 rate-change requests, without touching the server code.
• A switch that disables one tool without a redeploy. When something looks wrong at 2 a.m., the night manager should be able to turn off request_rate_change while the read tools keep working.

Review the log weekly at first. Agents call tools in patterns nobody predicted, and the log is where you find the tool that needs narrowing.

What to check before installing someone else's MCP server

Many teams will not write their own server; they will install one from a vendor or a public registry. That makes it a supply-chain decision, the same as adding a software library. Microsoft's 30 June guidance recommends an allowlist of approved publishers and switching off any "allow all" setting. Before installing:

1. Verify the publisher. Is it the vendor's official package, or a lookalike name like postmark-mcp?
2. Pin the version and read the tool descriptions on every update. A server can ship clean descriptions today and altered ones next month.
3. Run it in a container, an isolated box with only the credentials it needs, not on a laptop that also holds cloud keys and SSH access.
4. Do not auto-load server configs that arrive inside a project folder or repository. Review them like code.
5. Check what it can reach. A server that only needs your PMS should not be able to open connections to the internet.

A sensible first project

Pick one department and one question it asks every day. For a hotel, that is often the front desk asking about availability and rates; for a distributor, sales asking about stock and outstanding invoices. Build two or three read-only tools for it, connect them with that department's permissions, and run it for a few weeks while reading the logs.

Only then add a single write tool that creates drafts, with approval in the existing system. This is slower than connecting everything on day one. It is also how you find out what the agent actually does before it can do damage, which is the same discipline I recommend for agentic tool loops in general.

If you are weighing an "AI for your ERP" proposal, or want to connect an agent to your own systems without handing it a master key, I can help you design the boundaries before anything goes live.