Rules and permissions
The rule engine that bounds every agent: functional groups, operations, value conditions, learning mode, human approval, automatic guardrails and additional permissions.
11 min readUpdated October 1, 2026
An agent works unsupervised. What bounds it is therefore not your vigilance, but a rule engine that checks every call before it reaches Odoo.
Security never rests on the prompt
Rules are not instructions given to the AI. They are enforced by the server, on every call, regardless of what the agent believes it may do. A malicious instruction hidden inside an Odoo record therefore cannot bypass them.
How a rule is built
A rule pairs a scope with operations, plus optional conditions.
Scope: group "invoicing"
Operations: query, readScope: model mail.activity
Operations: query, read, createScope: model sale.order
Operations: query, read, write
Condition: amount_total < 5000An agent stacks several rules. Anything covered by no rule is refused.
Scopes
You designate either a functional group or an explicit list of models. To find a model's technical name (sale.order, crm.lead…), see the list of Odoo models.
| Group | Covers |
|---|---|
crm | Leads and opportunities |
ventes | Quotations, orders and their lines |
facturation | Invoices, credit notes, payments |
achats | Purchase orders and their lines |
stock | Transfers and stock moves |
support | Tickets and project tasks |
rh | Time off |
communication | Messages and activities |
Each group also covers scheduled activities (mail.activity), and carries the read-only models it depends on: granting writes on orders gives read access to customers and products, without ever allowing changes to them. Likewise, the rh group gives read access to employees and departments, the stock group to on-hand quantities and locations.
For a narrow-scoped agent, prefer an explicit list of models: longer to set up, and markedly safer.
Operations
| Operation | What it allows |
|---|---|
query | Searching for records |
read | Reading known records |
report | Computing aggregates |
print | Generating a PDF |
create | Creating |
write | Updating |
workflow | Triggering an Odoo business action |
execute | Calling an Odoo method |
Deletion does not exist
delete is absent from this list, and not by oversight: no agent can delete a record, whatever its configuration. To take a record out of circulation, an agent must archive it through write.
Value conditions
This is the setting that turns a broad permission into a safe one.
A condition applies to a field and is checked before the write. Aidoo re-reads the record concerned and verifies the condition against its real state, not against what the agent claims.
| Condition | Effect |
|---|---|
amount_total < 5000 | The agent stays away from large deals |
state != posted | It never touches a posted invoice |
user_id = <a salesperson> | It stays within one person's portfolio |
When in doubt, the call is refused
If Aidoo cannot verify a condition, because it could not re-read the record for instance, the call is blocked. The engine always fails on the side of refusal.
Learning mode
This is the default for a new agent, so you do not have to guess its rules before seeing it work. During a 48-hour window:
| What the agent does | What happens |
|---|---|
| Read any model | Allowed, within what its Odoo account can see |
| Write on a model covered by a starting rule | Executed, as outside learning |
| Write on a model no rule covers | Put on hold until you approve it (see below) |
| Delete | Still impossible |
Every access actually made is observed: model, operation, number of calls. Autonomous runs and conversations alike (in Aidoo or in the Odoo bubble) feed the learning. An approved write counts as an observed access; a rejected one does not.
When frozen, automatically at the end of the 48 hours or by you with the Freeze permissions now button, the observed accesses are merged into the rules: models sharing the same operations are grouped, and a fully covered functional group becomes a group rule. Starting rules are kept as they are. You review the result and correct it if needed; unticking the box from the agent's page shows you those rules before they are saved.
What learning does not guess
Value conditions ("draft invoices only", "amount below 5,000") still have to be written by hand. Learning observes models and operations, not thresholds. After freezing, re-read the write rules and add the conditions they call for.
Once frozen, an agent does not go back to learning on its own. If its rules turn out too narrow, add them by hand, or click Restart learning on its page (workspace owner or admin): a new 48-hour window opens, the current rules become starting rules and the observed accesses start again from zero.
Human approval
Some operations do not go out right away: they wait for a human to approve them. Three cases:
- the Human approval for writes option is ticked (it is off by default): every Odoo creation, update or action by the agent is submitted;
- the agent is in learning mode and wants to write on a model no rule covers;
- the agent prepares an email in "Review before sending" mode (see below).
Each submitted operation is shown with its detail (model, fields, recipients) in Aidoo and in the Odoo bubble, with Approve and Reject buttons. Without a decision, it expires after 7 days.
The agent pauses while it waits. It submits together the operations prepared in a single reply, then stops, instead of carrying on as if they were done. Its report ends by stating that an operation is awaiting your approval and that the agent is paused. Once every submitted operation is decided, it resumes once with all the decisions, rejections included, and adapts what comes next.
| Situation | Resumption |
|---|---|
| Autonomous run | A new "Decision received" run starts with all the decisions |
| Conversation | The agent picks the conversation back up as soon as nothing is pending |
While an operation submitted by a run is pending, the following scheduled runs are skipped, consuming nothing. Runs fired by an event, a date or by hand still go ahead, aware of the operations already pending so as not to submit them again.
Workflows-only mode
The most restrictive setting: the agent cannot call any Odoo tool directly, only run saved workflows you have approved.
It then acts strictly within sequences you wrote and validated. You lose in flexibility what you gain in predictability. It is the right setting for an agent that touches accounting.
Automatic guardrails
They protect every agent at all times; only the per-run limits are set agent by agent.
Odoo health check before any AI call. If your Odoo is unreachable, the run stops immediately, before a single token is spent. After several attempts, the agent pauses.
Per-run limits. They are set agent by agent in Limits & safety:
| Limit | Default value |
|---|---|
| Max credits / run | 100 credits (also the minimum), up to 1,000 |
| Max duration | 300 seconds, up to 4,500 |
| Max actions / run | Empty, meaning unlimited |
| Max writes / run | Empty, meaning unlimited |
A write counts one call, not one record: updating 50 tickets in a single grouped call counts as one.
Loop detection. The same call repeated with exactly the same parameters, with no write in between, is refused on the third occurrence; on the fourth, the run stops rather than burn its budget.
Automatic pause. After 3 consecutive failures (adjustable from 1 to 20), or if a run exceeds the write cap you have set, the agent pauses and notifies you rather than pressing on.
Global kill switch. The Pause all agents button suspends every agent in the workspace at once. Useful during an Odoo migration or an incident.
Stop on demand. A run in progress, real or simulated, stops with the Stop button of the "Run in progress" bubble, in the agent's thread. In a conversation, the send button turns into a Stop button while the agent works. The current tool call finishes, then nothing else goes out; the partial reply is kept.
Credit block. When the pool, or the agent's monthly budget, runs dry, no run goes out and nothing is billed. The agent resumes its rhythm as soon as credits come back.
Tamper-proof log. Every step is written as the run proceeds and cannot be edited afterwards. Sensitive parameters are redacted.
Tools outside Odoo
An agent can also act outside Odoo: post to Slack, send an email, write to Notion. Two sources, at most five applications per agent.
The app bank. More than 1,000 services connectable in a few clicks from the Integrations page, with authentication handled for you.
Your own MCP servers. If you already expose internal tools over MCP, declare them with their authentication (static header or OAuth). Secrets are encrypted per workspace.
The full detail of connecting, the catalogue and the permission settings lives in Integrations and external tools.
Narrow the tool list
For each application, enable only the two or three tools that are genuinely useful. Without that restriction, the application's whole catalogue is loaded on every conversation turn, inflating credit consumption for no benefit.
Writing to an external service is governed by a separate switch: by default, an agent only reads. And content coming back from a third-party service is treated as untrusted, exactly like Odoo data.
Web access
Two optional tools, reserved for agents and never exposed to Claude or ChatGPT: a web search and a page reader. Off by default.
Useful for an agent that must check a public fact, for instance whether a company exists before qualifying a lead. Results are truncated so the token budget does not explode, and internal addresses are blocked.
Other permissions
On top of the Odoo rules, the agent's Permissions section carries dedicated switches, all off by default:
| Permission | What it opens |
|---|---|
| Suggest emails | The agent prepares emails tied to an Odoo record (up to 20 at once), with up to 5 attachments already stored in Odoo if needed. In Review before sending mode (the default), nothing goes out without your click. In Automatic sending mode, they leave immediately under the agent's Odoo identity, within Max automatic emails / run (10 by default, up to 100). |
| Document reading | The agent reads PDFs, images (scans included) and Word files attached to records, up to 30 pages and 20 MB. 1 credit per 20 pages, once per document. |
| Can ask a human a question | In autonomous runs only, the agent asks a question (with up to 4 choices) and stops; it resumes as soon as the answer comes in, from Aidoo, the Odoo bubble or an email link. Unanswered after 7 days, the question expires. |
| Collaborating agents | Set from the agent's page: it can consult up to 5 other agents in the workspace or delegate a task to them. The agent called upon works under its own identity, with its own rules and budget, and cannot call on another one in turn. |
| Aidoo Drive | The agent reads and writes files (Markdown, Excel, Word, CSV) in the workspace Drive: its private folder, the shared folder read-only, and the folders you add. A deletion, or overwriting a file uploaded by a human, goes through approval. |
These permissions never widen access to Odoo: documents and attachments are read under the agent's Odoo identity, its read rules included.
A setup method that works
Let learning do the first sorting
During the 48 hours, put the agent to work on real cases. Its reads are free, its writes outside the rules go through you and it waits for your decision before carrying on. When frozen, re-read the resulting rules and remove what was touched out of curiosity rather than need.
Stay read-only if the agent analyses
For an agent that produces reports, only query, read and report. The agent produces its analyses, you confirm it aims correctly.
Add the least risky write
Usually create on mail.activity: the agent schedules follow-ups without changing anything that already exists.
Open updates, with conditions
write on one precise model, bounded by a value condition. Never write on a whole group with no condition.
Set a tight write cap
The Max writes / run field is empty (unlimited) by default. For a new agent, set it to five: that suits most missions, and going over it pauses the agent. Raise it only when a legitimate case exceeds it.
Next step
- Credits and consumption: what each run costs
- Best practices and troubleshooting: diagnosing a stuck agent