MIT Network Audit docs

MIT Network Audit

MIT Network Audit rests on a few simple ideas. Once you see them, the rest of these docs is detail.

4 min read

The open module that proves MIT is not reading your data. MIT ships its commercial modules — MailDesk, the license locker — obfuscated, so you cannot read the bytecode and prove for yourself that your email and business data are not being sent to MIT. This module is the one component shipped in the clear: readable, runnable, and auditable. It watches every network call your Odoo instance makes, attributes each one to the module that made it, and proves the result in a tamper-evident log — so you can answer one question with your own eyes: "Is my data leaving to MIT?"

Works with Odoo 17, 18, and 19. This documentation is written and verified against Odoo 18; behaviour is equivalent across the supported versions.

Where to go next

  • Overview — what MIT Network Audit is, the trust problem it solves, and how to install it. → Overview
  • First look — open the Network Audit menu and find your way around. → First look
  • Reading the Trust Report — the verdict, the trust chips, the destination panels, and what each means. → Reading the Trust Report
  • The audit log — the append-only journal and the Forensic Record behind every call. → The audit log
  • Verify & export — re-check the hash chain and produce a signed proof a standalone tool can verify. → Verify & export
  • Configuration — the master switch, strict redaction, retention, and which channels to capture. → Configuration
  • How it works — the interception architecture, in honest detail. → How it works
  • Security — the threat model, the two access groups, and the off-by-default forensic body capture. → Security

In one minute

MIT Network Audit rests on a few simple ideas. Once you see them, the rest of these docs is detail.

  1. It watches every call, in and out. The module intercepts every inbound and outbound network operation of your Odoo instance — down to the raw socket — and attributes each call to the Odoo module that made it. So a row in the log does not just say "something connected somewhere"; it says which addon connected where.
  2. It keeps metadata, never bodies. What was sent is never stored. The captured event has no body field at all — that is built into the data structure, not a setting you have to trust. It keeps the destination, the sizes, the timing, masked headers, and a salted fingerprint, so you learn that a call happened and where it went without your data being copied into the log.
  3. It classifies MIT-bound vs third-party. Every destination is sorted into MIT-bound (license-validation traffic to MIT) or third-party (your own Gmail/IMAP, your own OpenAI/LLM key, your own Microsoft 365). That single split is the heart of the proof: your other modules should be talking to your providers, not to MIT.
  4. The log cannot be quietly edited. The journal is append-only and hash-chained — each row seals the one before it. A daily job HMAC-signs the chain head, so even deleting rows is detectable. You can re-verify the whole chain on demand and export a signed proof that a separate tool can check.

The result is exactly what you want from a trust tool: open the Trust Report, read a single verdict — all-clear, attention, or alarm — and, if you want more than a verdict, drill all the way down to the individual call and verify the maths yourself.

The MIT Network Audit Trust Report showing an all-clear verdict The Trust Report — the verdict, the trust chips, and the traffic summary at a glance.

What it does NOT do

An honest boundary — read this before you rely on it

MIT Network Audit is a transparency and detection tool, not a sandbox or a firewall. Be clear-eyed about what that means:

  • It observes; it does not block. The module watches, attributes, and proves traffic. It does not stop a connection from happening. It is not a firewall.
  • It proves what it can observe. The capture is deep — it reaches the raw socket — but it cannot make a formal guarantee against an adversary who manages to bypass a layer it does not hook. We say this plainly rather than oversell it.
  • Forensic body capture exists, and it is off by default. A Network Forensic Officer can choose to turn on storing request and response bodies for a legal case. It is off by default, officer-only, and every read of a captured body is itself logged to the same append-only journal. See Security.

Highlights

  • Every call, attributed to a module. Outbound and inbound traffic is captured and tied to the originating Odoo addon — not just an anonymous destination.
  • MIT-bound vs third-party, side by side. Two destination panels make the core question visible at a glance: what goes to MIT, and what goes to your own providers.
  • Metadata only — bodies are never stored. Redaction is structural; the event has no place to put a body. With Strict redaction on, even more is masked at the moment of capture.
  • Tamper-evident by design. An append-only, hash-chained log, a daily signed chain head that survives deletions, on-demand Verify chain, and a portable signed proof export.
  • Zero self-egress. The module makes no outbound calls of its own — and the Trust Report raises an alarm if it ever sees a call attributed to MIT Network Audit itself.
  • Open source, never obfuscated. This is the MIT module you can read. That is the whole point.

New here? Start with the Overview. Looking for a specific term? See the Glossary.