Defaults
Clawker is secure by default. The three settings that shape your posture out of the box:
Everything below is either on by default or off for a deliberate safety reason. You opt into looser settings explicitly.
Agent Awareness Prompt
Clawker bakes a managed agent prompt into the image at the location the harness declares (for the claude harness,/etc/claude-code/CLAUDE.md, automatically loaded by Claude Code) so the agent understands its containerized environment — what it can and cannot do, how to diagnose firewall blocks, and which clawker firewall commands unblock a domain. The payoff is self-service: when the agent hits a blocked domain, it explains the problem and suggests the right command without the user needing to know the details. See Container Internals → Agent Awareness Prompt for the full prompt contract.
Security Controls
Each control below has a dedicated reference page. This section states what it does and where its defaults live. Network firewall. The egress firewall is deny-by-default: DNS queries for unlisted domains return NXDOMAIN, and TLS connections to unlisted destinations are reset, so only domains you explicitly allowlist are reachable. It runs as a shared Envoy + custom-CoreDNS + eBPF cgroup stack that clawker manages automatically, without granting agent containers any special privileges. The global toggle lives insettings.yaml (firewall.enable); per-project allow rules live in security.firewall in your .clawker.yaml. See the Firewall guide for the full architecture, configuration, CLI commands, and troubleshooting.
Harness egress floors. The only domains allowed by default come from the selected harness bundle’s egress floor — the bare-minimum set that harness needs for API access, authentication, and telemetry (for the claude harness, that includes the npm registry because Claude Code is npm-distributed). GitHub, PyPI, and every other service you must add yourself via add_domains or rules. See Default allowed domains (harness floors) for the per-harness lists, and Harness floor vs project rules for how a floor composes with your project config.
Container PID 1 and privilege drop. The container’s PID 1 is clawkerd, the per-container supervisor. It runs as root but never executes user-controlled code in its own process: the user CMD (the harness CLI) is forked with kernel-side privilege drop via SysProcAttr.Credential, so there is no user-mode code path between root and the unprivileged container user (clawker). The control plane talks to clawkerd over a CN-pinned mTLS Session. See Container Internals → clawkerd for the full PID-1 contract.
Docker socket, capabilities, and infrastructure privileges. Agent containers run fully unprivileged — no extra Linux capabilities (cap_add: [], though the field is available if a workflow genuinely needs one), no Docker socket. The elevated permissions required for eBPF enforcement (CAP_BPF, CAP_SYS_ADMIN, /sys/fs/bpf) live only in clawker’s infrastructure containers, on the enforcement side of the trust boundary — they constrain what agents can do without extending the agent’s reach. Enabling security.docker_socket: true mounts the host Docker socket read-write and is a major privilege-escalation vector — it gives the agent root-equivalent control of your host. See the Threat Model for the infra-privilege breakdown and Shared Responsibility for the Docker socket implications.
Host proxy and credential forwarding. The host proxy is a lightweight daemon on your host machine (enabled by default) that forwards Git HTTPS credentials and brokers browser-based OAuth flows (e.g. gh auth login) into containers — without copying secrets in. See Credential Forwarding.
Egress audit trail. Every firewall decision — allowed, denied, or bypassed — is recorded as a structured event in the clawker-ebpf-egress OpenSearch index, so bypass windows are not a forensic blind spot. See Egress Observability.