Audit trail
The audit trail is an append-only record of every privileged action taken in your Workforce organization: members invited, roles changed, API keys rotated, Groups remapped, security rules edited, routing policies changed, skills published, plus the handful of reads worth recording on their own, such as a log search. It is the artifact your security review asks for, and the evidence you pull when you need to know who changed what and when.
It is not activity. What an employee’s AI client did lives in Tool call logs and LLM calls; model requests and tool calls are never audit events. The audit trail is administrative change.
Open Settings → Audit trail. Reading and exporting it needs the View audit trail permission. The filter bar takes three things: date (before, after, or between), event type, and the user who acted. Filters are held in the URL, so a filtered view is a link you can send someone. Click a row for the event detail and, on updates, the full field-level diff.
What’s captured
Each entry stores a snapshot of the actor and the target, denormalized at write time, so the row stays readable after the user, role, or resource it names has been deleted.
The table is append-only. Entries are never modified after they are written, and nothing can be backfilled: an event is emitted inside the transaction that performs the mutation, or not at all. Failed actions mostly write nothing, because the mutation never began, with the exception of LOGIN_FAILED and MFA_VERIFICATION_FAILED.
Event catalog
Event types are uppercase strings, and the same value works as an ?event_type= filter on the audit-log endpoint. The authoritative list is the event_type enum on the audit-log endpoint in the API reference: it is generated from the source and picks up new values as features ship, so read it there before you hard-code a filter. The dashboard’s event-type dropdown is generated from the same source, and the newest event types can land in the record before they reach the dropdown, so filter on the endpoint when the dropdown does not offer the one you want.
Model provider credentials reuse the same CREDENTIAL_* names as employee Connector connections. The resource type on the row is what tells them apart.
The skills events are described alongside the flows that write them in Publishing skills, Reviewing submissions, and How agents load skills.
What an update entry looks like
Update events pair an identifying prefix with a per-field diff, so you can scan the feed and see what changed without fetching the resource:
Every diffed value is truncated to 100 characters in the description. The event detail shows each changed field’s old and new value side by side.
Sensitive fields
Secret values never reach an audit row in the first place:
- Auth-adjacent handlers omit the body. Credential, SSO, sign-in, password reset, and API key handlers record that the action happened, with the entity named in the description, and store no request payload.
- Updates diff before mutating. Fields holding secrets are summarized as
changedrather than rendering the old and new value, so the description carries no secret material.
Handlers that are not auth-adjacent do persist their validated request body as-is. If you handle especially sensitive configuration, review what those rows contain.
Investigation flow
Who changed this? Filter by event type, then read the resource column. Every event of that type comes back in order, with the user on each row.
What did this person do? Filter by user. You see everything that member touched across resources, which is the check to run before revoking an admin’s access.
Exporting
Export produces CSV of whatever filter is applied, so a compliance review that needs a 12-month window is a date filter and a download. The export itself is recorded as AUDIT_LOG_EXPORTED, so there is a trail of who pulled what.
The CSV carries the event ID, timestamp in ISO 8601 UTC, event type, actor email and ID, role, IP address, resource type and ID, source, and the JSON-encoded diff for update events. Cells beginning with =, +, -, @, a tab, or a carriage return are prefixed with a single quote to neutralize CSV injection.
For automated forwarding, the audit-trail export endpoint is documented in the API reference.
Data retention
One window covers audit events, Tool call logs, and the violation records behind Violations and alerts.
The default is 90 days. Some plans keep data longer, and an Enterprise contract can set a window of its own, so read the window that applies to you off your plan on Billing or off your contract.
Records belonging to an employee who has left follow the same window. Deprovisioning through SCIM revokes access immediately, and that employee’s audit entries and tool call history are kept until the window closes, then purged.
If your compliance requirements run longer than your window, export on a schedule and keep the results in your own systems. CSV export covers any filtered view, the audit-log endpoint covers audit events, and the log endpoints feed a warehouse or a SIEM.
What it doesn’t capture
The audit trail covers administrative actions in the dashboard and over the management API: changes to configuration and access, plus the few reads worth recording on their own. It does not include tool calls, model requests, or the OAuth steps that lead up to a CREDENTIAL_CREATED event. For the full picture, read it alongside Tool call logs and LLM calls.
Next
Decide who on your team can perform audited actions, and who can read the trail, in Team and roles.