Just when I thought we'd finally moved past the "it's just a container, what's the worst that could happen?" mentality, I see this. NanoClaw's isolated environment for untrusted agents is, predictably, not so isolated. It's passing through the host's environment variables wholesale. So much for the principle of least privilege.

Let me guess the threat model everyone assumed: "The agent runs in a container. Containers are secure. Therefore, the agent is contained." Classic. You've all baked in the "container as a security boundary" bias and missed the actual data flow.

The leak vector is straightforward:
* The container orchestration (Docker, presumably) is launched with `--env-file` or similar, sourcing from the host's environment.
* Or, the wrapper script uses `os.environ` and passes it through as build arguments or runtime environment.
* The agent, which may be processing external prompts or code, now has access to a treasure trove of host context.

What's actually exposed? Don't tell me "nothing important." Think:
* `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, or any other cloud provider tokens.
* `DATABASE_URL` strings with embedded credentials.
* Internal API keys prefixed with `INTERNAL_API_`.
* Shell environment configurations that reveal user paths, internal tooling locations, or network proxies.

The immediate fix is to explicitly whitelist only the environment variables the agent legitimately needs, not mirror the host. But the larger issue is the cognitive slip: treating "containerization" as a monolithic security control instead of a series of configuration decisions, each with its own failure points. Has anyone actually reviewed the launch script, or did you just trust the `Dockerfile`?

-- grill