Odoo MCP security: a practical threat model

An Odoo MCP server turns Odoo models and methods into tools an AI model can call. Security therefore comes down to four questions: which Odoo user the server acts as, which tools it exposes, whether a human confirms changes, and whether every call is logged. The MCP security best practices cover the protocol layer; this page covers the Odoo layer.

What can go wrong?

Prompt injection: why it matters more for an ERP

Language models cannot reliably tell the user's instructions apart from instructions hidden in data. Odoo stores a lot of text written by outsiders: incoming e-mails, website form submissions, helpdesk tickets, supplier product names. When a tool returns that text to the model, it becomes part of the prompt.

There is no complete technical fix today. The practical defence is to make sure that an injected instruction cannot do much on its own:

• the Odoo user behind the server has only the rights the task needs;
• every create, update or state change shows the exact record and values to a person, who confirms it;
• tools that change money or stock, such as posting a journal entry or validating a delivery, are not exposed at all, or only as draft actions;
• the same AI session does not also hold a tool that can send data outside, such as an e-mail or web request tool, unless you trust that combination.

Least privilege: start with the Odoo user

The most important control is not in the MCP server. It is the Odoo user whose API key the server uses.

Write actions: confirmation, drafts and undo

Reading data is useful on its own. Writing is where the leverage is, and where mistakes cost money. A defensible write design has five properties:

1. Allow-list, not deny-list. The server exposes named actions on named models, for example "create draft quotation" or "add a note to a lead", not a generic write on any model.
2. Preview, then confirm. The tool first returns what it will do, with record names and field values. The change runs only after explicit confirmation by the person.
3. Draft first. New quotations, bills and orders stay in draft state. Confirming or posting remains a human step in Odoo.
4. Undo. The server stores the previous values of every changed field, so a person can revert an action without restoring a backup.
5. No delete. unlink is not exposed. Archiving, where needed, is a separate confirmed action.

MCP has a hint for this: tools can declare annotations such as readOnlyHint and destructiveHint, and clients may ask the user before calling tools that are not read-only. The specification itself says clients must treat annotations as untrusted unless they come from trusted servers, and clients differ in how they display them. The server should therefore enforce confirmation for writes on its own side.

Audit log: what to record

Odoo's chatter shows changes to tracked fields. It does not show what the model read, which tool it called or which prompt led to it. An MCP server should log, for every call:

• timestamp, Odoo database, Odoo user and AI client;
• tool name and parameters;
• result status, number of records returned or changed;
• for writes: record IDs, old and new values, and who confirmed it.

Keep the log outside the AI session, so the model cannot alter it, and decide who reviews it and how often.

Authentication between the AI client and the server

Remote MCP servers use HTTP. The MCP specification (current version 2026-07-28) defines optional authorization based on OAuth 2.1, which lets an assistant such as Claude or ChatGPT connect after the user signs in, without pasting tokens into config files. Two rules from the spec are worth checking in any server:

• tokens must be issued for that MCP server and validated by it;
• the server must not accept or pass on tokens that were issued for something else (the "token passthrough" anti-pattern in the best practices).

For local servers started over stdio, the spec says credentials come from the environment, so the Odoo API key usually sits in an environment variable on the user's computer. That is acceptable for a developer, less so for a whole team.

Multi-company and data residency

In a multi-company Odoo database, set the allowed companies on the MCP user explicitly. Do not rely on the AI model to filter by company.

Data residency involves three parties: your Odoo hosting, the MCP server and the model provider. A hosted MCP server in the EU keeps the tool traffic and audit log in the EU, but tool results still go to the model provider you use. Check that provider's data processing terms and regional options separately. Our hosted pilot runs on a server in the EU.

Security checklist

• [ ] The server connects with a dedicated, non-admin Odoo user per person or role
• [ ] API keys have an expiry and a named owner
• [ ] Read-only by default; writes enabled per model, never delete
• [ ] Every write shows a preview and needs confirmation
• [ ] Changes can be undone from stored previous values
• [ ] Every tool call is logged outside the AI session
• [ ] Multi-company access is restricted on the Odoo user
• [ ] You know where the MCP server and the model provider process data

How a hosted pilot implements these controls is described on the home page. For connection steps, see the setup guide.