The audit log

Who this is for: Owner, Manager — requires org.audit.read. Where: Settings → Audit Log

Role changes, membership grants, app enablement, API keys at work, agent tool calls: the actions that matter after the fact are recorded here, newest first.

The defining property of this log is that there is one of it. A change made by a person in the UI, by an integration holding an API key, and by an MCP agent acting on somebody's behalf all land in the same stream, in the same shape. There is no separate "machine log" to reconcile against the human one.

One trail. A person, an API key and an agent in the same stream, in the same shape.

Read a row#

Column	What it tells you
When	The date of the action
Actor	Who did it — a person by their sign-in address, or an API key or agent by its identifier
Channel	How it arrived: app from the product, api from a key, mcp from an agent tool call
Action	What was done — app.enabled, member.revoked, or the endpoint or tool that was called
Target	What it was done to, as an object type and a short id
Outcome	ok, denied, or error

Channel is the column people underuse. It is what separates "the Manager changed this" from "something holding the Manager's API key changed this", and those are different conversations.

Find what you are looking for#

The log is a single chronological stream: there is no actor, date or action filter on the screen today. To find a specific event:

1. Open Settings → Audit Log.
2. Start at the top — the newest entries are first, so recent work is usually already on screen.
3. Use your browser's find-in-page for an actor, or for an action like role.created.

Note

The list shows the organisation's recent trail rather than its entire history. If you need a long-range or filtered extract — for an auditor, or an incident review — that is a request to the Nerve team rather than something to reconstruct by scrolling.

Failures are recorded too#

An outcome of denied or error is not noise, and it is the reason to read the log rather than to trust that the trail only contains things that worked. A refused action still tells you somebody tried: a revoked API key still being used, a member reaching for a screen they no longer hold, an agent asking for a tool its connected context does not carry.

A run of denied rows against one key or one agent is the signal that an integration is configured for permissions it was never granted.

Agent activity is in here, not somewhere else#

An MCP agent's tool calls appear as ordinary rows on the mcp channel, named by the tool — get_kpis, create_guest — and carrying the same outcomes as everything else. Nerve's position is that an agent acting for you is auditable in exactly the way you are: tools are permission-filtered to the connected context, sensitive actions are confirmed, and every call is written here. See MCP agents.

What's next#

• Escalation — the narrower verification trail for money-impact actions
• Team — the membership changes this log records
• API keys — what an API-key actor is
• MCP agents — what an agent actor is