Red Hat launched OpenClaw agent runtime support on its Developer Sandbox platform on July 21. The integration treats autonomous agents as untrusted by default, deploying them with network isolation that assumes full container compromise.
One Click, Two Namespaces
The setup is minimal: log into sandbox.redhat.com, click the OpenClaw card, paste an LLM API key, wait about a minute. No YAML, no Helm charts, no cluster-admin privileges. But beneath that simplicity is a security architecture designed for shared infrastructure where thousands of users occupy the same cluster.
According to Red Hat engineers Alexey Kazakov and Ryan Cook in the announcement, the operator deploys OpenClaw into a separate -claw namespace and gives the AI agent edit access only to the user’s -dev workspace. The agent can create deployments and debug pods in the development namespace. It cannot read secrets, proxy configurations, or network policies in its own infrastructure namespace because it has zero RBAC there.
“Kubernetes doesn’t let you say ‘access all secrets except these three,’ so we split the namespaces instead,” Kazakov and Cook wrote.
The Proxy Is the Only Way Out
The most significant architectural decision: the agent has no direct internet access. Three NetworkPolicies enforce this constraint. The OpenClaw gateway pod can reach exactly two destinations: the credential proxy on port 8080 and DNS. Nothing else. All outbound HTTPS flows through the proxy, which intercepts requests, checks the destination domain against an allowlist, and injects the appropriate API credentials. The gateway itself holds only placeholder keys.
“This threat model accounts for full container compromise; because there is no network path to the outside world, an attacker has no way to exfiltrate credentials,” according to the technical writeup.
Credential Separation
Users bring their own LLM API keys, which are stored in Kubernetes Secrets within the infrastructure namespace. The proxy reads those secrets and injects credentials into outbound requests. The OpenClaw process never sees the keys in plaintext. Even a prompt injection that causes the agent to make arbitrary HTTP requests would route those requests through the proxy, which only permits explicitly configured domains.
The architecture works with External Secrets Operator, Sealed Secrets, and HashiCorp Vault, according to the writeup.
Enterprise Agent Hosting as Competitive Surface
Red Hat’s launch adds to a growing list of cloud vendors positioning agent hosting security as a differentiator. AWS Lambda added one-click agent setup earlier this month. Google’s Gemini Enterprise Agent Platform enforces cryptographic agent identity at the hardware layer. The pattern is consistent: the competitive surface for agent hosting is shifting from model performance to containment guarantees.
Red Hat’s approach is distinctive in one respect: it publishes the full security architecture, including exact NetworkPolicy configurations and RBAC boundaries. The claw-operator that manages the deployment is open source. Teams evaluating agent hosting can inspect every isolation boundary rather than trusting marketing claims about security posture.