Chapter 7: Deployment Security

Outline

7.1 Introduction to Deployment Security

• Deployment as the moment when architectural trust assumptions become real operating constraints
• Why OpenClaw deployment security is about ownership, blast radius, and recoverability rather than only hardened images
• Core goals: explicit ingress control, bounded execution, trustworthy state, and provable operations

7.2 Trust Zones and the Hardened Deployment Topology

• Separating edge, control plane, worker, data, and operations surfaces
• Using topology to enforce authority boundaries already defined in earlier chapters
• Preventing direct user-to-worker and worker-to-internet trust shortcuts

7.3 Build, Artifact, and Image Provenance

• Signed artifacts, dependency discipline, and reproducible deployment inputs
• Treating model, policy, and runtime configuration as part of the security artifact set
• Preventing dirty-repo and unreviewed build drift from reaching production

7.4 Gateway Ownership and Ingress Discipline

• One owner for each ingress path: no competing pollers, duplicate bridges, or shadow listeners
• Normalizing requests before execution and preserving truthful delivery state
• Hardening public entry points without turning the gateway into a universal trust source

7.5 Worker Isolation, Job Runtimes, and Network Segmentation

• Isolated agent and subagent workers with internal-only defaults
• Scoped task delegation instead of ambient runtime authority
• Using network policy and runtime constraints to limit lateral movement and arbitrary egress

7.6 Secrets, Configuration, and Policy Distribution

• Ephemeral credentials, narrow secret scope, and fast rotation
• Local configuration as deployment truth
• Keeping policy freshness and configuration drift visible

7.7 Durable State, Storage Boundaries, and Recoverable Rollouts

• Distinguishing durable operational state from ephemeral scratch space
• Protecting databases, workspaces, object stores, and backups as separate security subjects
• Designing deployments that can roll forward or back without erasing evidence

7.8 Liveness, Presence, and Operational Freshness

• Proving that a runtime is actually alive, current, and authoritative
• Distinguishing always-on workers from on-demand identities
• Why stale ownership signals are a deployment security failure, not just an ops nuisance

7.9 Monitoring, Watchdogs, and Safe Fallbacks

• Monitoring the deployment boundaries, not just process uptime
• Verifying schema, browser, queue, and audit dependencies before claiming success
• Failing in bounded, truthful ways when infrastructure is degraded

7.10 Incident Handling in Production Deployments

• Containing compromise without destroying evidence
• Replacing suspect runtimes with clean artifacts instead of trusting in-place repair
• Restoring service only after ownership, policy, and audit continuity are re-established

7.11 Case Study: Eliminating Duplicate Ingress Ownership

• A realistic OpenClaw failure mode involving competing pollers or stale gateway owners
• How deployment controls, audit records, and service checks reveal the real system of record
• Lessons for hardened production operation

7.12 Chapter Summary

• The deployment security principles that matter most for OpenClaw
• Common anti-patterns to avoid
• Preparing for Chapter 8 on incident response