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, read

Scope: model mail.activity
Operations: query, read, create

Scope: model sale.order
Operations: query, read, write
Condition: amount_total < 5000

An agent stacks several rules. Anything covered by no rule is refused.

Scopes

You designate either a functional group or an explicit list of models.

Group	Covers
`crm`	Leads and opportunities
`ventes`	Quotations and orders
`facturation`	Invoices, credit notes, payments
`achats`	Purchase orders
`stock`	Moves, transfers, inventory
`support`	Tickets
`rh`	Employees, time off, expenses
`communication`	Messages, activities, channels

Each group also 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.

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.

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

These are not set case by case: they protect every agent at all times.

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.

Automatic pause. After N consecutive failures, or beyond a write threshold per run, the agent pauses and notifies you rather than pressing on.

Global kill switch. One button pauses every agent in the workspace at once. Useful during an Odoo migration or an incident.

Soft credit block. When the pool runs dry, runs are queued, not lost. They resume once credits return.

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.

A setup method that works

Start read-only

First week: 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.

Keep the write cap tight

Five writes per run suits most missions. 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