Every workspace keeps a trail of the actions that change who can do what. It is written once and never edited, and it is pruned after 90 days.

What is recorded

Roles - created, updated, deleted. An update carries a diff: which permissions were added, which removed, and whether the name, description, colour or default flag changed.
People - added, with the role they landed on, removed, role changed, status changed, and page-scoped grants added or revoked. Somebody leaving a workspace is recorded as a removal, with that person as their own actor.
Tokens - created and revoked, including the asset tokens that sign private media.
The workspace - settings updated, and the draft secret regenerated.
Webhook endpoints - created, updated, deleted, secret rotated, and a stored delivery replayed. An update carries where the URL pointed before, which events were added or removed, and whether it was switched off. A rotation carries the grace window the previous secret keeps signing for, because a rotation with no grace breaks every delivery until the consumer redeploys. An endpoint the delivery worker switches off after twenty consecutive failed deliveries is recorded too, as its own action with the failure count - never as somebody's edit.
Page publishing - published, unpublished, a draft discarded, a layout published, a layout draft discarded, a development draft promoted, and a change of editorial stage. Publishing is the moment a change becomes visible to the public, so it belongs here even though the edit that produced it does not. A layout publish is its own action: it changes what the page renders without making the page live.
Deletions - a page, and how many child pages went with it; a page lock taken over from whoever held it; a model, and how many records went with it; a single record; a bulk product deletion, with the count and whether the selection was made by ids or by a filter; a form, and how many submissions went with it; and a single submission. A submission entry names the form, the submission's status and when it arrived - never what the visitor typed. The audit log is read on a different permission from the submissions themselves, so repeating the answers in it would hand them to somebody who cannot open the inbox.

Each entry names the entity, when it happened, and who acted - a person, or the platform itself when it acted on its own, such as a webhook endpoint switched off by repeated failures.

Every entry says where the write came from. A change made in the admin carries no origin at all. A change made by the AI assistant is marked as such and names the tool it used; a change made through the MCP server is marked as that surface instead. The action is the same either way - a publish by the assistant is the same published entry a person makes - so the trail reads as one history and can then be narrowed to the machine writes when that is the question. The actor is still the person whose token made the change: the assistant acts on somebody's behalf, never on its own.

The organization keeps its own log

An organization owns the plan, the seats and the single sign-on configuration. Those events belong to no single workspace, so they are written to a separate trail with its own reader. The split is what keeps the workspace log honest: an entry there always names a workspace, and an organization event has none to name.

Recorded on the organization:

The organization itself - created, renamed, deleted, and its settings changed. A rename carries whether the name, the slug or both moved; a settings change carries the new default role for members and whether members may create workspaces of their own.
Ownership - transferred, naming who handed it over and who received it.
Seats - somebody invited, with the organization role they were offered; an invitation cancelled; an invitation accepted; a member removed; a member's organization role changed. These are the entries a seat dispute turns on, and a seat is what the plan is counted in.
Workspaces - moved into or out of the organization, naming both sides of the move.
Single sign-on - a domain added, verified or removed, the connection configured, a test connection run with its result, and enforcement switched on or off. Enforcement decides who can still sign in with a password, so it is recorded as an action of its own rather than as one more settings change.

The organization role somebody holds - owner, admin or member - is a different thing from the workspace role that grants permissions inside a workspace. A change to one is never recorded as a change to the other, and the two trails never mention each other's vocabulary.

An action that changed nothing writes nothing. Saving the settings form without touching a field, or setting a member's role to the one they already hold, leaves no entry: a trail padded with non-events is a trail nobody reads.

What is not, and why

Content edits are not in the audit log. No page saves, no block tweaks, no media uploads.

Publishing and deletion are the two exceptions, and both are on the list above. The line is not "content" against "access" but recoverable against not. A draft edit is reversible and private, so it is left out. The moment content becomes public is recorded, and so is the moment it stops existing - a deletion is the one content operation that nothing else can answer afterwards, because the thing anyone would ask about is gone.

That is a deliberate line, not an oversight. Those events are high-volume - a busy afternoon produces hundreds - and mixing them in would bury the fifteen entries that matter under thousands that do not. The audit log answers "who changed access"; for "who changed this page", the page's own version history records every save with its author.

The rule of thumb behind the list: it covers what affects trust, authentication and billing, and what an attacker would want to cover their tracks about.

Who can read it

The workspace log requires the permission to manage roles. That is intentional - the log is largely a record of permission changes, so the people who can grant access are the people who can see who granted it.

The organization log requires managing the organization: being its owner, or holding the organization's admin role. The workspace permission does not reach it. Somebody who can manage roles inside a workspace has no claim on the record of who was invited into the organization above it, and holding that permission in every workspace the organization owns still does not open it.

Ninety days

Entries older than ninety days are pruned by a scheduled job, which sweeps both trails in the same pass. If your retention obligations are longer than that, export what you need on a schedule rather than discovering the gap during an audit.

One entry outlives its subject on purpose: deleting an organization is recorded, and that record is not deleted along with it. It ages out with everything else once ninety days have passed.

Next steps

Members and roles - the permissions whose changes land here.
API tokens - creation and revocation, both recorded.
Webhooks - the endpoints whose changes are recorded here.
Single sign-on - domains, configuration and enforcement, all recorded on the organization.
Version history - the content trail this one deliberately leaves out.