Cloud agent security: treat every process the agent controls as hostile
How an agent printed our cluster map, what leaked, and the controls and tests we added.
In August 2026, one of our agents printed a map of our Kubernetes cluster. No model-provider key or platform credential was exposed, but the output included internal service names, cluster IPs, an internal model endpoint, a Redis address, a debug MCP address and run identifiers.
The short answer
- Assume the worst: treat every process an agent can influence as attacker-controlled. Keep platform credentials in a trusted broker, and give the sandbox only the smallest capabilities for the current run, enforced outside the model.
- The leak was ambient inheritance: an outdated denylist of environment variables, Kubernetes service-link variables, and a Go
os/execcommand with a nilEnvfield, which inherits the complete parent environment. - Our fix: one allowlist policy for every subprocess, and
enableServiceLinks: falseon agent, workflow and user-service Pods.
Regression tests
| Boundary | Test |
|---|---|
| Process environment | Start every command type and assert canary secrets are absent |
| Empty environment | Launch a plugin with no variables and assert the parent canary is absent |
| Pod defaults | Assert service links, service-account tokens, capabilities and seccomp settings |
| Internal APIs | Probe routes with no token, a malformed token and an expired token |
| Network | Try DNS discovery, metadata access, cross-tenant traffic and a reverse tunnel |
| Lifecycle | Leave a detached process and a canary file, then recycle the environment |
| Observability | Put canary secrets in command output and inspect events, logs and traces |
When the answer changes
- Architecture: the implementation details describe the platform in August 2026, when agents ran in Kubernetes pods. Agents now run in Firecracker microVMs.
- Narrow patch: internal DNS remains discoverable, and the agent can still reach the broker and storage gateway, so those services must authenticate it. User-provided credentials remain readable by code that uses them. An environment-variable allowlist does not replace authentication or network policy.
- Not a penetration test: teams with hostile-code or regulated-data requirements should add an independent assessment.
The full post has the seven controls, the supervisor re-exec pattern and a 12-question review worksheet.