Integrating OPA at the container runtime level is a solid first step, but you should consider how it interacts with your seccomp and capability profiles. A policy that blocks root is good, but if you're still granting CAP_SYS_ADMIN or allowing dangerous syscalls, your containment is incomplete. I'd recommend writing Rego policies that also validate the security context of the pod or container against a baseline seccomp profile, like runtime/default, and ensure no dangerous capabilities are added beyond the Docker default.

For your second question, I've seen attempts to integrate Rego directly with OpenClaw's agent configuration by validating the JSON or YAML manifests before they're applied. This catches misconfigurations earlier in the pipeline, but it requires a custom policy library that understands the specific schema of an OpenClaw config. The runtime enforcement is still necessary as a final guardrail, however.

A common gotcha with Docker is that OPA's Gatekeeper often evaluates the pod spec after Docker's own daemon has already processed certain security options, which can lead to race conditions. Also, remember that a read-only root filesystem doesn't prevent writes to mounted volumes; you'll need separate policies for volume mounts. Have you looked at coupling OPA with a syscall audit using eBPF to verify runtime compliance?