Skip to main content
Audit logs record authenticated API requests across your entire organization. Use them to review who called Kernel, which endpoint they called, when the request happened, and how the request completed. Choose the endpoint that matches the amount of data you need: Search and download are available on Start-Up and Enterprise plans. Continuous S3 export is available on Enterprise. Audit logs are also available from the CLI.

Filter audit logs

The API and SDKs use the same filters for search and downloads:
  • auth_strategy filters by authentication method, such as api_key, dashboard, or oauth.
  • service filters by the service that emitted the audit event.
  • method returns only requests that use the specified HTTP method.
  • exclude_method omits requests that use any of the specified HTTP methods.
  • search matches path, user ID, email, client IP, or status.
  • search_user_id matches requests from the specified user IDs in addition to any free-text matches.

Search audit logs

Each API page contains up to 100 events. The SDK pagination helpers request older pages as you iterate.
See the API reference for the full request and response schema.

Download audit logs

A download covers a time window of up to 30 days. The SDK download helpers default to jsonl.gz and write the result to a destination you provide. The helpers don’t close the destination. Python provides equivalent sync and async methods; both accept a synchronous binary destination.
Downloaded chunks contain one JSON object per line. They use the same fields as search results and add event_id. For direct HTTP integrations, see the API reference for pagination headers, formats, and the full request and response schema.

Continuous S3 export

Continuous export writes new audit log events to an S3 bucket that you control. A destination is an organization-level resource: Kernel assumes an IAM role in your AWS account and writes jsonl.gz objects to the configured bucket. The destination is created paused so you can configure and verify IAM before delivery starts.

Set up a destination

You can use the SDKs, the CLI, or the HTTP API. All destination requests require an organization-level credential. The setup steps below use the SDKs. For the CLI walkthrough, see the CLI reference.

1. Create a paused destination

Create the destination with the customer role ARN. The create response contains the destination id, the Kernel role ARN that must be trusted (kernel_role_arn), and the unique STS external ID (external_id). Save all three values. The external_id is not your organization ID and is not interchangeable with an external ID from another destination. Every destination is an S3 destination in jsonl.gz format and starts with status: "paused". If you use KMS, set kms_key_id to a key ID, alias, or ARN in the destination region.

2. Configure the IAM trust policy

Update the trust policy on the customer role supplied as role_arn. Use the kernel_role_arn and external_id returned by the create call. The values below are placeholders; replace both of them with the values from your response.
Principal.AWS must be the returned kernel_role_arn, not the customer role’s own ARN. The sts:ExternalId condition must be the returned external_id. Recreating a destination generates a new external ID, so update this trust policy again if you recreate it.

3. Grant S3 and KMS permissions

Attach an identity policy to the customer role. Grant s3:PutObject for real delivery and the test probe. Granting s3:DeleteObject is recommended so Kernel can remove the temporary probe after a successful test. The resource should match the configured prefix. If you use a different prefix, replace audit-logs/* below. Omit the KMS statement when kms_key_id is empty.
When KMS is configured, the KMS key policy must also allow the customer role to use kms:GenerateDataKey (unless the key policy delegates access to IAM policies). The test and real uploads use the same encryption request: SSE-KMS with the configured key. Without a configured KMS key, the bucket’s default encryption applies.

4. Test and activate

The test endpoint assumes the customer role, writes a temporary gzip probe, and attempts to delete it. The probe uses the same request metadata as a real delivery: a SHA-256 checksum, Content-Type: application/gzip, and SSE-KMS when configured. Run the test before changing the destination to active. A successful test returns stage: "complete". A failed test identifies assume_role or put_object and returns assume_role_failed or put_object_failed. Do not activate the destination until the test succeeds.
Activation starts delivery at the activation time. It does not backfill events recorded before activation.

Object layout

Every continuous export object uses this exact key layout:
For example, a destination with prefix audit-logs writes under audit-logs/destination_id=.... If the prefix is empty, the key starts with destination_id=... and has no leading slash. The date and hour partitions are UTC and identify the calendar hour that fully contains every row in the object. This makes the layout safe for Hive-style partitioning. The format is always jsonl.gz: each decompressed line is one JSON event, including event_id.

Delivery semantics

  • Delivery is at least once. A retry can rewrite the same object.
  • Each event-time window is held for about 10 minutes before it commits. A row that becomes visible after its window has committed may not be delivered.
  • Delivery begins at activation time; events before activation are not backfilled.
  • Pausing stops new delivery attempts. Resuming starts from the resume time; events recorded while paused are never exported. Pausing is not a way to defer delivery.
  • An S3 upload already in progress may complete after a pause or delete. Its rows can appear again after the destination is resumed.

Monitor delivery

Use the SDK retrieve and list methods, the CLI, or the HTTP GET endpoints to inspect the destination and its delivery health. The health fields are: The cursor and timestamp/error fields can be absent until the destination has attempted delivery. Use last_error, last_error_at, and consecutive_failures together when investigating a destination that is active but not progressing.

Troubleshoot delivery

  • assume_role / assume_role_failed: Check the customer role’s trust policy. The principal must be the current kernel_role_arn from the destination response, and sts:ExternalId must equal the current external_id. Recreating a destination issues a new external ID; update the trust policy after recreation.
  • put_object / put_object_failed: Confirm that the customer role can write to the configured bucket and prefix with s3:PutObject, and that the bucket is in the configured commercial AWS region. Grant s3:DeleteObject as well so the test probe can be cleaned up.
  • KMS failures: Confirm that the KMS key is in the commercial aws partition, that an ARN’s region matches the destination region, and that both the role policy and key policy allow kms:GenerateDataKey. If you do not need a customer-managed key, clear it and use bucket-default encryption.
  • A probe remains after a successful test: Probe cleanup is best effort. Add s3:DeleteObject for the configured prefix and remove any leftover .kernel-audit-log-export-test-*.jsonl.gz object yourself.
  • A PATCH returns 409 Conflict: The destination changed concurrently. Retrieve fresh state, merge your intended fields with that state, and retry the update. Do not retry a stale read-modify-write payload unchanged.
  • No objects after a pause or downgrade: Check status and the plan. Pausing and non-Enterprise status stop new delivery; restore Enterprise and follow the normal activation/resume path if the destination is paused. Events recorded while paused are not backfilled.