# Organization audit log

> What MMW records in the organization audit log, who can see it, and why it never contains memory content.

On this page you will learn:

1. which events go into the organization audit log;
2. who can open it;
3. what the log does not contain and where to look for the rest.

The log answers one question: who did what to whose knowledge. Example: Northwind's security team wants to know who read Ben's records after he left, and to whom they were opened.

## Who sees the log

The Audit log tab exists only for the **admin** and the **auditor**. Other roles do not see the tab, and the server refuses their requests with `org_admin_required`.

The auditor role is designed for exactly this kind of oversight: an auditor sees the log but cannot read a single memory record or issue a key.

## What is recorded

| Event in the account | API value | When | Details |
|---|---|---|---|
| offboarding started | `offboarding_started` | "Start offboarding" was clicked | Recipient, keys revoked, records by visibility, uploaded sessions |
| offboarding completed | `offboarding_completed` | "Complete offboarding" was clicked | — |
| handed-over knowledge read | `read_transferred` | The recipient read a leaver's records | Number of records and where: account (`account`) or agent (`mcp`) |
| visibility of a handed-over record changed | `transferred_visibility_changed` | The recipient opened a leaver's record to the unit, project or organization | Record ID, new visibility, node |
| `access_term_changed` | `access_term_changed` | The admin set, extended or removed an access term | New access end date |

Each event has a time, who did it ("Who") and whose knowledge or access it concerns ("Whose"). The log shows the latest 200 events, newest first.

Sample log after Ben's departure:

| When | Action | Who | Whose |
|---|---|---|---|
| 2026-10-12 15:40:02 | visibility of a handed-over record changed | anna@northwind.example | ben@northwind.example |
| 2026-10-12 15:31:47 | handed-over knowledge read | anna@northwind.example | ben@northwind.example |
| 2026-10-12 11:05:10 | offboarding started | anna@northwind.example | ben@northwind.example |

## What the log does not contain

- **Memory content.** Only actions, IDs and counts are logged. The rule is built into the function that writes the log: memory text is never passed to it.
- **Ordinary reads and writes.** A member searching colleagues' records or saving new ones does not appear in the organization log; only reads of departed people's knowledge are tracked.
- **Keys.** Neither key secrets nor key hashes are logged.

Separately from the organization log, the account has an MCP operations log (Activity): time, tool and outcome of each call. It does not contain record text either, and for integration calls via `gateway_call` neither arguments nor results are stored.

## How to use it

- **After offboarding**, check that the knowledge is read by the person it was handed to, and that the records opened to the team are the right ones.
- **For contractors**, the log shows each extension: who extended access and until when.
- **For oversight**, give your security reviewer the Auditor role instead of Admin: they see the log but cannot change the structure or read memory.

## Next steps