Frequently asked questions

You are about to put a piece of software in the path of every network call your Odoo instance makes. That is exactly the kind of thing you should be suspicious of. The honest answers below are the same ones we would want before trusting a tool like this on our own production server — what it costs, what it can break, what it keeps, and what it deliberately cannot do.

You are about to put a piece of software in the path of every network call your Odoo instance makes. That is exactly the kind of thing you should be suspicious of. The honest answers below are the same ones we would want before trusting a tool like this on our own production server — what it costs, what it can break, what it keeps, and what it deliberately cannot do.

If your question is not here, the Overview explains the why, and the How it works page explains the how in full detail.

Does it slow Odoo down?

For everyday use, no — not in a way you would notice.

When a network call happens, the module does a small, bounded amount of work: it records the metadata of the call (direction, destination, sizes, timing, masked header names) and attributes it to the originating module. It does not read, copy, or store the body of the request or response — there is nowhere to put a body, so the heaviest part of network traffic is never touched.

To keep the dashboard fast even on a busy instance, the Trust Report does not re-read every individual row. It reads a pre-aggregated rollup table that a background job keeps up to date, so the summary cards, the donut, and the byte bars render from a small, ready-made table rather than a full scan of the journal.

Can it break my email or my network calls?

No — and this is a hard design rule, not a hope.

The module is fail-open always. If anything goes wrong inside the auditor — capturing, attributing, redacting, or writing to the log — that error is swallowed, and the original network call proceeds exactly as it would have without the module installed. The audited call must never break because of the auditor.

In plain terms: if the audit ever has a bad day, the worst case is a missing row in the log — not a failed email send, a dropped IMAP sync, or a broken license check. The auditor is built to step out of the way rather than stand in it.

Does it store my email contents? My documents? My AI prompts?

No. Bodies are never stored.

This is structural, not a setting you have to trust us to leave switched on. The captured event has no body field at all — there is physically nowhere in the record to put the contents of a request or response. What it keeps is metadata: direction, channel, protocol, method, destination host, URL path, the names of query keys, source and destination IP and port, status, the request and response sizes, timings, masked headers (header names are kept, their values are masked), and a salted HMAC fingerprint.

A fingerprint lets you tell whether two calls carried the same payload without the payload itself ever being recorded. So you learn that a call happened and where it went and roughly how big it was — without your actual data being copied into the audit.

Can MIT — or anyone — quietly alter or delete the log?

That is the whole point of the design, so the answer is: not without it being detectable.

The audit journal (network.egress_log) is append-only. It refuses write and unlink operations — including sudo — with the single exception of the retention vacuum. There is no supported path, for us or for an administrator, to edit a row after it is written.

On top of that, every row is hash-chained. Each row's row_hash is a SHA-256 hash that folds in the previous row's hash. Change one row and every row after it no longer matches — the chain breaks at exactly the tampered row. The Verify chain button on the Trust Report recomputes the entire chain and names the first row that does not match, if any. When it is clean you see:

Audit chain verified OK — no tampering detected.

And to catch the one attack a chain alone cannot — simply deleting the most recent rows — a daily job HMAC-signs the current chain head into Odoo's configuration (mit_network_audit.signed_head). The signed head outlives any rows you delete, so even truncating the log is detectable: the signed head points at a position the shortened log can no longer reach. The signing key is a per-database secret generated on first use; it is never in the source code.

What counts as "MIT-bound" traffic?

"MIT-bound" means a connection whose destination is one of MIT's own endpoints — in a healthy install, that is the small license-validation metadata that confirms your MailDesk or license-locker licence is valid. No email, no documents, no customer data.

Every destination the module sees is classified as either MIT-bound or third-party using a seeded catalogue of known MIT endpoints (the Egress Components list under Configuration). That single split is the heart of the proof: your other modules should be talking to your providers — your Gmail or IMAP server, your own OpenAI / LLM key, your Microsoft 365 — which land in the third-party bucket, not the MIT one.

The Trust Report shows the two buckets side by side as click-through tables, so you can see at a glance what goes to MIT and what goes to providers you chose. See Reading the Trust Report.

Do I have to configure anything to use it?

No. The module captures traffic and builds the chain-protected log out of the box, and the Trust Report works with no setup.

The settings exist only if you want to tune behaviour. In Configuration → Settings you will find:

Leaving everything at its default gives you a fully working audit. See Configuration.

Is it really open source?

Yes — and it is the one MIT module shipped that way, on purpose.

MIT's commercial modules (MailDesk, the license locker) ship obfuscated to protect the licensed software. This module is the deliberate exception: it is never obfuscated, so you can read it, run it, and audit it line by line. Open source is not a footnote here — it is the feature. A trust tool you cannot inspect would be a contradiction.

The interceptor core is written so that the trustworthy part stands on its own: the interceptor/ code is pure Python with zero Odoo imports, which means it can be read and reasoned about as a standalone library, separate from the Odoo glue around it.

Does it work on Odoo.sh?

Yes. The module installs on both self-hosted Odoo and managed platforms like Odoo.sh.

On a self-hosted or Kubernetes deployment where you control the server-wide module list, it loads server-wide so every worker is covered. On a managed platform such as Odoo.sh — where you cannot set server-wide modules — it installs from an ordinary Apps install and hooks in from there. Both paths funnel through the same single, idempotent setup step, so the behaviour you get is the same either way. See Installation.

It also runs on Odoo 17, 18, and 19; this documentation is verified against Odoo 18 and the behaviour is equivalent across versions.

What is "self-egress", and why is it an alarm?

"Self-egress" would be the audit module making a network call of its own. By design, it never does — the module makes no outbound calls.

That is a deliberate, checkable promise: the auditor should be a silent observer, not another thing phoning home. So if the Trust Report ever sees a connection attributed to mit_network_audit itself, it does not quietly ignore it — it raises an alarm. The Self-egress trust chip on the dashboard shows the count, and it should always read zero.

The reason it is treated as an alarm rather than a curiosity is simple: a transparency tool that started talking to the network would be the last thing you should trust. Holding the auditor to its own audit is how the tool keeps itself honest.

How long is data kept?

For as long as you choose. The Audit retention (days) setting controls it:

• Set it to 0 to keep everything indefinitely.
• Set it to a number of days to let a vacuum job trim rows older than that.

There is one important guard rail: the vacuum never deletes at or after the signed head. The chain head that the daily signing job protects always survives, so retention can prune old history without ever erasing the position that makes truncation detectable. Retention shortens the journal; it cannot be used to quietly drop the evidence that the journal was shortened.

See Configuration.

Does it block bad traffic, like a firewall?

No — and it is important to be honest about this. The module observes, attributes, and proves; it does not block, filter, or alter traffic. It is a transparency and detection tool, not a firewall.

It also proves only what it can observe. The capture is deep — it reaches down to the raw socket — but it is not a formal sandbox and makes no mathematical guarantee against an adversary who manages to bypass a layer it does not hook. It dramatically raises the bar for hidden exfiltration and makes any normal call visible and attributable; it does not claim to be unbeatable. We would rather say that plainly than oversell it.

Related

• Overview — the trust problem this module solves.
• Installation — self-hosted and Odoo.sh.
• Reading the Trust Report — the verdict, chips, and destination panels.
• The audit log — the append-only journal.
• Verify & export — re-check the chain and produce a signed proof.
• Configuration — the master switch, strict redaction, retention, and channels.
• Security — the access groups and off-by-default forensic body capture.