As AI agents take on autonomous tasks, securing them requires robust, infrastructure-enforced boundaries, workload isolation, and policy controls designed to safely govern enterprise operations.
Why is OpenClaw the fastest-growing open source project in GitHub history? It links a familiar, chatbot-style interface to a powerful, autonomous AI system that independently completes tasks for you. In simple terms, OpenClaw is an agent harness: it provides a software infrastructure that wraps around a model to create a self-managing AI agent. Its gateway connects models, tools, skills, messaging channels, and user interfaces while keeping the system under the operator’s control.
Until now, OpenClaw adoption has been driven largely by developer demand for a locally operating AI agent, but enterprise demand has quickly followed. Running agents in the enterprise requires an architecture designed for isolation, identity, data retention, governance, and security. My team at Red Hat is exploring how agentic platforms can meet these requirements, and in March 2026, I became an OpenClaw maintainer. Working on OpenClaw gives us the opportunity to solve agentic AI challenges for enterprise across the entire stack, from the application to the underlying platform.
OpenClaw’s open source origins are also key to its adoptability. It didn’t emerge from a funded startup or a corporate product plan. Instead, Austrian developer Peter Steinberger built it as a personal project in November 2025 because he wanted an AI assistant that could work across communication channels, remember context, connect to tools, and do useful work. By early March 2026, it was GitHub’s most-starred software repository. The project now describes itself as an extensible, proactive, open source AI agent that works everywhere you work, developed by the OpenClaw Foundation and its community. It is maintained by a full-time foundation team and core maintainers from organizations including NVIDIA, Atlassian, OpenAI, Hugging Face, Microsoft, and Red Hat, and a large contributor community.
From a useful agent to an operable service
Enterprise software is often described in terms of scale: more users, more traffic, more clusters. For agents, scale is only part of the problem. In our recent open blueprint for cloud-native AI agents, we described agents as a new workload class: the model, agent harness, and sandbox runtime have separate lifecycles and security requirements. A persistent agent holds state, invokes tools, handles untrusted content, and may act on a person’s behalf. It therefore needs workload identity, controlled model access, policy, observability, and lifecycle management.
OpenClaw supports a broad range of model and inference providers. Operators can use a hosted service or self-host open weight models. Red Hat AI Inference brings a supported, vLLM-based inference stack to OpenShift AI, while OpenShift supplies the Kubernetes operations, scaling, access controls, and monitoring needed to run it as an enterprise service. With models, storage, and tools kept internal and external egress denied by default, inference and sensitive context can remain inside a disconnected or tightly isolated network. Observability, credential management, and the software supply chain must also be governed. Taken together, these requirements make enterprise agents a platform concern rather than something each agent application should be expected to solve alone.
This flexibility supports multiple deployment shapes. Teams may run agents in isolated Kubernetes namespaces with role-based access control, network and admission policy, and per-workload identities. When a stronger operating-system boundary or compatibility with existing software is needed, OpenClaw can run in a virtual machine (VM) alongside containers. VMs can separate the reasoning agent from deterministic integration services. OpenShift Virtualization makes the VM boundary a platform choice rather than a separate infrastructure silo.
OpenShell as the runtime boundary
In our work, OpenShell is the sandbox runtime we rely on wherever OpenClaw runs. OpenClaw supplies the assistant, gateway, skills, channels, and user experience; OpenShell supplies an infrastructure-enforced boundary around agent execution. This separation lets us evolve the agent without asking the agent to enforce its own limits.
NVIDIA OpenShell is an Apache-licensed open source runtime built specifically for autonomous agents. Its architecture separates a gateway control plane from a supervisor that runs with each sandbox. The supervisor launches the agent as a restricted child process and enforces declarative YAML policy where process identity, filesystem access, network egress, and runtime credentials are visible. Policies can constrain which paths an agent reads or writes, which processes it launches, which network destinations and HTTP operations it reaches, and how inference traffic is routed. OpenShell builds on familiar Linux isolation primitives, then adds policy controls tailored to agent behavior.
OpenShell also gives us a common abstraction across environments. Its compute integration points support local container runtimes, virtualization, and Kubernetes. The underlying isolation mechanisms differ, and their guarantees still need to be tested on each platform, but the policy intent can remain consistent. The same OpenClaw workload that a developer exercises locally can therefore move into an OpenShift VM or a Kubernetes-backed sandbox without abandoning the runtime model used during development.
This work is also an example of open source collaboration at the infrastructure layer. NVIDIA leads the OpenShell project, while Red Hat is contributing upstream and integrating the runtime with Red Hat AI. Red Hat and NVIDIA have described the collaboration as a way to connect agents to sandboxing, policy, and gateway controls. Other companies and individual contributors are testing the same runtime against different agents and platforms. OpenShell remains alpha software, and some deployment paths are still developing. With open collaboration, security properties, platform gaps, and operational requirements can be worked through together instead of being rediscovered in private wrappers around every agent.
OpenClaw itself distinguishes where tools execute from which tools policy permits. OpenClaw can decide which tools a session may use, while OpenShell constrains the environment in which those tools run. OpenClaw’s sandboxing documentation is appropriately direct that sandboxing reduces blast radius rather than creating a perfect security boundary. Enterprise systems should be designed with this in mind. The resulting pattern is portable. OpenClaw can run on a developer’s machine, in a container, in a VM, or as part of a managed Kubernetes environment. The important point is that isolation is an explicit decision based on the workload, its data, its tools, and the consequences of failure.
What the agent runtime boundary makes possible
We can consider several motivating use-cases. Imagine, for example, an assistant that can gather a daily briefing from email, Slack, meeting notes; identify what needs attention; and propose responses. We’ve all felt the pain of context sprawl across various channels and platforms. The value of OpenClaw is its ability to connect context across systems and turn it into reviewable next steps.
OpenClaw skills allow a team to encode how work should be done rather than rely on a long prompt that changes from conversation to conversation.
The same foundation can support incident summaries for a CISO. It can help drive research across various data sources or act as an assistant to handle customer follow-up for a sales representative. A team agent can manage software maintenance, from issue triage to release. OpenClaw skills are especially useful here: a skill packages instructions, references, and supporting tools into a reusable unit, allowing a team to encode how work should be done rather than rely on a long prompt that changes from conversation to conversation.
That extensibility creates a supply-chain question of its own: who wrote a skill, what can it reach, what does it instruct the agent to do, and how was it reviewed? OpenClaw is already developing useful answers. Through its skill-security collaboration with NVIDIA, every skill published to ClawHub passes a verification pipeline combining static analysis, VirusTotal, NVIDIA SkillSpector, and ClawScan, and ships with a Skill Card documenting its provenance and capabilities. In an enterprise setting, inspecting a skill should become as familiar as reviewing a package manifest or container image: capability should be visible before it is enabled, and installation policy should fail closed.
Agent security starts outside the model
Persistent agent security cannot depend on asking the model to behave. Models are probabilistic; their infrastructure can be deterministic. OpenClaw controls which tools are available; OpenShell adds an external enforcement boundary with default-deny networking and explicit filesystem, process, endpoint, and request policy. Together, capability can be granted deliberately instead of inherited accidentally.
We began with a few first principles.
- First, a provider credential should not enter the agent workload unless that workload must use it directly. Credentials should instead remain with narrowly scoped services that expose only the operations the agent is authorized to request.
- Second, the agent should communicate with an enumerated set of destinations, not an open network. Model and tool traffic should pass through governed services or gateways where authentication, rate limits, policy, and guardrails can be applied consistently.
- Third, the controls that constrain an agent should live outside the agent’s reach. A prompt cannot negotiate with a network policy, rewrite a supervisor it cannot access, or persuade a read-only service to send mail. We enforce this boundary through isolated namespaces, sandboxes, VMs, network policies, and narrowly scoped deterministic services.
- Finally, consequential actions should require human approval. An agent can gather information, prepare a response, or recommend an action, but a person should decide whether it is carried out.
These principles also shape how we think about prompt injection. Email, Slack messages, documents, and web pages are all untrusted input. Input and output guardrails can help detect attacks, but classifiers shouldn’t be the only barrier between a malicious instruction and agent action. Agents should lack the credentials, tools, network access, or approvals needed to act beyond their assigned roles.
There is no single security layer: what’s needed is defense-in-depth. A sandbox limits local impact. Network policy limits destinations. Scoped credentials limit provider authority; narrow services can further restrict a broader credential. Human approval controls consequential writes. Observability and reproducible artifacts make the system diagnosable and reviewable.
OpenClaw offers extensive safety and security configuration, while its default experience is optimized for a trusted single operator. Enterprise readiness comes from configuring those capabilities deliberately and reinforcing them with platform-level controls.
Open source is the accelerator
Open source made this exploration possible. The OpenClaw Foundation, of which Red Hat is a sponsor, adds the value of continuity. It is an independent 501(c)(3) nonprofit whose stated purpose is to keep the project open, neutral, and community-driven, with no single company controlling its direction. With open source, we build on software we can continue to inspect, pin, maintain, or fork if necessary. The foundation provides a neutral home for full-time maintainers, community contributors, and companies that might otherwise be competitors to collaborate on shared agent infrastructure. That governance is part of our technical foundation: we can confidently design around OpenClaw’s extension points without making the viability of our architecture depend on one vendor continuing to offer the same proprietary product under the same terms.
This collaborative feedback loop is already visible in OpenClaw. The project’s security guidance, sandbox backends, skill verification, installation policies, and operator tooling continue to evolve in public. Users are not limited to consuming features; they can help define the responsible patterns around them. As a recent RHRQ conversation on security, agentic AI, and open source emphasized, this is still a young field. Open communities give us a way to discover the right abstractions together.
Building better boundaries
The next stage is not simply to give agents more tools. It is to make authority legible: which person or workload an agent represents, which data it may use, which actions require approval, and what evidence remains afterward. Our current work is focused on workload identity, short-lived credentials, skill provenance, policy-aware gateways, prompt-injection defenses, human-in-the-loop interfaces, and lifecycle management across fleets of agents.
The project exposes enough of the agent stack for a broader community to build the boundaries around it.
OpenClaw began as one person building the assistant he wanted. Its value to the enterprise is that the project exposes enough of the agent stack for a broader community to build the boundaries around it. Without a shared foundation, teams will repeatedly recreate the same agent loop, gateway, tool integrations, and state management. Those common mechanics are not where organizations need to differentiate. The real opportunity lies in what we build on top.
As an OpenClaw maintainer, I encourage you to try it. Read its security model. Run it inside the isolation boundary appropriate to your use case. Inspect a skill before enabling it. Test what your agent is forbidden to do, not only what it can do. Contribute the missing endpoint, policy hook, documentation, or negative test upstream.
No single model or company can solve the challenges of scaling agents safely. The future of agents will be built through open systems that people can inspect, challenge, improve, and trust for reasons they can verify.