Readonly is not a security wall

An Odoo Server Action form includes a Readonly Tool checkbox for a tool that the team considers not to write or modify existing data. Odoo says the checkbox advises the client that the tool can be invoked without explicit user approval.

The limitation is precise: Odoo also says that enabling Readonly Tool does not hide the tool from the AI client and does not act as a security rule that forces the tool to be read-only. Odoo, AI MCP server

A team should therefore not use the checkbox in place of code review or permission review. If a tool affects data or a business process, test it with the account that will actually be used, inspect the database result, and decide where the client must ask for approval. A client being allowed to invoke a tool automatically does not mean Odoo approves every agent action, or that the action is safe in every context.

A practical example before production use

The following is a hypothetical example. It does not describe Enersys’s current database configuration.

Suppose a warehouse team wants an AI agent to answer questions about available and reserved stock. The team could start with a dedicated Odoo user whose permissions cover only the relevant models and companies. It would expose the tools needed to find and read that data, then test that the agent sees the intended warehouse quantities but not purchase prices or another company’s records.

If the team later wants the agent to create or edit a sales order, that should be a separate decision. The team needs to define who can approve it, which customers are in scope, which fields cannot change, and how the created records will be reviewed. Exposing a create or edit tool does not follow from selecting Readonly, and using an administrator’s API key simply because it is convenient is a poor starting point.

The evidence from testing should be more than a screenshot showing a successful connection. Keep the prompts that could read data, the requests that were rejected, the data that was returned, the result of each create or edit, and the owner responsible when a result differs from the expected outcome.

A least-privilege rollout checklist

1. Define the work before exposing a tool. State whether the agent will read, search, open a view, create, or edit something. Do not begin with the available tool list and then look for a use.
2. Create a dedicated MCP user. Give the account only the permissions the work needs. Keep it separate from an administrator account and review company, warehouse, model, and field access.
3. Give every exposed tool an owner. Record who approved it, why it is exposed, and how it will be disabled if the work ends or testing fails.
4. Separate read from write. Begin with read tasks. Record creation or edits need their own test cases and accountable owner. Do not treat Readonly as an access-control mechanism.
5. Treat the API key as the user’s credential. Odoo says a key can have a validity duration and is shown to the user only once when generated. Store it through a controlled method, not in a shared chat or broadly accessible file. Odoo, AI MCP server
6. Test requests that should fail. Use the MCP account to search outside its scope, create a record without permission, edit a restricted field, and invoke a tool that has not been exposed. The result should reject the request or limit the data as designed.
7. Plan a stop and review path. Decide how to disable a tool, revoke or replace a key, inspect records created or changed, and review the setup after a role change, module change, or client upgrade.

MCP can make Odoo data easier to reach through natural language. The rollout should start with a concrete question: “Which data may the agent touch, through which tool, under whose permissions?” Once the team can answer that and has evidence from a test database, it can decide whether to expand from reading into writing.