Get a personal AI assistant on Red Hat Developer Sandbox with OpenClaw

OpenClaw is now available on Red Hat Developer Sandbox.

One click, one API key, and you get a personal AI assistant running in your own Red Hat OpenShift project. The AI agent never sees your credentials and can’t escape its network sandbox.

OpenClaw on Developer Sandbox

If you log into sandbox.redhat.com today, you’ll see a new card: OpenClaw. Click it, paste in an LLM API key, and about a minute later you’ll have a working AI assistant. No YAML, no Helm charts, no cluster-admin. The assistant comes pre-configured with access to your workspace project, so you can ask it to deploy apps, debug crashlooping pods, explain your NetworkPolicies, or just use it as a general-purpose coding companion. It runs OpenClaw under the hood, managed by a purpose-built Kubernetes operator we call claw-operator. 

Note: OpenClaw is a heavy token consumer, so we recommend a paid tier for real use. A free Gemini key will get you through the initial setup and a few conversations, but you’ll hit rate limits quickly

Why an OpenClaw AI assistant?

OpenClaw is one of the most impactful and popular open source projects to emerge in the last few years. An autonomous AI agent that can execute tasks via LLMs, it offers the powerful capabilities of having an AI assistant that can provide you scheduled reports, perform tasks on your behalf, and serve as a centralized hub to simplify your workflow  

OpenClaw also fits very well within OpenShift and Red Hat OpenShift AI capabilities. OpenShift provides security, while Open Shift AI provides vLLM (Model-as-a-Service), agents, and observability. This provides all of the capabilities needed to design a feature-rich OpenClaw that can use both frontier and locally served models.

The hard part: security on shared infrastructure

Implementing OpenClaw was less about getting it to run (it’s a Node.js app, it runs anywhere) and more about running it safely on Developer Sandbox, where thousands of users share the same cluster. Each user gets their own namespace, but everything runs on shared infrastructure with shared API servers and shared networking.

The challenges we had to address:

• The AI agent needs Kubernetes API access to be useful. But if it can read secrets in its own namespace, it can grab the LLM API keys, the proxy CA, the gateway token— everything.
• The AI agent needs to call LLM APIs. But if it has direct internet access, a prompt injection could exfiltrate data to an attacker-controlled endpoint.
• Users bring their own API keys. Those keys need to reach the LLM providers, but the AI process itself should never see them in plaintext.
• Namespaces provide isolation between users, but within a namespace there’s no built-in way to isolate the AI agent from its own infrastructure.

OpenShift already gives us a solid foundation here. The restricted Security Context Restraints (SCCs) enforce non-root user IDs, SELinux, and seccomp profiles, and block privilege escalation without us having to configure any of that. But pod-level security isn’t enough when the problem is credential access and network boundaries. We needed application-level isolation on top of what the platform provides.

We ended up with a design where agentic AI is treated as untrusted by default. Here’s what that looks like in practice.

Two namespaces, hard boundary

In the Developer Sandbox environment, the operator deploys OpenClaw into a separate -claw project and only gives the AI access to your -dev workspace:

alice-dev (your workspace)     alice-claw (AI infrastructure)
├── your deployments           ├── OpenClaw gateway
├── your services              ├── Credential proxy
├── your apps                  ├── Secrets (API keys, CA, tokens)
│                              ├── NetworkPolicies
│  AI has: edit access here    │  AI has: zero access here

The OpenClaw AI agent can create deployments and debug pods in -dev all day long. But it physically cannot read the secrets, proxy config, or network policies in -claw because it has no RBAC there. Kubernetes doesn’t let you say “access all secrets except these three,” so we split the namespaces instead.

Note: This experience is unique to the Developer Sandbox. When using the operator on your own cluster or your organization’s cluster the OpenClaw deployment will only have access to what you specifically provide via RBAC. The security implementation may change as the OpenShell project matures.

Credential proxy

Your API keys live in Kubernetes Secrets (this works with External Secrets Operator, Sealed Secrets, Vault, whatever you use). A dedicated proxy sits between OpenClaw and the outside world. The proxy intercepts outbound HTTPS, looks at the destination domain, and injects the right credentials. The gateway itself only ever holds dummy placeholder keys.

NetworkPolicies enforce this: the gateway can talk to the proxy and DNS. That’s it. No direct internet access. Even if someone found a way to make the agent send arbitrary HTTP requests, those requests go through the proxy, which only allows explicitly configured domains.

The proxy is the only way out

Three NetworkPolicies are applied per instance of OpenClaw:

1. Network policy summary for claw instance: INGRESS (who can connect TO claw pods)

2. EGRESS (where claw pods can connect TO): For app=claw pods

3. For app=claw-proxy pods

• Restricted connectivity: Claw pods are limited to the DNS and the claw-proxy on port 8080.
• Gateway isolation: The proxy manages all outbound HTTPS and Kubernetes API requests.
• Ingress control: External traffic is only permitted on port 18789 through OpenShift ingress controllers.
• Secure by default: A comprehensive default-deny stance blocks any other network paths.

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 or reach unauthorized endpoints.

Supported providers

This approach works out of the box with multiple providers, as detailed in the table below.

For the well-known providers, you just provide a key and the operator figures out the domain, auth type, and model catalog. Custom endpoints need a bit more config but work the same way.

What can you do with OpenClaw?

OpenClaw is more than a chatbot: because it has edit access to your workspace namespace, it can actually do things, not just talk about them, whether that’s deploying a Python app, providing insights into why a pod might be failing,” or writing a Dockerfile.

While its “Kube hat” makes it a useful companion for Kubernetes tasks, OpenClaw is a general-purpose AI assistant. You can also use it for code reviews, architectural brainstorming, and writing docs, and learning new tools.

Not sure how to configure a specific feature? Just ask OpenClaw! The assistant is designed to guide you through the process.

Get started in the Developer Sandbox

1. Sign up at developers.redhat.com/developer-sandbox at no cost
2. Grab a free API key from Google AI Studio
3. Click the OpenClaw card on your dashboard

Your free 30-day Developer Sandbox trial idles the assistant after 12 hours of inactivity. Click “provision” on the dashboard to activate the assistant.

Everything is open source

• OpenClaw — the assistant itself
• claw-operator — the operator that deploys and secures it
• Developer Sandbox — the platform running it all

The operator works on any OpenShift cluster, not just Developer Sandbox. If you want the same security model on your own infrastructure, it’s all there.

What we’re working on next

Right now our focus is on two things: hardening security further (there’s no such thing as “secure enough” when you’re running AI workloads on shared infrastructure) and monitoring how the system behaves at scale with real users hitting it daily. One of our first tasks will be integration with OpenShell.

This is also a fresh production deployment, so expect some rough edges. We’re actively watching for issues and fixing them as they come up—if something breaks, it won’t stay broken for long.

If you try it out and hit problems, we want to hear about it. The operator repo is at github.com/codeready-toolchain/claw-operator.

Note: Red Hat’s Emerging Technologies blog includes posts that discuss technologies that are under active development in upstream open source communities and at Red Hat. We believe in sharing early and often the things we’re working on, but we want to note that unless otherwise stated the technologies and how-tos shared here aren’t part of supported products, nor promised to be in the future.