Reading the Trust Report
You installed MIT Network Audit to answer one blunt question: is my data leaving to MIT? The Trust Report is where you get the answer — at a glance for a quick reassurance, and in detail when you want to see every destination for yourself. This page walks you through the dashboard top to bottom, so that every banner, chip, number, and table means something concrete to you rather than being decoration.
You installed MIT Network Audit to answer one blunt question: is my data leaving to MIT? The Trust Report is where you get the answer — at a glance for a quick reassurance, and in detail when you want to see every destination for yourself. This page walks you through the dashboard top to bottom, so that every banner, chip, number, and table means something concrete to you rather than being decoration.
Open it from the top menu: Network Audit → Trust Report. It is an OWL dashboard (an Odoo client action) and reads only from the append-only log, so opening it changes nothing — you can refresh it as often as you like.
Who can open it
The Trust Report is for the Network egress log: audit group — the internal users you have granted read access to the audit. It shows metadata only: who talked to whom, how much, and when. It never shows message bodies; those are not stored at all unless a forensic officer has explicitly enabled body capture (off by default). See Security & access for the roles.
The hero verdict card with its trust chips — the first thing you read.
The header buttons
Four buttons sit at the top of the report. They are the only things on this page that do something rather than simply show you a number.
| Button | What it does |
|---|---|
| Refresh | Re-reads the latest data and redraws every card, chart, and table. Nothing is captured by pressing it — it just reloads what the auditor already recorded. |
| Verify chain | Recomputes the entire hash-chain of the log and confirms no row has been altered or removed. On success you get the toast "Audit chain verified OK — no tampering detected." If a row was tampered with, it names the first affected row instead. |
| Export signed proof | Opens the Export Signed Audit wizard, which produces a signed JSON file you can hand to a third party (or your own auditor) and verify outside Odoo. |
| Audit Log | Jumps to the raw append-only journal — the full, drill-down list of every captured event. |
Verify the chain yourself, any time
Verify chain is the proof button. It does not trust a stored "OK" flag — it recomputes every row's hash from the row before it and tells you the truth on the spot. Press it whenever you want the report to re-earn your confidence. The mechanism is explained in The append-only journal.
The forensic-capture status banner
At the very top, a status banner tells you the mode the auditor is running in — most importantly, whether forensic body capture is on. By default it is off, and the banner reassures you of exactly that: bodies are not being stored.
This matters because the whole promise of the module is that your private payloads are never kept. Forensic body capture is an opt-in, officer-only feature for legal cases, and even when an officer turns it on, every read of a captured body is itself logged. The banner is there so you never have to wonder which mode you are in — it says so out loud.
The hero verdict card
The hero card is the headline. It collapses everything the report found into one of three plain-English verdicts:
| Verdict | What it means |
|---|---|
| all-clear | Nothing unexpected. MIT-bound traffic is the small license-validation metadata it should be, and the auditor itself made no calls of its own. This is the state you want to see. |
| attention | Something is worth a second look. Open the destination tables below and see for yourself which traffic raised it. |
| alarm | The auditor saw a call attributed to itself — self-egress — which by design should never happen. This is the one thing the module treats as a red flag against itself, and it tells you loudly. |
The verdict is a summary, not a substitute for looking. For the full meaning of each state — what triggers it and how to respond — read Verdicts explained.
The trust chips
Just under the verdict sit four small trust chips. Each one is a one-word promise the module is making about how it recorded the data — so you can trust the numbers above them.
- Append-only log — the audit table rejects edits and deletes (even with
sudo), except the retention vacuum. Nobody quietly rewrote history. - Hash-chained — every row's hash is computed from the row before it. Remove or change one row and the chain no longer matches, which Verify chain will catch.
- Bodies OFF — request and response bodies are not stored. The captured event has no body field at all; this is structural, not a setting someone could flip. (If a forensic officer has enabled body capture, the banner above will say so.)
- Self-egress N — the count of calls the auditor itself made. By design this is 0. Any number above zero is what flips the verdict to alarm.
Why the chips come before the data
The chips are deliberately placed next to the verdict, not buried at the bottom. A number you cannot trust is worse than no number. The chips say, in four words, that the record underneath them is append-only, chained, body-free, and that the auditor stayed out of the traffic it was watching.
The three summary cards
Below the verdict, three cards count the traffic the auditor attributed during the period:
| Card | What it counts |
|---|---|
| Total events | Every inbound and outbound network operation the auditor captured. |
| MIT-bound events | Calls whose destination is classified as an MIT endpoint. For a healthy MIT install this should be small — license-validation metadata, nothing more. |
| Third-party events | Calls to everywhere else: your own Gmail/IMAP, your own LLM provider, Microsoft 365, and any other service your modules use. |
The split between MIT-bound and Third-party is the heart of the report. It is the direct, countable answer to "is my data going to MIT, or to my own providers?" A destination is classified by the seeded Egress Components catalogue of known MIT endpoints — everything not on that list is third-party.
The summary cards — the countable answer to "how much goes to MIT vs. to my own providers?"
Traffic distribution (the donut)
The Traffic distribution donut shows the same MIT-bound vs third-party split as the summary cards, but as a proportion by number of events. It is the quick visual: a tiny MIT-bound slice next to a larger third-party slice is exactly the shape a well-behaved MIT install should have — a little license chatter, and the rest of your traffic going to the providers you chose.
Volume — bytes transferred (the byte bars)
Right next to the donut, Volume — bytes transferred shows the same destinations measured in bytes, not event counts. This is not a duplicate of the donut — it answers a different and more important question.
A handful of events can move a lot of data, and a lot of events can move almost none. Exfiltration shows up in volume, not in event count: ten quiet license pings are not the same as one large upload. By charting the request and response sizes the auditor recorded for each destination, the byte bars make data leaving visible even when the number of calls looks unremarkable. If a destination's slice of the bytes looks wrong for what that service should be doing, that is your cue to open its table below.
Read the donut and the bars together
The donut tells you how often each side is contacted; the byte bars tell you how much crosses the wire. For spotting exfiltration, the byte bars are the ones to watch — a small, predictable MIT-bound byte bar is the reassurance you are really after.
Left: the donut (how often each side is contacted). Right: the byte bars (how much data crosses the wire).
The two destination tables
This is where the report stops summarising and lets you check the raw facts yourself. Two panels list the actual destinations the auditor saw:
- MIT-bound destinations — every endpoint classified as MIT. On a clean install these are the license-validation hosts and nothing else.
- Third-party destinations — every other endpoint: your mail providers, your LLM, your Microsoft 365, and so on — the services you configured.
The two destination panels — MIT-bound on one side, third-party on the other.
Each row is a destination, with the metadata the auditor kept for it. Rows click through to the raw log: select one and you are taken into the append-only journal filtered to that destination, where you can open any single event as a Forensic Record and see the full attribution — which Odoo module made the call, its author, the call site, the sizes and timing, and the tamper-evident chain fields. Nothing is hidden behind the summary; the summary is just the fast path to the same facts.
What you will and won't see in a row
A row shows you direction, channel, protocol, method, host, path, ports, status, the request and response sizes, timings, and masked headers (the header names are kept; their values are masked). You will not see a message body — there is none stored to show.
Putting it together
Read the report top-down and it answers your question in layers, each more detailed than the last:
- The banner confirms bodies are not being captured.
- The trust chips confirm the record itself is append-only, chained, and body-free.
- The verdict gives you the one-line answer: all-clear, attention, or alarm.
- The summary cards and donut show the MIT-bound vs third-party split by events.
- The byte bars show the same split by volume — where exfiltration would actually show.
- The destination tables let you check every real endpoint, and click through to the raw, tamper-evident log for any one of them.
What this report can and cannot promise
The Trust Report proves what the auditor can observe — and it observes deeply, down to the socket. It is a transparency and detection tool, not a firewall and not a formal sandbox. It does not block traffic; it observes, attributes, and proves. It cannot make a guarantee about a layer it does not hook. That is the honest boundary — within it, the report is a faithful, verifiable record of where your data went.
Related
- Verdicts explained — what all-clear, attention, and alarm mean, and how to respond.
- The append-only journal — the raw, hash-chained log behind every row, and how Verify chain works.
- Exporting a signed proof — hand a verifiable export to a third party.
- Security & access — who can read the audit, and the forensic-officer body-capture model.