Share feedback
Answers are generated based on the documentation.

Local audit logs

The sandbox daemon writes local audit records as JSON Lines (.jsonl) files. Local audit logs stay on the host that produced them and can be collected by your own log shipper. Local delivery is independent of cloud delivery, so you can use local files with cloud delivery on or off.

The sandbox daemon writes local audit records only for signed-in users who have an AI Governance license and are governed by an enforced centralized organization policy. Docker Sandboxes users without both do not send audit data to audit logs. To confirm governance is active, run sbx policy ls. The output includes a Governance: Managed by <org> line when an organization policy is in effect.

What gets recorded

The daemon writes two categories of local record:

  • Evaluation records capture each policy decision: the resource, the action, the verdict, and the reason for a denial.
  • Session lifecycle records mark the start and end of each daemon run. Evaluation records share the run's audit_session_id, so you can correlate every decision back to a daemon session.

Records contain metadata only. They don't contain prompt content, agent output, or parameter values. For field details, see Audit record reference.

A network evaluation record looks like this:

{
  "audit_event_id": "95e7257f-93c9-4f29-bde7-88830e2dae80",
  "timestamp": "2026-05-28T19:15:00.728933Z",
  "schema_version": "1.82.0",
  "category": "AUDIT_CATEGORY_EVALUATION",
  "decision": "AUDIT_DECISION_DENY",
  "username": "jordandoe",
  "user_email": "jordandoe@example.com",
  "org_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
  "org_name": "Acme Inc",
  "audit_session_id": "8a3bc076-79d0-4502-baf3-cc6ad35fb578",
  "resource_id": "example.com:443",
  "os": "macos",
  "app_version": "v0.31.0",
  "client_name": "sbx",
  "hostname": "host-machine",
  "deny_reason": [
    "no applicable policies for op(action=net:connect:tcp, resource=net:domain:example.com:443)"
  ],
  "action_type": "network_egress",
  "network_egress": { "protocol": "tcp" },
  "agent": "claude"
}

Where records are stored

The daemon writes audit records, not the CLI. Running a command such as sbx create sends a request to the daemon, and the daemon emits the resulting record to its own audit directory.

The default location depends on your operating system:

OSDefault path
macOS~/Library/Logs/com.docker.sandboxes/sandboxes/auditkit/
Linux${XDG_STATE_HOME:-~/.local/state}/sandboxes/sandboxes/auditkit/
Windows%LOCALAPPDATA%\DockerSandboxes\sandboxes\logs\auditkit\

The directory layout differs by platform because each operating system places application logs in its own conventional location.

Files are named audit-<utc-timestamp>-<process-uuid>-<seq>.jsonl.

The daemon writes in-progress records to a temporary .tmp file and finalizes it into a .jsonl file by atomic rename. Finalization happens at a rotation threshold: by default, 5 minutes, 1000 events, or 50 MiB, whichever comes first. Finalization also happens when the daemon shuts down cleanly. Only .jsonl files are complete. Treat .tmp files as incomplete and don't collect them.

Sandboxes never delete .jsonl files. Retention and cleanup are the responsibility of your log shipper or your own housekeeping.

Collect records with a SIEM

Point your log shipper at the audit directory and configure it to collect .jsonl files only. Tools such as the Splunk Universal Forwarder, Filebeat, and CrowdStrike Falcon LogScale read the directory and forward each line as an event. Because in-progress records live in .tmp files until they are finalized, collectors never see partial records.