Governance layer · Runs inside your Odoo · OAuth 2.1
Giving an AI agent access to your ERP is an access-control decision, not an integration decision. The KSROlabs governance layer adds OAuth consent, per-user scopes, tool-family policies, model rules, data guards, session control, and a complete audit trail — enforced inside your own Odoo, where your data already lives.
Odoo MCP governance is the control layer that decides what an AI agent is allowed to do inside your ERP, and records everything it did. It covers how the agent authenticates (OAuth consent per user, not a shared API key), which tools it can call, which models and fields it can touch, what it is forbidden to write, how long its session lasts, and how you revoke it. The KSROlabs governance layer implements all of this as a native Odoo module, so policies are enforced by your own Odoo and the audit log is a table in your own database.
One API key pasted into five people’s AI clients means five people with identical access and no way to tell their actions apart. Rotating it breaks everyone at once. Revoking one person means revoking all of them.
Odoo access rights were designed for humans clicking through a UI at human speed. An AI agent can issue hundreds of writes a minute, chain operations a person never would, and act on a misread instruction. Record-level permission is necessary. It is not sufficient.
When a number changes, someone will ask which agent, which user, which prompt, which tool, which record, and when. If that answer lives in an application log or a third-party dashboard, it isn’t an audit trail.
Each control is configured in Odoo and applied on every MCP call, before the call reaches your data.
Each person connects their own Claude, Cursor, or MCP client through a one-time OAuth flow with a consent screen. No shared secrets, no copied keys, no static credentials in a config file.
Permissions are set by what the agent can do, not just what it can see. Tools group into families — read, analytics, export, write, bulk, administrative — and each family is granted or denied per client.
Per-model configuration for create, read, update, and delete, layered on top of Odoo’s own ACLs and record rules. The default is deny: an unconfigured model is invisible, not accidentally exposed.
Field-level allowlists and denylists, plus domain filters. An agent stays out of margin data, payment terms, salary fields, or personal data even when it is authorized on the model that contains them.
A live view of every connected client and session, with expiry and immediate revocation. A visible kill switch for when something is behaving unexpectedly — the control Odoo 20’s native MCP does not have.
Every authentication, tool call, denied permission, and rate-limit event recorded with the acting user, client, tool, model, payload, response, and timing. In your database. Exportable. Retained on your schedule.
Last verified: 7 August 2026. Odoo 20 is not yet generally available — the native MCP column is based on pre-release analysis, and we re-verify this table after each Odoo release.
| Capability | Odoo 20 native MCP | Hosted MCP relays | KSROlabs Governance |
|---|---|---|---|
| Authentication | MCP-scoped API key | Vendor-managed OAuth | OAuth 2.1 + PKCE, per user, in your Odoo |
| Per-user identity | No — key-based | Vendor account layer | Yes, native Odoo user |
| Consent screen | No | The vendor’s | Yours, in your Odoo |
| Tool-family policy | No | Varies | Yes |
| Per-model CRUD control | Read-only by default | Varies | Yes, default-deny |
| Field-level guards | No | Varies | Yes |
| Write confirmation gate | No — confirmation passed as true | Varies | Confirm against v1.0 |
| Rate limiting | No | Vendor-side | Yes, per key |
| Audit log | No — requests logged only | On vendor infrastructure | In your Odoo database |
| Kill switch | No | Vendor dashboard | Yes |
| Where your ERP data flows | Direct | Through vendor servers | Direct |
| Odoo editions | Enterprise 20 only | Varies | Community + Enterprise, 14–19 |
CTOs and ERP architects who have been asked to approve AI access to a system holding the general ledger.
Odoo partners rolling AI access out across a client base and needing a defensible, repeatable access model.
Compliance and security owners who need to answer “what can it do” and “what did it do” in writing.
Operations teams of 10–50 where every person wants their own AI connection and nobody wants to hand out the admin key.
Governing AI access to Odoo: permissions, audit, revocation, and where your data goes.
MCP governance is the access-control layer that decides what an AI agent is allowed to do inside your ERP, and records everything it did. It covers how the agent authenticates, which tools it may call, which models and fields it may touch, how long its session lasts, and how you revoke it. It is a control layer, not a feature of the MCP endpoint itself — an MCP endpoint answers requests, and governance decides which requests are allowed to be answered.
Odoo access rights control which records a user may reach, and they still apply. They do not control which operations an AI agent may perform, how fast it may perform them, or whether that activity is recorded in a way you can audit later. Odoo answers “which records”. Governance answers “which operations, how fast, by whom, and recorded how”. Both layers are needed once a non-human client is issuing the calls.
Odoo 20’s native MCP module authenticates with an MCP-scoped API key, ships five read-only tools, gates writes behind an explicit admin flag, and logs requests. It does not include OAuth, per-user consent, rate limiting, an audit log, or a kill switch. For read-only reporting and question-answering on Enterprise 20 it is a sound choice as shipped. Governance becomes relevant when you need writes with a record of them, per-person access, or an answer to a compliance question.
In your own Odoo database, as an Odoo table. It is never sent to a KSROlabs server. You query it with the same tools you use for any other Odoo data, export it on your own schedule, and apply your own retention policy to it.
Yes. Per-model rules cover create, read, update, and delete independently, and the default is deny. An agent can only delete records on a model where delete has been explicitly granted for that client. Bulk operations are a separate tool family, so an agent can hold write permission without holding bulk delete.
Yes. Each person authenticates through their own OAuth flow as their own Odoo user, so their agent inherits their identity rather than a shared key. Policies are set per client, so a finance analyst’s assistant and a warehouse supervisor’s assistant can hold entirely different permissions against the same Odoo instance.
Revoke the session or the client from the governance panel in Odoo. Revocation follows RFC 7009 and takes effect on the next call, without disturbing any other user’s connection. This is the difference between per-user OAuth and a shared API key, where revoking one person’s access means rotating a credential everyone depends on.
The KSROlabs MCP Server that this layer builds on runs on Odoo Community and Enterprise alike, across Odoo 14 to 19. This matters because Odoo 20’s native MCP is Enterprise-only, so Community users have no built-in option at all. Confirm the current edition and version matrix for the governance layer with us before purchase.
No. Odoo Online does not allow installing custom server-side modules, so no governance module — or MCP module of any kind — can run there. For Odoo Online instances, KSROlabs maintains the Odoo Online MCP Gateway, a hosted external bridge that connects MCP clients over Odoo’s standard XML-RPC API. Odoo.sh is a different product and does support module installation.
No. The governance layer is a native Odoo module that runs inside your own Odoo instance, so policy decisions and audit records happen where your data already lives. Your ERP data moves directly between your Odoo and your AI client, with no KSROlabs server in the path. This is the structural difference between a governance layer that installs in your ERP and a hosted relay that proxies your traffic.
We will walk through the policy model against your own Odoo, your own models, and your own compliance requirement — and tell you plainly if the native or hosted options already cover you.
Requires the KSROlabs MCP Server for Odoo.
