It can act, because it can be refused.
Odient does real work in your Odoo, but only what the person asking is cleared to do, only after you approve a write, and never off the books. The governance layer is not a setting. It is the reason it is allowed to act at all.
RECORD™ allowed · blocked · approved
Five checks stand between a prompt and your data.
Every request, whether from Diana, the Odient panel or any MCP client, walks the same five gates before it touches a single Odoo record. Each gate can stop it cold. Watch two requests take the walk.
access
screening
policy
approval
logging
Two requests, the same five gates. Diana’s confirmed order clears all five and reaches your data. Diego’s out-of-scope read is stopped at layer 3 - it never reaches Odoo, and the stop is written to the record, in the same trail as the work that went through. The firewall is not a wrapper around the model. It is the path the model has to take.
Every write is decided before it happens.
Reading is scoped to the person. Writing is held to a gate you set: human-in-the-loop by design, each of these a control Odient checks before a single record changes. Built and tested this way, not bolted on.
- ✓Allow / deny / confirmPer model, per action. Each write is matched to a rule before anything runs. Some go, some stop, some wait.
- ✓Value capsA reminder over a set amount, a change past a threshold: held for a person, not sent on the assistant’s say-so.
- ✓Rate limitsHow many writes an assistant can make in a window is bounded, so nothing runs away in a loop.
- ✓Dry-runThe write is computed and shown first, so the exact change is on screen before it ever lands.
- ✓Human-confirmAnything above policy waits for a person to approve. Drafts stay drafts until you say go.
- ✓PII redactionSensitive fields are stripped at egress, before anything leaves your Odoo on its way to a model.
- ✓One audit record per writeAllowed, blocked or approved: every decision writes exactly one row, tied to the person who made the request. Not a sample. Every write.
This is the trail, not a diagram of one.
A real AI audit trail: every question, action and refusal Odient handled: user, channel, model, action, decision. The declined rows sit in the same list as the work that ran. Nothing hidden, nothing silent.
You can let it act, because every move is auditable.
Who asked, what ran, whether policy allowed it, exactly when. Ask and Act are one trail. A granted execution and a declined attempt sit side by side, tied to the person who made the request. That is the reason a lean team can hand real work to AI.
The AI can only reach what the person can.
Access is decided per user, not per feature. Diana never sees more of your Odoo than the person asking already can. API keys are scoped, and when a call needs to hit Odoo, a short-lived session exchange mints a native-scope key bounded by that person’s own permissions, then lets it expire. No long-lived, all-powerful token sitting on a server. Plain plumbing, and the part we were most careful to get right.
# Scoped key in → short-lived native key out session = exchange( tenant="elmwood", user="marco.ricci", scope="odient_mcp", # narrow, per-user ) # mints a native-scope key just for this call, # bounded by Marco's own Odoo permissions, # then expires. Nothing long-lived is stored. token = session.native_key(ttl=300)
Built and tested: the write-gate and session exchange are how Odient is architected, not a checkbox you turn on later.
tell you no.
An assistant that can do real work is only safe if it can be refused. Ask Odient to touch a record you are not cleared to see, and it stops. The refusal is logged too, as visible as the work that went through.
Frequently asked questions.
Can the AI write to our production ERP?
Only through the gate you set, and only as the person who asked. Each write is matched to a rule (allow, deny or confirm) with value caps, rate limits and a dry-run that shows the exact change before it lands. Anything above policy waits for a person.
Where do our prompts and data go?
Your Odoo data is read to serve the request in front of it, never to train models. Sensitive fields are stripped at egress before anything reaches a model, and every request is logged, served or refused. For teams that need everything inside their own walls, an on-prem option is in development.
What does the audit trail actually record?
One record per decision: who asked, through which channel, what ran, and whether policy allowed it: allowed, blocked and approved rows side by side, nothing sampled, nothing hidden. It is the reason a lean team can hand real work to AI and still pass its own audit.
Are you SOC 2 compliant?
Not yet. SOC 2 is in progress. We will publish the report the day it is issued, not a target date before it exists.
Is our data encrypted?
Encryption is in progress, not complete. We are not going to claim it is done until it is verified end to end, at rest and in transit.
Where is our data hosted?
US and Europe today, or the AWS region closest to you if neither fits. Your Odient contact can confirm the exact region for your account.