When we started pitching our AI Bot to enterprise clients, the first question was always the same: what happens if it modifies our data? It's areasonable concern. You have a production Odoo instance running your entire business - sales, inventory, accounting, HR. Giving an AI tool access to that system sounds risky. So we designed the architecture to make it physically impossible for the bot to write, update, or delete anything.
The foundation is simple: the bot connects to Odoo via XML-RPC using a dedicated service account that has strictly read-only permissions. This isn'ta software toggle we can accidentally flip. The Odoo user assigned to the bot has custom access rights at the model level - read access to the models the client approves, zero write/create/unlink permissions on anything. Even if our code had a bug that attempted a write operation, Odoo's own access control layer would reject it with an AccessError.
We went further than just Odoo permissions. The bot's integration layer has no write methods implemented at all. The XML-RPC client we built only exposes search_read, fields_get, and read operations. There's noexecute_kw call for create, write, or unlink anywhere in the codebase. This is defense in depth - even if someone compromised our application layer, the tooling to modify data simply doesn'texist in the deployed code.
Credential storage was another critical decision. Every client's Odoo connection details - URL, database name, API key - are encrypted at rest using AES-256-GCM. The encryption keys are stored separately from the encrypted data, following the envelope encryption pattern. We use a unique initialization vector for every encryption operation, which means even identical credentials for two clients produce completely different ciphertext.
The API keys themselves deserve attention. We use Odoo's built-in API key system rather than storing passwords. API keys can be revoked instantly by the client from their Odoo admin panel without involving us at all. If a client wants to cut off bot access, they delete the API key and it stops working immediately. No ticket, no waiting, no dependency on us.
Data in transit is protected by TLS 1.3 for all connections between our bot server and client Odoo instances. We enforce certificate validation - no skipping SSL checks even for development. The bot server itself runs on an isolated Hetzner VPS with a minimal attack surface: no unnecessary ports open, SSH key-only authentication, automatic security updates.
One question we get from IT teams is whether client data is used to train AI models. The answer is no, and the architecture enforces this. When a user asks the bot a question, we query the client's Odoo for the relevant data, format it into a prompt, send it to Claude's API, and return the response. We don'tstore query results beyond the conversation session. We don'tbatch data for training. Claude's API terms explicitly state that API inputs and outputs aren'tused for model training.
The conversation history itself is stored in our database with the same AES-256-GCM encryption used for credentials. Conversations are tied to individual Telegram users and automatically pruned after 30 days. A client can request immediate deletion of all their conversation data, and we can execute that within minutes.
Odoo's record rules add another layer of protection that most people overlook. Even with read access, record rules can restrict which records the bot user can see. A client can configure their Odoo so the bot only sees records from specific companies in a multi-company setup, or only approved/published products, or only certain employee categories. The bot inherits all of these restrictions automatically because it operates as a regular Odoo user.
We also implemented rate limiting at multiple levels. The bot limits queries per user per minute to prevent abuse. It limits total queries per client organization per hour to prevent runaway costs. And it has a global rate limit to protect our infrastructure. If any limit is hit, the bot responds with a polite message and the user can try again shortly.
For clients in regulated industries, we provide a detailed security questionnaire response and can arrange for their security team to audit our codebase. We'vedone this three times so far, and each audit confirmed that the read-only architecture is genuine, not just marketing. One auditor specifically noted that the absence of write methods in the codebase was unusual - most systems implement write methods and then try to block them at the permission level, which is inherently less secure.
The practical result of all this is that our bot has processed over 10,000 queries across client Odoo instances with zero data incidents. No accidental writes, no data leaks, no unauthorized access. The read-only architecture isn'tjust a security feature - it'sthe product's core design principle that makes enterprise adoption possible.