BytesafeDependency Firewall

Review the audit log

Trace who changed firewall configuration, policy, tokens, and teams, and spot denied or failed attempts.

The audit log records control-plane actions: configuration and policy changes, token and team management, permission denials, and OIDC exchanges. It answers "who changed the firewall", where the firewall log answers "what happened to that package request". Every namespace has one; events cannot be edited or deleted from the API.

Read it

In the dashboard, open Audit. The table shows Timestamp, Action, Resource, Actor, IP, and Status. Select an event for its API outcome, request metadata, and action-specific detail. The detail shows both the actor's name and raw user ID, and links the resource to its page where one exists.

Via the API:

curl -H "Authorization: Bearer $BYTESAFE_TOKEN" \
  "https://eu-sov-1.bytesafecloud.eu/v1/<namespace-id>/audit?action=firewall.config.upsert&from=2026-07-01T00:00:00Z"

Filters: action, resourceType, resourceId, actorUserId, outcome (success/failure), from/to (RFC 3339), limit (up to 1000), offset. actorUserId takes the raw user ID, not a name; copy it from an event's detail view. The full event shape and action catalog are in the audit log reference.

Reviews worth running

Who changed policy? Filter action=firewall.rule.upsert (and firewall.exception.upsert, firewall.config.upsert). Each event names the actor and the firewall. If you run config as code, anything here not coming from the CI identity is drift.

Denied attempts. action=authz.denied lists actions users tried without permission; the event data names the missing permission. Repeated denials are either someone probing or someone who needs a grant, and both are worth knowing.

Failed logins and bad tokens. action=auth.failed records authentication failures with a hashed token identifier when the requested namespace can be assigned to one tenant. This makes retries correlatable without exposing the token. An attempt that cannot be assigned safely is not shown in a tenant's namespace audit log.

Token lifecycle. token.personal.create, token.service.create, token.delete. Service token creation is admin-gated, so this list should be short and recognizable.

CI identity exchanges. oidc.exchange events record successful exchanges and failures that identify a configured Trusted Builder, including repository mismatch and verification failure. Malformed tokens and unknown audiences cannot be assigned to a tenant and are not shown in its audit log. For a known builder, this is the first place to look when a GitHub Actions workflow cannot get a token.

Exception governance. firewall.exception.upsert paired with the exception's reason and expiry in the event data shows who is granting waivers and how often; expired-and-renewed patterns show up here.

Correlate with the firewall log

Audit events carry the same requestId and interactionId fields as firewall log entries. An interaction ID appended to a CI token ties the pipeline's package requests (firewall log) and its config changes (audit log) into one story. See Access Tokens.

Verify

Make a harmless change (rename a rule description, create and delete a token) and confirm it appears as an event with your user as the actor. If you review on a schedule, script the API query and alert on authz.denied and auth.failed counts.

On this page