Security: marlinspike/OCaaS

This repo assumes one trusted operator managing a private OpenClaw appliance. It is not designed as a multi-tenant platform and does not try to isolate hostile operators from each other.

External skills come from a separate repo and should be treated as third-party code. A pinned commit SHA makes builds reproducible; it does not make the skill safe.

Before enabling or promoting a build:

1. review config/manifests/skills.txt
2. review config/manifests/skills.lock.yaml
3. verify the pinned commit SHA
4. review declared binaries, env vars, and risk level
5. run validation and smoke paths

CI hard-fails if the configured skills ref is not a full commit SHA.

The repo differentiates agent posture intentionally:

• main
  • orchestration-oriented
  • narrower direct tool authority
  • denies high-risk direct tools like exec, process, browser, and canvas
• coder
  • strongest capability set
  • explicitly sandboxed
  • writable workspace access is scoped through OpenClaw sandbox config
• writer
  • minimal surface
  • exec and process denied by default
  • additional risky tools denied unless the config is deliberately widened

These controls are implemented through OpenClaw per-agent tool policy and sandbox config, not ad hoc wrapper logic.

Secrets are operator-supplied through env/config, not baked into the image. Important points:

• the OpenClaw artifact is fetched during build, but credentials are not copied into the final image
• the runtime image contains build metadata, not secrets
• required runtime secrets such as OPENCLAW_GATEWAY_TOKEN live in operator env/state
• third-party skills may require additional env vars declared in the lockfile; those should be reviewed before use

Mounted runtime state exists so the container can be replaced safely without losing:

• active OpenClaw home/config/state
• project workspace data
• runtime logs and durable session state

That durability is intentional and is the reason upgrade/rollback can be container-level operations.

• final runtime container runs non-root
• root filesystem is read-only where practical
• Linux capabilities are dropped
• no-new-privileges:true is enabled
• optional extra skills mount is read-only
• nonessential network fetching is not done inside the Dockerfile
• agent restrictions are enforced through OpenClaw config

• the trusted operator is not isolated from the appliance state
• host-mounted runtime state is not sandboxed from the operator who owns the host
• external skills are not magically safe just because they are pinned
• agent sandboxing reduces risk but does not turn the appliance into a hostile multi-tenant boundary

Because runtime state is on the host mount, you should:

• back it up
• protect filesystem permissions
• avoid sharing it casually
• treat rollback as normal and rehearsed

• image build: deterministic artifact staging, not Dockerfile fetches
• runtime container: hardened, non-root, read-only by default
• skills: controlled by manifest + lock + eligibility validation
• state: durable and operator-owned, not ephemeral