A recurring finding in our recent audits of agent orchestration platforms is the improper propagation of environment variables. While the container model in systems like NanoClaw aims for strong isolation, the orchestrator layer often becomes a weak link. It's not uncommon to see sensitive context—API keys, database connection strings, internal service URLs—leaked to tasks that have no legitimate need for them, simply because they were part of the orchestrator's own environment or a global configuration.

The primary failure modes we've observed are:

* **Orchestrator Inheritance:** The orchestrator process launches child tasks (agent containers) without sanitizing its own process environment. Tools like `os.Environ()` in Go or `os.environ` in Python can inadvertently pass everything along if not explicitly filtered.
* **Misconfigured Container Runtimes:** Using the `--env` flag or equivalent in a blanket manner, perhaps by passing a whole configuration file without scoping variables to specific tasks.
* **Shared Volume Configuration Files:** A task writes its runtime configuration (containing secrets) to a shared volume, and a subsequent task reads it, bypassing the container isolation.

Here is a simplified, high-risk pattern we've encountered in a custom orchestrator written in Python:

```python
import subprocess
import os

def launch_agent_task(agent_image, command):
# This passes the ENTIRE orchestrator's environment to the container.
env = os.environ.copy()
env['TASK_ID'] = generate_id()
subprocess.run(['docker', 'run', '--rm', '--env-file', '/dev/stdin', agent_image, command],
input=format_env_file(env), text=True)
```

The secure approach requires an allow-list, not a deny-list. The orchestrator must explicitly define the minimal set of variables for each task or task class.

```python
def launch_agent_task(agent_image, command, allowed_env_vars):
# allowed_env_vars is a dict of only the variables this specific task needs
env = {k: os.environ[k] for k in allowed_env_vars if k in os.environ}
env['TASK_ID'] = generate_id()
subprocess.run(['docker', 'run', '--rm'] +
[f'--env={k}={v}' for k, v in env.items()] +
[agent_image, command])
```

From a zero-trust perspective, each agent task should be treated as an untrusted principal. The threat model must include the orchestrator as a potential source of credential leakage. Key questions to ask:

* Does your orchestration framework have a mechanism to define scoped environment variables per agent or task type?
* Are you using secrets management (e.g., mounted files, dedicated secrets API) instead of environment variables for sensitive data?
* Do your audit logs capture which environment variable *keys* (not values) were provided to a task container? This is essential for detecting misconfigurations.

The container isolation boundary is only as strong as the process that constructs it. A systematic review of your orchestrator's task spawning logic is necessary to close this gap.