Audit Logs

Identity systems earn trust when access and administrative change remain explainable later. This page keeps the audit-focused operator guidance from the underlying manual while excluding the private implementation paths used to collect or expose that data.

Scope

This guide covers the in-product audit-log review workflow for operators and administrators.

Portal now ships a dedicated audit-log browser at Monitoring -> Audit Logs, backed by . The same page also exposes an Export CSV action backed by for the current filtered result set.

Access

Audit-log review requires portal.audit.view.

Current roles with that permission:

• super_user
• admin

Review Workflow

1. Navigate to Monitoring -> Audit Logs.
2. Confirm the current scope banner:
3. operator-tenant sessions can search across all tenants
4. non-operator sessions are restricted to the current tenant
5. Select Apply filters to rerun the server-side search.
6. Select Export CSV when you need a reusable bulk-review artifact for the current filter set.
7. Review the table columns for timestamp, tenant, actor, action, resource, IP, and the details summary.
8. Select Review on any row to inspect the full event payload, actor attribution, resource metadata, and network context.
9. Use Previous and Next to move through server-driven pages of results.

Operational notes:

• non-operator callers are restricted to their own tenant
• operator callers can query across tenants
• the browser always reloads from the backend; the page is not reconstructing a local audit cache
• CSV export uses the current search filters, tenant scope, and a flattened row shape so the operator can bulk-review the same slice outside the browser.
• ip_address and created_at are part of the stored audit row and should be used together when reconstructing a timeline
• JML template changes, imported or scheduled trigger creation, terminal trigger outcomes, manual run kickoff, callback receipt, callback-driven step completion, terminal run outcomes, and step retries now appear as governance.jml.* events, while the resulting access changes still appear under governance.access_grant.*
• forwarded headers only affect ip_address when the request came through a configured trusted proxy boundary
• when multiple trusted reverse proxies sit in front of Portal, controls how many trusted hops Portal walks from the right before it records the client IP

Practical Filters

• Use action=user.updated or a similar exact action value when you need one event type.
• Use a date range for incident response instead of paging the whole table.

Recovery Guidance

• If the result set is empty, first confirm you are using the correct tenant and date window.
• If the actor is no longer present in the directory, actor_email may be null even though the audit row still exists.
• If the event exists in the API but not the current page, widen the filters or move through the paginated result set.