When we first wrote a blog about the security of Odoo years ago, a large part of the attention went to hosting. Where is my database? How are the servers secured? Are there backups? How are passwords stored?
All valid questions.
But if you ask me now what I worry most about regarding the security of Odoo, the data center is not at the top of my list.
I am more concerned about the employee who gets administrator rights because otherwise they can't do something occasionally. About company data that is thoughtlessly pasted into a public AI tool. About an AI agent that gets direct access to Odoo and can independently modify data. And about custom code that is generated in a few minutes with AI and then ends up on a production database without a proper review.
Or something shorter:
Make everyone an administrator and you will never have questions that they can't do something.
It works. It's just that as a security strategy, it's a bit weaker.
Is Odoo itself secure?
Let's first answer the basic question: yes, Odoo has a quite mature security architecture.
When using Odoo Cloud, customer data is stored per customer in a separate database. Data is encrypted during transport and also stored data and files are encrypted. Odoo also makes multiple generations of backups and replicates them across different data centers.
For user accounts, two-factor authentication, secure HTTPS connections, and options to limit repeated login attempts are available. Two-factor authentication can also be enforced centrally for employees or for all users.
That does not mean that Odoo is invulnerable. No software is. But the technical foundation is not the part I would look at first if a company asks me how to make its Odoo environment more secure.
The more interesting conversation starts after that.
I worry less about the data center.
Companies sometimes pay a lot of attention to the physical location of their ERP system. I understand that. Your administration, customer data, sales information, inventory, employee data, and perhaps even production data are all in the same system.
You want to handle that carefully.
But when you use Odoo Cloud, infrastructure security, encryption, backups, and disaster recovery are matters that Odoo is professionally engaged with every day. Odoo keeps different generations of full backups and distributes them across multiple data centers.
Therefore, I would not say that the infrastructure is unimportant. On the contrary. However, the risk there is often better managed than the risk within your own organization.
Because then a user logs in who can access everything.
En dát heb je zelf ingericht.
Make everyone an administrator and you are free from the hassle.
Permissions are one of the most powerful security mechanisms within Odoo and at the same time one of the easiest to misconfigure.
Odoo has extensive capabilities to record which users are allowed to read, create, modify, and delete certain data. With groups, roles, access rights, and record rules, you can quite precisely determine who can access which information. Rights from different groups can be summed up.
The latter makes good rights management important.
In practice, however, a different pattern quickly emerges.
An employee cannot do something. Something needs to happen quickly. Someone grants broader rights. Problem solved.
A month later, the same thing happens elsewhere.
After a few years, you have an organization full of users who are allowed to do much more than necessary for their role.
That is convenient until something goes wrong.
The starting point should actually be the opposite: give someone exactly the rights needed to do their job. No more.
That principle is often called least privilege. A sales employee, for example, does not automatically need to be able to view all financial data. Someone who maintains customer data does not necessarily need to be able to modify user rights. And someone who creates reports may need to read data, but not delete it.
This requires a bit more thought during implementation. After that, it actually saves problems.
Security does not stop after implementation.
A common mistake is that user rights are set up during implementation and then remain unchanged for years.
But organizations change.
People get different roles. Teams are merged. An employee temporarily takes over tasks from a colleague. Someone gets additional rights for a project. New Odoo apps are being adopted.
The temporary exception of today often becomes the permanent setup of tomorrow.
Therefore, users and rights should be reviewed periodically.
Who still has access to Odoo? Which employees have administrator rights? Who can export sensitive information? Which external users still exist? Which accounts are hardly used anymore?
Odoo also records information about the devices users are logged in with and offers the ability to revoke access from devices.
In my opinion, two-factor authentication should be the rule rather than the exception for business software with sensitive data.
A good password is nice. A good password plus a second factor is better.
And then AI came.
Here, the security issue will become more interesting in the coming years.
AI not only changes how we search for information or write texts. AI is gaining more and more access to business information and business processes.
This creates two very different risks.
On one hand, data goes from Odoo to AI.
On the other hand, AI comes into Odoo.
Both require policy.
What happens when employees input Odoo data into an AI tool?
An employee wants to quickly analyze something and copies an export with customer data to an AI tool.
Or a contract.
A list of outstanding items.
A personnel document.
An email exchange with a customer.
Technisch is dat heel eenvoudig. Juist dát maakt het een risico.
Op het moment dat persoonsgegevens of vertrouwelijke bedrijfsinformatie naar een externe AI-dienst wordt gestuurd, moet je weten wat die leverancier met de gegevens doet, waar die worden verwerkt, welke afspraken er gelden en of het gebruik past binnen je privacybeleid en de AVG.
“It was just for ChatGPT” is not a category under the GDPR.
You don't have to ban AI. That would be unrealistic in my opinion. You just need to make agreements.
Which AI tools may employees use? Which data may be processed in them? Which data absolutely not? Are business accounts used or personal accounts? What contractual agreements are there with the supplier?
These are now common components of information security.
It becomes even more interesting when AI gains access to Odoo.
The next step is already underway.
AI is not only used to analyze information but also gains access to company systems to perform tasks independently.
Odoo is also developing in that direction. AI agents can be set up within Odoo with specific instructions, information sources, and tools to perform tasks.
This offers enormous possibilities.
An agent can, for example, collect information, process data, or perform recurring actions. But as soon as an AI agent can read or modify data, you need to ask the same security questions as with a human user.
Perhaps even stricter.
Which customers may the agent see?
May he read financial information?
May he create a quote?
May he also send that quote?
Can he modify records?
Can he delete data?
And what happens if the agent draws a wrong conclusion?
An agent who is only allowed to read information from a controlled dataset has a different risk profile than an agent who has full read, write, and delete rights to your ERP database via an API.
That sounds obvious. Still, I expect many mistakes will be made here in the coming years.
AI makes automation so easy that we run the risk of granting access first and only later thinking about the consequences.
Treat an AI agent like a user
My starting point would be simple: treat an AI agent as if it were an employee.
Give it its own identity and only access to what is necessary.
Odoo also advises using separate users for long-term automated API access. This allows for minimal rights to be granted and actions to be better traceable to that specific technical user.
An AI agent that only needs sales information does not need to access accounting, personnel information, and settings.
And if an agent performs actions that can have significant consequences, you can build in human oversight.
Let AI draft a proposal. But should an AI agent independently send a proposal of €250,000?
Let an agent check data. But should it be able to independently delete thousands of records?
Being technically capable is different from being wisely structured.
The same principle applies to AI as to users: as few rights as possible, as many as necessary.
And then we still have AI-generated code.
There is another development that I am at least as concerned about.
Developing software has become much more accessible due to AI.
Je beschrijft wat je wilt, een AI-tool genereert Python, XML en misschien zelfs een complete Odoo-app. Even installeren en klaar.
Or not.
Nowadays, you can quickly create your own Odoo app and then completely ruin your entire database.
That may sound exaggerated, but the underlying concern is serious.
Code does not have to be visibly wrong to be unsafe.
An app may seem to work fine while containing incorrect access rights. A method may be accessible via an external call while there is insufficient control over it. Code can bypass security rules. A function can modify data that the user should not have access to at all.
Odoo explicitly warns developers about this kind of security issues in custom code. Among other things, public methods, access rights, and mishandling the ORM can cause security problems.
AI does not change that.
On the contrary, AI increases the risk that code is used by someone who does not fully understand what the code actually does.
The AI tool gives you a convincing answer within thirty seconds. That does not mean you have a secure business application within thirty seconds.
AI code is still just code.
Daarom hanteren wij voor AI-gegenereerde code exact hetzelfde uitgangspunt als voor code die door een ontwikkelaar wordt geschreven.
The code must be reviewed.
It must be under version control.
It must be tested.
And you test it first in a controlled environment before it goes to production.
For security-sensitive components, you explicitly look at access rights, record rules, external access, API calls, use of elevated privileges, and the consequences of errors.
AI can greatly accelerate a developer. I am absolutely in favor of that.
But AI does not replace the responsibility of the developer.
That also relates to why we are critical of unknown apps from the Odoo App Store. When you add code to a system that is central to your business, you want to know who created that code, what it does, and who maintains it.
Whether that code is written by a human or by AI does not change much.
Odoo Studio requires the same discipline
For smaller adjustments, Odoo itself offers options via Studio. It also applies here: just because something is easily adjustable does not mean that every adjustment is automatically wise.
Creating an extra field is something different than significantly changing processes, automations, and data models.
We have previously written extensively about that in why Odoo Studio is not the holy grail.
The common denominator is always the same.
The threshold to change something technical is getting lower. That is positive as long as knowledge and control do not disappear at the same time.
A backup does not solve every security problem
Backups are important. Very important even.
When a faulty import, bad code, or a wrong automated action damages large amounts of data, you want to be able to recover.
But a backup is the last safety net.
It is not a security policy.
When someone has exported and taken confidential data, restoring a backup does not help.
When personal data has been sent to the wrong external service, you cannot retrieve it by restoring yesterday's database.
And when an account has had too much access for months, even with a good backup, you still do not automatically know what has happened to it.
Security therefore consists of three components in my opinion: preventing something from going wrong, being able to see when something goes wrong, and being able to recover if it does happen.
All three are necessary.
Good Odoo management starts with three topics.
When we look at the security of Odoo in an organization, I would explicitly include three areas nowadays.
The first is users and rights.
Define roles based on functions and processes. Do not give everyone broad rights for convenience. Limit administrator rights and periodically check who has access. Activate two-factor authentication where appropriate.
The second is AI and data.
Make clear agreements about which AI services may be used and what information may be processed in them. Once AI has direct access to Odoo, treat that integration or agent as a user. With its own identity, limited rights, and human approval where necessary.
The third is customization and code.
Whether the code is written by an experienced developer, comes from an external app, or is generated by AI: assess it before it gains access to your main business database.
This aligns with our broader approach to a Odoo implementation. We try not to add as much technology as possible, but rather to determine in a controlled manner what is needed, who is responsible for what, and how you test changes before users become dependent on them.
So, how safe is Odoo?
Odoo technically has many security measures that you would expect from modern business software.
However, that does not complete the question.
You can still use a well-secured platform quite unsafely.
Give every user administrator rights and the access security means little more. Let employees randomly send business data to AI services and you lose control over where information ends up. Give an AI agent unlimited access and a wrong action can suddenly be executed on a massive scale. Install custom code generated without review and you simply do not know enough about what you are adding to your database.
That is why I worry less these days about which data center Odoo is in.
I would rather know who can access the data, what rights that person has, which AI systems are watching, and which software we give access to the database.
That is where an increasingly larger part of your actual security risk lies.
And the good news is: you can do quite a lot about that yourself.
