Access control answers “can the AI see this record?” Governance answers “what happens after it does?” Odoo’s permission system (ACLs, record rules, field rights) already bounds what an AI connected via MCP can reach — that’s the baseline, covered in our piece on whether AI access to Odoo is safe. This article is about the layer above it: once the AI can see a customer’s invoice history, is every read logged, are sensitive fields hidden anyway, and can it act on what it sees without asking?
Why isn’t “the user could see it anyway” a sufficient answer?
Because a human browsing Odoo and an AI querying Odoo behave nothing alike. A salesperson opens ten records a day, remembers roughly none of it, and never touches fields outside the form they’re looking at. An AI agent can enumerate thousands of records in seconds, correlate fields across models the UI never juxtaposes, and — if you’ve wired it up that way — draft an email based on what it found. Same permissions, completely different risk profile.
This is precisely the distinction GDPR’s data minimisation principle draws: personal data must be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed” (Article 5(1)©). Having read access to a field because your Odoo role includes it is not the same as it being necessary for the AI to process that field for the task at hand. Access control answers who’s allowed in the room. Governance answers what they’re allowed to do once they’re there, and whether anyone can prove it afterwards.
What does “control” actually consist of, beyond ACLs?
Four concrete mechanisms, each closing a gap that ACLs leave open by design:
- Audit trail. Every read and write the AI performs, logged and exportable — not just “user X had access” but “the AI queried this record, at this time, and returned these fields.”
- Data privacy masking. Sensitive fields (national ID numbers, bank details, health data) hidden from the AI even when the underlying Odoo user could technically see them — including in exported results, not just on-screen.
- Per-user policies below ACLs. Odoo’s ACLs say what a role can touch. A policy layer says what the AI is allowed to touch for that role — narrower, and testable before you switch it on.
- Human-confirmed writes and an outbound guard. Risky changes (deleting a record, adjusting a price, sending an email) wait for a human nod instead of executing autonomously.
None of these exist in Odoo’s native ACL system, because ACLs were never designed to answer “did an autonomous agent do this, and can I see it did.” They were designed for humans clicking through a UI.
Why does an audit trail matter more for an AI than for a person?
Because when something goes wrong, “who did this and why” is the first question — and with an AI in the loop, the honest answer is often “we don’t know, it doesn’t remember.” GDPR’s Article 32 requires “appropriate technical and organisational measures to ensure a level of security appropriate to the risk,” including the ability to restore access after an incident and to test and evaluate the effectiveness of your safeguards on an ongoing basis. You can’t evaluate what you don’t log.
The EU AI Act takes this further for high-risk systems, mandating “automatic recording of events (logs) over the lifetime of the system” so operators can identify when the system caused a risk and support post-market monitoring (Article 12). An ERP-connected AI agent is not automatically “high-risk” under that regulation’s categories, but the underlying logic transfers directly: if an autonomous system can touch customer records, pricing, or financial data, you want a record of what it touched — before a regulator, an auditor, or a customer asks.
Cledoo MCP Pro logs every AI-initiated read and write in a full, exportable audit trail: what was queried, what was changed, by which agent session, when. That’s the difference between “we trust the AI acted correctly” and “we can show what it did.”
Why mask fields the AI’s user could already see?
Because visibility inside an Odoo form and exposure inside an AI’s context window are not the same risk. A field a support agent glances at once, in context, surrounded by a dozen other fields on screen, is not equivalent to that same field being pulled into an AI’s response, potentially summarized, potentially quoted back in a draft email, potentially cached somewhere in a conversation log. The data hasn’t moved, but its exposure surface has multiplied.
This is what “data protection by design and by default” (GDPR Article 25) is meant to force: technical measures that ensure “by default, only personal data which are necessary for each specific purpose of the processing are processed” (Article 25(2)) — not “personal data that happened to be reachable.” Masking is that principle applied to an AI connector: national ID numbers, IBANs, health notes stay hidden from the AI’s queries and from anything it exports, regardless of the underlying Odoo user’s raw permissions. It’s least privilege applied a second time, for a different actor with a different risk profile.
Why do you need a policy layer below ACLs instead of just tightening ACLs?
Because tightening ACLs for the AI also tightens them for the human, and that’s usually not what you want. Your accountant needs full access to the account.move model to do their job. You may not want the AI acting on that same model with the same breadth — reading every historical invoice to answer one question is fine; letting it silently reconcile entries is not.
A policy layer that sits between the user’s ACLs and what the AI is actually allowed to do lets you say: this role’s human can do X, Y, Z — the AI, on their behalf, can only do X. Cledoo MCP Pro’s per-user policies do exactly this, with a dry-run simulator so you can see what a policy would have blocked before you turn it on — no surprises the first time a real query hits it.
What happens when the AI wants to act, not just read?
That’s where the largest gap between “access” and “control” opens up. Reading a record and misreporting it is a bad answer. Writing to a record, or sending an email on your company’s behalf, is a bad action — and actions are much harder to undo than answers.
Two mechanisms close this gap in Cledoo MCP Pro:
- Human-confirmed writes. Changes flagged as risky (deleting, bulk-updating, altering financial fields) pause and wait for explicit approval instead of executing immediately.
- Outbound guard. The AI cannot send emails, messages, or other outbound communication on its own initiative — a human authorizes what goes out, and to whom.
This is containment, not obstruction: read-heavy, low-risk use stays fast and frictionless; the handful of actions that are hard to reverse get a checkpoint.
The takeaway
Access answers can. Governance answers did, and can you prove it, and did anyone check first. Odoo’s ACLs, inherited by Cledoo MCP Classic, give you the first part for free — the AI is bounded by whatever the connected user could already do. Cledoo MCP Pro (€189, one-time, no subscription) adds the second part: an exportable audit trail, data privacy masking beyond raw ACLs, per-user policies with a dry-run simulator, human-confirmed writes, an outbound guard, and usage analytics to watch how the AI actually behaves over time. Access without control is a demo. Access with control is something you can put in front of an auditor.