Skip to Content

MCP server security: connect AI to your ERP, but not just any way

Published flaws, what the specification says, and the six safeguards I apply to my own ERP.
November 10, 2026 by
MCP server security: connect AI to your ERP, but not just any way

On 15 April 2026, OX Security described a "by design" flaw in the way local MCP servers are launched; on 16 May, the Cloud Security Alliance published a white paper on the attack surface of AI agents. Should you give up on connecting an agent to your ERP? No: MCP server security depends less on the protocol than on how you plug it in. Minimal rights, read-only by default, dry runs, backups, an action log and human approval of every write: that is what I practise every day with my own ERP.

Key points

  • MCP (Model Context Protocol) has become the standard socket between AI agents and business software. Since December 2025 it has been governed by a Linux Foundation project, and Odoo 20 offers it as a way to connect to the database.
  • The flaws published in 2025 and 2026 break no encryption: they exploit the trust placed in an installed server, in a tool description or in an over-privileged account.
  • The specification itself says so: a human should always be able to deny a tool call, and tool usage should be logged.
  • An agent never has more rights than the account it connects with. That is where everything is decided.
  • Six safeguards are enough to make the connection reasonable for an SME, and none of them requires expensive tooling.

What is happening: MCP takes hold, researchers probe its limits

Anthropic introduced the Model Context Protocol on 25 November 2024 as "a new standard for connecting AI assistants to the systems where data lives". The idea: a small program, the MCP server, exposes "tools" to the AI (find an invoice, create a contact, read a database) that it can call on its own. On 9 December 2025, the protocol was handed to the Agentic AI Foundation, set up within the Linux Foundation with Anthropic, OpenAI and Block; the announcement counted more than 10,000 published MCP servers at the time. Software vendors are following: the Odoo 20 release notes, published in September 2026, announce connecting to the database "via MCP". The current version of the specification is dated 28 July 2026.

Security researchers have kept pace. Three episodes sum up the risks.

A fake connector that copied emails

In September 2025, an npm package called "postmark-mcp", posing as the connector for the Postmark email service, added a line in version 1.0.16 that blind-copied every email to an external server. On 25 September 2025, Postmark confirmed it had nothing to do with the package, which had earned its users' trust over fifteen versions. Nobody hacked the AI: it was handed a booby-trapped tool, and it used it as intended.

A "by design" flaw in local launching

On 15 April 2026, OX Security published research on the STDIO transport, the one that launches an MCP server as a program on your machine from a configuration file. If uncontrolled input reaches that configuration, it can run any command. OX puts the exposure at more than 150 million downloads and up to 200,000 instances. According to OX, Anthropic declined to change the protocol's architecture, calling the behaviour "expected": it is up to the developer to control what gets launched.

The confused deputy and tool poisoning

On 16 May 2026, the Cloud Security Alliance published a white paper on three families of risk: tool poisoning (instructions hidden in a tool description, which the AI reads and follows), the "confused deputy" (a server acting with broader rights than the user actually intended) and the supply chain (public packages and registries). The document, which the CSA itself presents as AI-assisted rapid research not yet validated by its official processes, recommends four controls: approve and version tool definitions, limit the rights of each call, enforce a policy at the moment the tool is called, and log every call.

What it means for you: MCP server security is decided at installation

For an SME owner, the lesson is not "MCP is dangerous". It is that connecting an agent to your ERP amounts to signing a power of attorney. The agent reads what its account can read and changes what its account can change. If it receives a booby-trapped instruction, hidden in an email, a PDF invoice or a tool description, it will carry it out with those same rights.

The MCP specification states this in plain words. It asks that there "always" be a human able to deny a tool call, that applications ask for confirmation on sensitive operations and log tool usage, and that descriptions supplied by a server be treated as untrusted unless that server is trusted. The protocol cannot enforce these rules: it is up to whoever installs it to apply them.

Three questions tell you where you stand. Which account does the agent connect with? Can it write without anyone approving? Will you be able to say tomorrow what it did today?

What I have learned

I have been running my ERP in natural language since my move to Odoo Community, told in Odoo Community vs Enterprise: my migration: an MCP server connects Odoo to Claude, I ask, the AI does the work, I check. I have also written an MCP server for the SiYuan note-taking tool, published as open source (SiYuan MCP Server). Writing it showed me an MCP server from the inside: a program that turns the AI's requests into calls to the software, with exactly the rights it is given. Mine writes directly into SiYuan's database files, because the official API did not allow it. It is useful, and it shows clearly that a server does what its access allows, not just what its description promises.

The most complete framework is the one around my bookkeeping, described in AI bookkeeping in practice. The agent drafts a plan, runs it first as a dry run (everything is computed, then rolled back), I review it, then it runs for real after an automatic database backup. Import checks refuse to write at the slightest discrepancy, and no expense without a receipt is booked without my approval.

I learned that rule the hard way. During the migration, a first sync test with my personal calendar deleted four events. A test on an external system is still a write. Since then, nothing is written there without explicit approval.

What to do in practice

1. Give the agent its own account, with minimal rights

Create a dedicated technical user, limited to the apps and companies the agent needs, with no administrator rights. Never the owner's account or the administrator's: if a booby-trapped instruction gets through, that scope is what limits the damage.

2. Start read-only

For the first few weeks, the agent searches, summarises, matches and proposes, but does not write. You open up write access afterwards, one app at a time, once you know what you expect from it.

3. Require a dry run before every write

Every change first goes through a simulation that shows what would be created or modified, and is then rolled back. If the tool cannot simulate, the agent at least presents the exact list of planned writes.

4. Back up before writing

A database backup, with a tested restore, before any batch of writes. That is what turns a mistake into a mere setback.

5. Keep an action log

Every tool call should leave a trace: who, when, what, and with what result. A dedicated account already helps, since all its changes carry its name in the ERP's history.

6. Keep a human to approve writes

The agent prepares, a person approves. Only install MCP servers from a verified source, the vendor's own or code you have reviewed, and treat any incoming document as a possible source of booby-trapped instructions.

Frequently asked questions

Is it safe to connect an AI agent to my ERP through MCP?

Yes, if you treat it like a new team member given a power of attorney: an account in its name, limited rights, approved writes and a log. The published incidents exploit over-privileged accounts or servers installed without checks.

Is the MCP server provided by my software vendor safer?

It removes the risk of a fake connector, which matters. But it still acts with the rights of the account you give it: the safeguards remain your responsibility.

Do I need to host the AI myself to be safe?

Not necessarily. The model can be an external service if the data it sees is acceptable to you and if rights, approval and logging stay on your side. The real question is what the agent can do, more than where it does its thinking.

Going further

I set up AI agents connected to Odoo and to your business tools, with these safeguards from day one: see business applications and the infrastructure behind them. To discuss your case, book a 20-minute call.

Sources

Tags: MCP server security, Model Context Protocol, AI agents, ERP, Odoo, cybersecurity, SME

Swiss Data Protection Act and AI: the law already applies, AI rules are coming in 2027
What Swiss law already requires when you use AI, what the Federal Council is preparing, and six steps to comply without waiting.