Odoo 19 · read from the source
Does Odoo’s native AI have an audit trail and permissions?
Short answer: yes, and that part is close to table stakes now. Odoo 19 ships a real AI agent, its permissions run at the acting user’s level, and logging what an agent did is something a number of tools handle well. The distinction that actually decides whether any of it can be trusted sits one level underneath.
An audit trail logs what your AI said it did. It does not tell you what your database actually contains.
A log keeps the agent’s own report of a write. Verification is the separate step of re-reading the record from the database afterward and confirming what is actually there. Only the second catches a write that reports success while landing on the wrong record. Here is the precise picture, generous to what Odoo built, and the bar an audit trail has to clear to be evidence.
Written by nanti.ai. The Odoo quotes below are verbatim from Odoo’s own documentation; the rest are findings we read in the Odoo 19 Enterprise source. We build the Execution Layer for Odoo, which exists to clear the bar this page describes, so read us knowing that. Corrections welcome at hello@nanti.ai.
First, be fair
Odoo built a real agent.
This is not a chatbot with an ERP logo on it. We read the Odoo 19 Enterprise source: the native AI runs a real tool-calling agent loop, up to twenty rounds of up to twenty parallel calls, with retrieval and unattended cron execution. That is generous engineering, and it is exactly why the rest of this page matters. The question is not whether Odoo’s AI is capable. It is what the AI keeps as a record, and what stands between it and your ledger.
- 20rounds per turn
- 20parallel calls per round
- Retrievalgrounded in your data
- Cronruns unattended
“The standard Ask AI agent cannot make changes to the database. As such, it can open views and display reports, but it cannot create leads or alter data.” Odoo documentation
That is the safe, well-fenced part, and it is a good default. Everything below is about the moment an agent is given a tool that can write.
Permissions
Control lives in each tool’s Python.
Odoo’s AI acts with the acting user’s permissions, which is real and worth using. But there is no standing, per-agent allow-list of the specific operations an agent may run. Odoo’s own documentation is candid about where enforcement actually sits.
“The server action does not enforce business rules, modify records directly, or guarantee the correctness of the operation. Its role is limited to decision-making.”
The tools that write “contain all execution logic and perform record updates, moves, or writes” and “must enforce business rules explicitly in Python code.”
Odoo documentationSo the guardrail is whatever the tool author wrote, not a policy the agent cannot cross. And we read something sharper in the Odoo 19 source: when a permission error is raised, it is caught, converted to text, and returned to the model as a tool result. A denial arrives as advice the model may route around, rather than a wall it hits.
Enforcement that a prompt cannot skip has to live on the server side of the write, deciding before the action runs, not in the sentence handed back afterward.
The distinction
Logging is not verifying.
Give an AI agent a well-built log and it will faithfully record every action: which operation, on whose behalf, with what inputs, and what the tool returned. That is worth having, and it is increasingly common. But read the last part again. What the tool returned is the tool’s own report. If a write lands on the wrong record, or a success sentence is composed from what the action intended, the way Odoo’s native AI does when a server action returns nothing, a faithful log records that false success perfectly. The log is honest. It is honest about a claim, not about the database.
“The AI agent updated the customer’s payment terms.”
- The operation, the user, the inputs, the tool’s returned result
- A faithful record of what the agent claimed
- No independent read of the row after the write
- If the write missed the record, the claim is logged all the same
Payment terms: 30 days → 45 days, read back from the row
- The record re-read from the database after commit
- Compared field by field against what the caller intended
- The values on both sides, not a sentence about them
- A claim that does not match the database becomes a failure, not a log line
This is not a knock on any capable agent, Odoo’s included. A log is designed to record what happened as reported; verification is the separate job of confirming it against the row. Both matter. But only verification catches the write that reported success and did not land, and that gap stays invisible until the day you need to prove what an agent actually changed.
Plain answers
Asked, answered.
Does Odoo 19’s native AI keep an audit trail of what it does?
It keeps a record, but not one built to be evidence. First, be fair: Odoo 19 ships a real AI agent, a genuine tool-calling loop, and it is capable. When that agent acts through a server action, the trace it leaves is a chatter message on the record. We read the Odoo 19 Enterprise source, and a chatter message records what the agent attempted rather than the before-and-after state of the row, and it can be edited or deleted like any other message. So you can see that something was tried; you cannot reliably reconstruct what actually changed, or prove it was not altered afterward. An audit trail meant to stand as evidence keeps the values on both sides of every write, reads them back from the database, and is tamper-evident.
What is the difference between an audit trail and verification for an AI writing to Odoo?
An audit trail logs what your AI said it did. It does not tell you what your database actually contains. A log records each action an agent took and what the tool reported back, which is worth having and something a number of tools now do well. But the tool’s report is a claim: if a write lands on the wrong record, or a success sentence is composed from what the action intended, a faithful log records that false success exactly as written. Verification is the separate step of re-reading the record from the database on an independent connection after the write commits, and comparing it field by field against what the caller intended. Logging tells you what the agent claimed; verification tells you what is actually in the ledger. Only the second catches the write that reported success but did not land.
Can you control what Odoo’s AI agent is allowed to do?
Yes, at the level of the acting user’s Odoo permissions, which is real control and worth using. What Odoo’s own documentation is candid about is where enforcement lives: a server action, in Odoo’s words, "does not enforce business rules, modify records directly, or guarantee the correctness of the operation. Its role is limited to decision-making." The tools that actually write "must enforce business rules explicitly in Python code." So the guardrail is whatever the tool author wrote, not a standing per-agent policy. And we found in the source that when a permission error is raised, it is caught, converted to text, and handed back to the model as a tool result, so a denial arrives as advice the model may try to route around, rather than a wall.
Why can an action Odoo’s AI was denied still leave changes behind?
Two reasons we read in the Odoo 19 source. First, there is no savepoint in the AI module’s tool execution, so if step three of a five-step action is denied, steps one and two remain written. Second, when a server action returns nothing, Odoo composes a success sentence from what the action intended and hands that to the model, so the agent can report success without the database being re-read. The fix is structural, not a better prompt: run the write in a transaction that rolls back as a whole, then read the record back from the database before anyone calls it done.
What does an audit trail need to do to count as evidence?
Four things. Keep the before-and-after values, not just the event. Read the record back from the database on an independent connection after commit and compare it, field by field, against what was intended. Commit a refusal on its own transaction so the record of a denial survives the rollback of the action it denied. And be tamper-evident: make alteration visible with a hash chain, while being honest that a database superuser who disables the trigger can still alter rows. That last honesty is the tell. Tamper-evident is defensible; tamper-proof is a claim no ERP add-on can keep.
Is Odoo’s native AI safe to let write to your ERP?
For reading, displaying reports, and drafting, it is genuinely useful today, and Odoo’s standard Ask AI agent, in Odoo’s own words, "cannot make changes to the database... it can open views and display reports, but it cannot create leads or alter data," so the low-risk path is well fenced. The care is needed the moment an agent can write. There the questions are whether a failed multi-step write rolls back cleanly, whether success is confirmed by re-reading the database, and whether the record of what happened can be trusted afterward. We work those through in detail on can AI write to Odoo safely (nanti.ai/can-ai-write-to-odoo-safely).
The proof layer
Odoo built the agent. We built the proof.
Odoo’s native AI is a capable agent, and it will keep improving. The gap this page describes, writes you can prove and a record you can trust, is a different job, and it is the one the Execution Layer for Odoo is built for: every AI write read back from the database, verified, and recorded before and after. See also can AI write to Odoo safely, how to verify what an AI agent actually wrote, and why your AI gets Odoo revenue wrong.
Evaluating an AI tool that writes to your Odoo?
Name it. We read its public docs and your description and tell you, in writing within five working days, whether it checks the proposal before it writes, logs the result, or re-reads the committed row after. Sourced line by line, using the same pre-registered method as our public write-verification census. Free, no pitch, and we tell you the truth even if the tool is not ours.
Get the Write-CheckOur own write-verification, the Execution Layer for Odoo, is available now. The verdict stays honest either way.
Not ready to talk? Follow what we ship.
An email when something real ships. No newsletters, no spam.
Living this problem every day and want to shape what comes next? We work closely with a small number of Odoo teams on the Execution Layer for Odoo, the ones who need more than a log of what the AI said it did. Tell us about your Odoo setup.
