Does Odoo's native AI have permissions and an audit trail?

We build Pinchy, a self-hosted governance layer for AI agents, and Odoo is the integration we get asked about most, so we are partisan here. We have tried to keep every claim on this page sourced and fair: where Odoo has a documented gap we say so, and where the community already has an answer (the OCA's own modules) we point to it.

Is Odoo's native AI available in Community Edition?

No. Creating and customizing AI agents in Odoo 19 requires the AI application, and that application sits in the Enterprise tier. The Odoo community has reported this directly: the forum thread "Community Edition v19 - AI Module missing" is exactly what it sounds like. AI Agents, AI fields in Studio, and AI-driven server actions are part of the licensed edition.

That matters because a large share of self-hosted Odoo runs on Community Edition. Those teams are not behind on AI. They are simply not served by the native feature, and an open, self-hosted AI layer that talks to Odoo through its standard API is the realistic path for them.

Can you control what an Odoo AI agent is allowed to do?

This is the part people most often assume is handled, so it is worth being precise. Odoo's AI-agents documentation describes how an agent is given Topics and Tools (for example "Create Leads", or a natural-language search that opens the right view), and it notes that an agent with no Topics "is only able to provide information, not complete tasks or make changes to the database." That is a real, sensible on/off boundary.

What the documentation does not describe is a fine-grained, per-agent permission model: no documented allow-list of which specific operations an agent may run, no documented read-versus-write separation per agent, and no statement that the agent operates under a constrained, agent-specific identity. In practice the agent acts within Odoo's general access-rights and record-rules system, scoped to whatever user it runs as. So the honest description is: the boundary is the user's permissions, not an agent's permissions. If that user can do something in the database, the path exists for the agent to do it too.

That is fine for low-stakes, read-only help. It is a different conversation once an agent can create, write, or confirm records, because an agent is not a person following a runbook. It is a probabilistic system that also reads untrusted input (documents, emails, chat messages), and a cleverly worded input can push it past the instructions in its prompt. A prompt is guidance; it is not a boundary. This is precisely the concern the Odoo community itself has flagged: the OCA discussion "HELP WANTED: Odoo LLM agents are here!" names security, access control, and audit as the unsolved part of running LLM agents against Odoo.

Does Odoo log what its AI agent did?

Not natively, and not specifically. Odoo does have partial change visibility: certain tracked fields on certain models post their changes into the record's chatter. But there is no built-in, system-wide audit log of create/read/write/delete operations. The gap is well known in the ecosystem because the OCA maintains a dedicated Audit Log module to provide it: you enable a rule per model, and it records CRUD operations. An optional scheduled action (off by default) can purge logs older than six months; until you enable it, logs are kept indefinitely. It is a fair, open-source way to get auditing in Odoo today.

Two things follow. First, auditing in Odoo is opt-in and per-model, so it only covers what you remembered to switch on. Second, and more to the point for AI: even with the OCA module logging database writes, you are logging the database row that changed, not the agent reasoning and tool call that caused it. "Sales order 4123 was confirmed" is in the row log; "the AI agent confirmed it because a customer chat message asked it to, on behalf of user X, at this time" is the thing you actually want when an entry looks wrong three weeks later. Agent governance needs an audit trail at the level of the agent's actions, not only the table's.

A fair side-by-side

These layers complement each other; this is not a scoreboard. The OCA module is a genuinely good answer to the logging half of the problem, and many Odoo teams should know it exists.

What "governed AI for Odoo" actually requires

Whatever tool you use, a setup you can let near live business data needs the same shape, and none of it is Odoo-specific:

• Scoped tools, not a raw API key. The agent never holds the broad credential. It calls narrow, named operations ("read this order", "create this expense"), each a defined tool. Anything not granted is unreachable because it does not exist as a tool.
• Default-deny, per agent. A new agent can touch nothing until you enable specific tools for it. A support agent that reads orders does not silently also get the tool that posts invoices.
• Read and write are different grants. Plenty of useful Odoo agents only ever need to read. Make "can look up" and "can change" separate decisions, because the risk is not the same.
• Human approval for the irreversible parts. For high-impact writes, the safe default is that the agent prepares the action and a person approves it before it lands. The receipt-photo-to-bookkeeping flow is the classic example: extract and stage the record, but a human signs off before it hits the books.
• An audit trail of the agent's calls. Which operation, on whose behalf, with what inputs, and what came back, captured per tool call and ideally tamper-evident, so a wrong entry is reconstructable rather than a guess.

How Pinchy does it

This section describes our own product. Pinchy reaches Odoo through its standard external API (JSON-RPC). Self-hosted Odoo exposes that API on every edition, Community included, so Pinchy works on self-hosted Community and Enterprise alike. On Odoo's own SaaS hosting (Odoo Online), the external API is part of the Custom plan, not the Standard or One App Free plans. Each Odoo capability is a scoped tool an admin grants per agent on an allow-list (default-deny); read and write are separate grants; high-impact actions like confirming an order or validating a picking are discrete, approval-gated tools rather than blanket write access; and every tool call is written to a tamper-evident, HMAC-signed audit trail. It is AGPL-licensed and runs on your own infrastructure. For Odoo admins, the free Pinchy Connector module on the Odoo App Store (versions 17, 18, and 19) wires the connection from inside Odoo's settings.

We are not claiming this is the only way. The OCA module above is a fair option for the logging half, and you can assemble governance yourself. We mention Pinchy because the gap this page describes is the precise thing it was built to close, and because it is open source, you can read exactly how it does it: github.com/heypinchy/pinchy.

The honest limit

Governance bounds the damage and makes it reviewable. It does not make the model correct. A draft-first write can still propose the wrong expense category; scoped permissions just guarantee a human sees it first and that the agent could never have touched payroll. Those are different problems, and pretending otherwise is how teams get burned. What you can fix today is the boundary: never give an Odoo agent a raw credential, give it narrow granted tools, require approval for the writes that matter, and log everything it does.