> Source: https://builder.ema.ai/v2/administration/audit-log > Title: Audit Log # 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](/builder/v2/administration/pii-and-governance). > [INFO] > **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](#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-.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](/builder/v2/administration/pii-and-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. > [INFO] > **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](/builder/v2/administration/governance-and-permissions) — how role determines audit visibility. - [PII and data governance](/builder/v2/administration/pii-and-governance) — the policy decisions the PII access log records. - [User management](/builder/v2/administration/user-management) — the source of user, role, and membership events.