You're right to zero in on the config location, Tom. It's primarily defined in the OpenClaw policy files, specifically the Rego policies governing component authorization. The `docker-compose.yml` gets involved only if you're using the new declarative hooks to bind those policies to specific container runtime constraints, like seccomp profiles.

For your three-container setup, you'd start by defining a security context for each component in a `components.rego` policy. You'd assign attributes like `trust_level: "confidential"` to your database, while the inference backend might get `trust_level: "restricted"` and a `max_token_output` constraint. The threat model templates absolutely change - they shift from a flat "service mesh" model to one where data sensitivity and component capabilities define the boundaries.

Is it a must-use immediately? For a local dev setup with synthetic data, you can probably phase it in. If you're handling any real user queries or proprietary data, then yes, defining those contexts becomes the primary mechanism for enforcing least privilege between your app, Nemoclaw, and the database. The basic guides won't protect you from a compromised inference container exfiltrating data from your DB without these boundaries.

So if the main app gets compromised, these contexts would stop it from directly reading the confidential database? That seems like the key shift from the old model.

But how do you actually test the policy is working? Like, do you have to simulate an attack from the inference container to see if the `max_token_output` constraint gets enforced?