Yes, if the AI connects through your ERP’s own permission system rather than around it. The real question isn’t “can an AI be trusted with my data” — it’s “what does the AI inherit, and what happens if it’s tricked.” With Cledoo MCP, the AI inherits exactly the access rights of the Odoo user who connected it, nothing more. The residual risk is prompt injection, and it’s bounded, not eliminated, by those same access rights.
What does “the AI has access to my ERP” actually mean?
It depends entirely on the architecture, and there are two fundamentally different models:
- Export model. Your Odoo data is synced or copied to an external AI platform — a vector database, a third-party connector, a middleware service. The AI queries that copy. Now you have two places your data lives, two places it can leak from, and a sync process that’s usually out of your control.
- Direct-access model. The AI connects straight to your live Odoo through a protocol — MCP — and every read or write goes through Odoo’s own permission checks, in real time, on the actual database. No copy exists.
Cledoo MCP is the second model. The AI reaches your Odoo through the /mcp
endpoint the module exposes, and from there it’s just another Odoo client —
subject to the same rules as the browser tab you have open right now.
Can the AI see or do more than the connected user could?
No. This is the core guarantee, and it’s worth being precise about why it holds. Odoo’s access control is layered, and none of the layers are MCP-specific — they’re the same ones that have governed every Odoo client (web, mobile, API) for years, as documented in Odoo’s own developer reference:
- Access rights (
ir.model.access) decide, per model, whether a user’s groups can create, read, update, or delete at all. - Record rules (
ir.rule) filter which records — a salesperson sees their own opportunities, not the whole pipeline, if that’s how the rule is configured. - Field-level security hides or blocks specific fields — a salary field a given group shouldn’t see stays invisible, whoever’s asking.
When the AI calls a Cledoo MCP tool, that call executes as the connected user through Odoo’s ORM — the same code path a manual click would take. There is no privileged service account, no bypass. If the user can’t see the HR salary field in the UI, the AI can’t retrieve it either. If the user can’t delete invoices, the AI’s delete call is rejected by the same rule that would reject the user’s own attempt. This is why the honest framing is “bounded by the user’s rights,” not “the AI has been taught to behave” — behavior isn’t the enforcement mechanism, Odoo’s permission system is.
Does any data leave the Odoo instance?
No, and this is where the direct-access model earns its keep. There’s no external server holding a copy of your records, no data broker sitting between Odoo and the AI, no sync job with its own retention and access policy to audit. The AI’s context — what it can read in a given conversation — comes from live tool calls against your instance and disappears with the session. What you’re auditing is one thing: your Odoo, and who logged in as what.
That doesn’t mean nothing is exposed to the AI provider — whatever data the AI reads to answer a question is, by definition, sent to that AI’s model for processing, same as pasting a screenshot into a chat. What it means is there’s no additional copy sitting in a second system with its own breach surface.
What can actually go wrong — honestly
The permission model closes off “the AI exceeds the user’s rights.” It does not close off a different class of risk that OWASP’s Gen AI Security Project ranks as the top risk facing LLM applications in its 2025 Top 10 list: prompt injection. Per OWASP, a prompt injection vulnerability occurs when “user prompts alter the LLM’s behavior or output in unintended ways,” and it comes in two forms — direct (a user deliberately crafts a manipulative prompt) and indirect (the AI reads content from an external source — a document, an email, a web page — that contains hidden instructions it then follows).
Applied to Odoo: imagine a customer email, ingested as a support ticket, that contains text designed to make the AI take an unintended action next time someone asks it to summarize tickets. This is real, it’s the OWASP-ranked #1 risk category for LLM applications, and no vendor should tell you otherwise.
Here’s what actually limits the damage: the injected instruction still executes as the connected user, inside their existing access rights. A prompt injection aimed at an AI connected as a read-only sales rep cannot make that AI delete an invoice or read the payroll table — the record rules and access rights described above apply regardless of why the AI is making the call, only who it’s making it as. The blast radius of a successful injection is capped at what that user could already do by hand. That’s a real mitigation, not a complete one — a user with broad write access who’s tricked by injected content can still cause real damage within their own rights.
MCP’s own specification documentation is candid about this class of problem too, dedicating detailed sections to session hijacking, token passthrough, and scope minimization — the common thread is: least privilege first, monitoring second, because no single control eliminates the risk on its own.
What if I need tighter control than “the user’s normal rights”?
Some data is sensitive enough that you don’t want it in an AI’s context even though the connected user is technically allowed to see it, and some actions are consequential enough that you want a human to confirm before an AI executes them, whatever the user’s rights allow. That’s a legitimate need, and it’s a different layer than what’s described here — the base module gives you accurate, ACL-bounded access; Cledoo MCP Pro adds governance below those rights (masking, deny policies, confirmed writes, full audit trail). We cover that layer in a separate article; the point to take from this one is that it’s additive, not a replacement for the ACL boundary — Pro narrows what the base module already correctly bounds.
The takeaway
An AI connected to Odoo through MCP is not a new, unbounded actor in your system — it’s the connected user, acting through the same access rights that already govern them, with no copy of your data sitting anywhere else. The honest remaining risk is prompt injection, which is real and worth taking seriously, but its blast radius is capped by exactly the same permission system. If you need it capped further — narrower than the user’s own rights — that’s what governance controls are for, not a reason to distrust the base architecture.