Audit Log
The audit log is an immutable, tenant-wide record of every meaningful action taken in your tenant — sign-ins, user and role changes, workflow and AI Employee edits, runs, knowledge base changes, integration and API-key events, and more. Use it to investigate unexpected behavior, demonstrate compliance, and hold actions accountable. Events are append-only: nothing in the log can be edited or deleted.
The audit log lives on the Audit Logs tab at /admin/governance/audit, alongside PII governance.
What you can see depends on your role. The audit feed is open to every role except no_access, but each event row is filtered server-side by your role — see Role-based visibility. system_admin and user_admin see every event in the tenant; builder_admin and builder see a build-resource subset; a user sees only their own actions. The PII access log is stricter — it is restricted to system_admin (the holder of the audit.view capability).
What an event records
Every event captures who acted, what they did, and what they acted on:
| Field | Meaning |
|---|---|
created_at | When the action happened. |
actor_id, actor_name, actor_email | Who performed it, captured at event time. |
actor_role | The actor's role at the time of the action. |
action | The action performed (for example user.role_changed, workflow.published). |
resource_type, resource_id, resource_name | What was acted on. The name is stored at event time. |
resource_version_id | The version of the resource, when applicable — the basis for change tracking on versioned resources like workflows. |
metadata | Free-form context about the event (JSON). |
ip_address | The actor's IP address, when available. |
Events are emitted asynchronously by every service. The actor and resource names are denormalized into the event at the time it is written, so the log remains accurate even if the user or resource is later renamed or deleted.
Role-based visibility
The audit feed is scoped to your role in the SQL query itself, so pagination and counts always reflect exactly what you're allowed to see:
| Role | What appears in the feed |
|---|---|
system_admin, user_admin | Every event in the tenant. |
builder_admin, builder | Events on build resources: workflow, agent, knowledge_base, run, document, integration. |
user | Only events where the user was the actor (their own actions). |
no_access | Nothing. |
Viewing and filtering
The tab shows the most recent events first, loaded in pages with a Load more control. Three filters narrow the feed:
- User — filter to a single actor.
- Resource type — for example users, sessions, API keys, workflows, agents, knowledge bases, connections, integrations, or evaluations.
- Action — for example login, logout, user created, role changed, user deactivated, workflow created/published/deleted, run started/completed/failed, agent created, document uploaded, knowledge base created, search executed, connection OAuth connected, integration installed, or API key created/revoked.
Filters combine, and changing any filter reloads from the first page.
Contextual activity feeds
The same audit data also appears in context throughout the product, scoped to a single resource. Wherever you see an Activity tab — on SSO config, email domains, API keys, and in the workflow builder's versions rail — it is showing the audit events for that one resource. Because each event carries a resource_version_id, this is how you track what changed on a versioned resource (such as an AI Employee's workflow), who changed it, and when, in chronological order.
These contextual feeds are powered by the same list endpoint, scoped with resource_type and resource_id.
Exporting
Select Export CSV to download the currently loaded events. The export includes: time, actor name, actor email, actor role, action, resource type, resource name, and resource ID. The file is named audit-log-<date>.csv. Load more pages before exporting if you need a longer range — the export reflects what's currently loaded into the view.
PII access log
When PII governance is enabled, every PII decision is recorded as a dedicated audit event (pii_access or pii_data_export). A separate, system_admin-only endpoint, GET /audit/pii-access, projects these events into compliance-friendly fields rather than requiring you to parse raw metadata:
| Field | Meaning |
|---|---|
entity_type | The taxonomy entity the decision was made for (for example EMAIL_ADDRESS). |
decision | What happened to the value: Tokenize, PartialMask, Redact, or PassThrough. |
boundary | Where the decision applied — for example LLM_COMPLETION, CHAT_DISPLAY, or TENANT_EXPORT. |
purpose_category | The purpose recorded with the decision (for example END_USER_AUTHORED, INTEGRATION_EGRESS). |
integration_type | The downstream integration or LLM vendor, on egress decisions. |
byte_count | Bytes exported, on pii_data_export events. |
This endpoint accepts filters for time range, actor, entity type, boundary, purpose, integration type, and decision, so you can answer questions like "what cleartext PII left the tenant for which integration, and when."
Reference: endpoints
| Action | Endpoint | Access |
|---|---|---|
| List audit events (role-filtered) | GET /events | Role-based visibility |
| Get one event | GET /events/{id} | Role-based visibility |
| List PII-access events | GET /audit/pii-access | system_admin |
The event feed uses cursor pagination (limit up to 200, defaulting to 50) and supports actor_id, resource_type, resource_id, action, from, and to filters.
Retention. Audit events are retained per tenant for a configured period (365 days by default). Cleanup is a background process; there is no API that edits or deletes individual events.
What's next
- Governance and permissions — how role determines audit visibility.
- PII and data governance — the policy decisions the PII access log records.
- User management — the source of user, role, and membership events.