Skip to main content
The audit log records every authenticated request to the oleander API for your organization, whether it came from the app, an API key, the CLI, an SDK, or an agent over MCP. Use it to answer who did what, when, and with which credential. Open it at oleander.dev/app/audit.

What is recorded

Each entry is one request. The table shows the newest entries first and loads older ones as you scroll, and clicking a row opens the full record. The full record also includes the API key ID for key-based requests, an impersonator ID when a support session acted on the principal’s behalf, any error code and message, and the request parameters.

What is not recorded

Request parameters are filtered to a fixed list of structural fields - identifiers, names, resource and action names, table and namespace names, paging and status fields. SQL text, scripts, chat messages, connection settings, credentials, and uploaded files are never written to the audit log, and a request body over 16 KiB is omitted. Where something was filtered, the record says so instead of showing an empty value. Reading the audit log is itself an audited request.

Permissions

Audit logs are an IAM resource with two actions, both on the organization-wide scope Audit logs → All audit logs: OrganizationAdmin holds both, SecurityAdmin holds Describe, and UserAdmin holds Manage grants. There is no per-entry scope. See Resources and actions.
The permission definitions ship with the system-managed roles today. Enforcement of Describe on the audit page follows once every organization’s system-managed roles have been backfilled; until then the page is available to members of the organization.