What You’ll Learn
- What Declaw’s audit log actually captures (lifecycle + security events, not request/response bodies)
- How to opt a sandbox out of audit logging with
AuditConfig(enabled=False) - The retention window and why it is platform-wide
Prerequisites
- Declaw instance running and
DECLAW_API_KEY/DECLAW_DOMAINset
Code Walkthrough
This example is available in Python. TypeScript support coming soon.
1. The default: audit on
Declaw records a fixed set of lifecycle and security events for every sandbox by default. You do not have to enable anything.2. Opt out of audit logging
If a sandbox is handling sensitive workloads and you’d rather have no record at all, passAuditConfig(enabled=False) on the policy:
audit field also accepts a plain boolean as a shorthand:
enabled=False, the orchestrator drops gated events (network,
command, filesystem, snapshot, pty, security) for that sandbox at the
source — nothing is shipped to the collector for those categories. Only
lifecycle and admin events are still recorded.
AuditConfig field | Default | Description |
|---|---|---|
enabled | True | Whether events for this sandbox are recorded. Set to False to opt out. |
3. What the audit log captures
The audit log records a fixed set of events. These are emitted by the orchestrator and node collector, not by the HTTP proxy:- Lifecycle (always recorded) —
vm_created,vm_killed,vm_paused,vm_resumed, plus their_failedcounterparts. - Snapshot (gated) —
vm_snapshot_started,vm_snapshot_completed,vm_snapshot_failed,vm_restore_started,vm_restored,vm_restore_failed. - Network (gated) —
egress_allowedandegress_blockeddecisions from the per-sandbox firewall (domain, destination IP/port, rule that fired).
detail payload scoped to the event.
Request and response bodies are not written to the audit log. PII
redaction and prompt-injection scanning emit their own metrics; see
the PII and injection-defense cookbook pages for how to read those.