Configuration
MIT Network Audit is built to do the right thing out of the box: install it and it starts capturing, attributing, and hash-chaining every network call — no tuning required. So this page is not a list of dials you must turn before the tool works. It is the opposite: a calm walkthrough of the few settings that exist, what each one changes, and — just as importantly — why the most sensitive of them is off until you deliberately turn it on.
MIT Network Audit is built to do the right thing out of the box: install it and it starts capturing, attributing, and hash-chaining every network call — no tuning required. So this page is not a list of dials you must turn before the tool works. It is the opposite: a calm walkthrough of the few settings that exist, what each one changes, and — just as importantly — why the most sensitive of them is off until you deliberately turn it on.
There are two places to look. The everyday settings live in Odoo's own Settings screen, under a Network Audit section. The one advanced capability — Forensic body capture — is locked behind a dedicated role and ships off, and the second half of this page is devoted entirely to it.
You reach the settings from the top menu Network Audit → Configuration → Settings (they also appear in the standard Odoo Settings app, in the Network Audit section).
The Network Audit settings: the master switch, strict redaction, retention, and disabled channels.
The settings, one by one
Every setting here changes how much is captured or for how long it is kept — none of them can make the tool store something it structurally cannot. Request and response bodies are never written to the ordinary audit log no matter how these are set; that is a property of the data model, not a checkbox (see Why you can trust it). With that floor in place, here is what each field does.
| Setting | What it does | Default behaviour |
|---|---|---|
| Network auditing enabled | The master switch. When off, there is no capture at all — the interceptor stays out of the way and nothing new lands in the Audit Log. | On — auditing is the whole point. |
| Strict redaction | Tightens capture even further: keep only host / IP / port / sizes, and mask everything else at the moment of capture. URL paths, query keys, header values — masked before they are ever written. | A privacy-maximising mode you can opt into. |
| Audit retention (days) | How long captured rows are kept before the retention vacuum may remove them. 0 = keep everything, forever. |
Your choice — and bounded by a safety rule, below. |
| Disabled channels | A comma-separated list of capture channels to switch off (for example socket,smtp). Empty = capture all channels. |
Empty — every channel on. |
Network auditing enabled — the master switch
This is the on/off for the entire tool. Leave it on: a transparency tool that isn't capturing proves nothing. The switch exists for the rare moment you need to pause capture deliberately — and turning it back on resumes capture immediately, without a restart.
Off means a gap you can see
Turning auditing off does not erase anything already recorded — the append-only log keeps every row it already holds. But while it is off, calls are not captured, so there will be a visible gap in the timeline. For a tool whose job is to prove what happened, that gap is itself meaningful. Turn it off only with intent.
Strict redaction — keep even less
Standard capture is already metadata-only and masks header values while keeping their names. Strict redaction goes further still: it strips the record down to just the bare destination facts — host, IP, port, and sizes — and masks everything else at the moment of capture, before it is written. That means even the URL path and the query keys are masked away.
Turn this on when you want the smallest possible footprint and you don't need path-level detail to answer "is my data leaving to MIT?". You can still see where each call went and how big it was — which is exactly the signal the Trust Report is built on. You give up some of the forensic detail you would otherwise see on a Forensic Record.
Audit retention (days) — and the one line it will never cross
Set how many days of history to keep. Older rows become eligible for the retention vacuum,
the only process allowed to remove rows from the otherwise append-only log. Set it to
0 to keep everything, indefinitely.
There is one safety rule baked in, and it matters:
The vacuum never deletes at or after the signed head
The retention vacuum will not remove any row at or after the signed head — the daily HMAC-signed marker of the current end of the chain. This is deliberate. The signed head is what makes log truncation detectable even after rows are gone; if retention could trim past it, you could no longer prove the tail of the chain was intact. So no matter how short you set retention, the recent, signed portion of the log is protected. To understand how the signed head and the hash chain fit together, see Why you can trust it.
Disabled channels — turn off what you don't want to watch
The interceptor wraps several channels — the different ways traffic can leave or
enter your instance. If you have a reason to stop capturing one of them, list its name
here, comma-separated. For example, socket,smtp turns off the raw-socket backstop and
SMTP capture while leaving the rest on. Leave the field empty to capture all
channels — the recommended default for the broadest proof.
Channels change at runtime — no restart
Editing this list takes effect immediately. You do not need to restart Odoo to turn a channel on or off. For the full picture of which channels are wrapped and how each network call is attributed back to the Odoo module that made it, see Architecture.
Egress Components — what counts as "MIT-bound"
The Trust Report's whole verdict rests on one classification: is this destination MIT-bound, or third-party? That decision is driven by a seeded catalogue you can review under Network Audit → Configuration → Egress Components.
Each entry maps a known destination to whether it belongs to MIT (the small license-validation metadata traffic the tool expects) or to one of your own providers (your Gmail/IMAP, your own LLM key, your Microsoft 365). When the Trust Report sorts every captured destination into the MIT-bound destinations and Third-party destinations panels, this catalogue is the rulebook it follows. Reviewing it tells you exactly which endpoints the tool treats as MIT's — so the classification is never a black box.
The Egress Components catalogue — the rulebook that decides which destinations count as MIT-bound.
The catalogue is auditable, like everything else here
Because the only traffic MIT Network Audit expects toward MIT is small license metadata, the catalogue of MIT endpoints is short and inspectable. If a destination isn't in it, it shows up as third-party — attributed to whichever of your own modules and providers made the call. For how the verdict reads this, see Reading the dashboard and Verdicts explained.
Forensic body capture
Everything above keeps to the tool's core promise: bodies are never stored. There is exactly one capability that can change that, for legal and incident cases only — and it is walled off accordingly.
Forensic body capture lets a designated officer store the actual request and response bodies of captured calls, for situations where the metadata isn't enough and you need the content itself as evidence. It is the one part of MIT Network Audit that holds payload, so it is treated with the most care in the whole product:
- it is OFF by default,
- it is officer-only — restricted to the Network Forensic Officer role,
- and every read of a captured body is itself logged to the append-only journal.
Turning on body capture stores bodies — officer-gated and audited
With body capture enabled, MIT Network Audit begins storing the request/response bodies it captures — the one place the tool ever holds payload rather than just metadata. This is off by default and on purpose. Only a Network Forensic Officer can enable it or read what it stores, and each read of a stored body is written as its own row in the append-only Audit Log — so even looking at a body leaves an immutable trace. Enable it only for a genuine forensic or legal need, and turn it off again afterwards.
Who can use it
There are two access groups in the security model, and they are not the same:
| Group | What it grants |
|---|---|
| Network egress log: audit group | Read the audit — the Trust Report, the Audit Log, the verdicts. This is the role for anyone who needs to verify traffic. It does not grant access to captured bodies. |
| Network Forensic Officer | The only role that can enable forensic body capture and read the bodies it stores. Captured-body records are gated by Network egress body: forensic officer only. |
Keep the Network Forensic Officer group as small as you keep any role that can touch payload — ideally empty until a specific case calls for it. Reading the audit (the everyday job) never requires it.
The Captured Bodies view
When body capture is on, the stored bodies appear in the Captured Bodies view
(network.egress_body) — a list with a decoded popup so an officer can read a captured
body's content. Because access is gated to the Network Forensic Officer role and each
read is logged, opening a body here is itself an auditable event: the journal records who
looked, and when.
Treat captured bodies as the most sensitive data in the system
A captured body can contain exactly the private payload the rest of this tool is built not to keep. While body capture is on, those bodies live in your own Odoo database, behind the Network Forensic Officer gate. Restrict the group tightly, turn capture off as soon as the case is closed, and remember that every read is recorded — for the person reading, that recording is a feature, not a risk.
A sensible default posture
For most installations, the right configuration is the one you already have after installing:
Recommended defaults
- Network auditing enabled: on — keep capturing.
- Strict redaction: on if you want the smallest footprint; off if you want path-level detail on each Forensic Record.
- Audit retention (days): as long as your policy requires;
0to keep everything. The signed head is protected either way. - Disabled channels: empty — capture all, for the broadest proof.
- Forensic body capture: off, and the Network Forensic Officer group empty, until a specific legal or incident need arises.
This keeps MIT Network Audit doing what it is for — observing, attributing, and proving where your data goes — while holding the one payload-bearing feature behind a deliberate, audited door. The tool observes and proves; it does not block traffic, and it is not a firewall. For where that line sits, see Security & boundaries.