What is OpenClaw Enterprise? An architecture for agents at work

OpenClaw Enterprise (OCE) is an open-source, vendor-neutral platform for configuring, deploying and operating persistent agents on infrastructure you control. It provides a common control plane for managing multiple agent instances across teams.

At RAW Labs, we’re building on OpenClaw and OCE, with business integrations, deployment, maintenance and support.

This article introduces OCE’s architecture for enterprise architects, security teams and engineers evaluating agent deployments. It explains how the platform manages agent instances and how identity, credentials and execution isolation fit together.

OpenClaw Enterprise began at OpenAI and was donated to the OpenClaw Foundation, where it continues as an independent project developed in collaboration with Red Hat, NVIDIA and other contributors. Its launch announcement described internal pilots at OpenAI and Red Hat, including OpenAI agents working with codebases and plugins. Project origins

Scope: This article describes OCE’s architecture as of 22 October 2026, including its design for workload-identity exchange. That exchange remains planned; dedicated native OpenClaw and OpenShell-based credential mediation are experimental paths. Deployment support depends on the selected release and integration. Architecture and scope

A common operating model for many agents

In OCE, each agent represents a managed OpenClaw instance with its own identity, configuration, credential bindings and execution environment. OCE organizes these resources, controls who can use or change them, and manages the agent’s deployment lifecycle. Its architecture separates the authority to configure and deploy an agent from the environment in which that agent calls models and executes tools.

An organization running multiple agents needs consistent ways to assign ownership, grant access, deploy configuration and retain an operational record. These responsibilities recur even when the agents use different models, tools or business systems.

OCE gives them a shared management layer. Platform operators select the infrastructure integrations and establish the installation’s trust boundaries. Authorized users manage agents and resources within their assigned scope. Each agent runs with its own identity and explicitly assigned access.

This division allows deployment and security policy to be managed centrally while individual agents retain their own configuration, workspace and lifecycle. Access to connected applications is also governed by the accounts and permissions those applications provide.

Installation, Namespaces and Agents

OCE organizes its resources in a hierarchy. An Installation represents one deployment of the platform. It contains Namespaces, each of which groups agents and resources within a tenant scope. Every Agent belongs to one Namespace.

Resource	Architectural role
Installation	The platform deployment and its operator-selected infrastructure integrations.
Namespace	The ownership and access scope for a set of agents and resources.
Agent	A managed OpenClaw instance with its own identity, configuration and deployment history.
Configuration	Reusable OpenClaw settings belonging to a Namespace.
Secret	A credential stored separately from configuration and referenced by authorized consumers.
AgentRevision	An immutable snapshot of the configuration and execution settings admitted for a deployment.

A Namespace contains the configuration, credentials and agents that can be managed within that scope. Resource references stay within the Namespace, and permissions determine which individual resources a caller may read, change or use. A shared Namespace therefore supports resource reuse through explicit grants. Namespace model

Each deployed Agent has its own gateway and revision history. The control plane manages those runtimes individually: changing or retiring one Agent leaves the others under their own resource ownership and lifecycle.

The Compute Driver maps this resource model to infrastructure. In the single-cluster Kubernetes topology, a tenant’s Agent workloads occupy a Kubernetes namespace. OpenClaw Control Plane (OCC) enforces ownership and authorization for platform resources; Kubernetes supplies workload identities, storage and network controls. Platform architecture

Control plane and agent execution

OCC owns configuration, authorization and resource lifecycles. Its API serves users, automation and the management console. A controller worker carries out deployment operations, with PostgreSQL retaining platform state, queued work and audit evidence.

Agent operation involves message handling, model inference and tool execution. Dedicated execution separates these responsibilities between two components:

• The Agent gateway manages client and channel connections and routes messages for its Agent.
• The Harness calls the model, executes tools and works with the Agent’s files.

The following diagram shows the management relationships and runtime communication in dedicated Kubernetes execution.

flowchart TB
    U[People and authorized automation] --> API[OCC API and console]
    subgraph CP[Control plane]
        API --> IAM[Resource authorization]
        API --> DB[(PostgreSQL: state, work and audit)]
        DB --> W[Controller worker]
        W --> IAM
        W --> D[Installation-selected Drivers]
    end
    subgraph T[Tenant namespace: dedicated execution]
        G[Agent gateway: connections and messages]
        H["Harness (OpenClaw or Codex): model calls and tools"]
        G <--> H
    end
    D -->|Provision and reconcile| G
    D -->|Provision and reconcile| H
    H --> M[Configured model service]

The gateway and Harness have separate responsibilities and execution environments. In Kubernetes, dedicated execution separates their Pods, ServiceAccounts and storage. This lets infrastructure policy govern their privileges and access independently. Harness architecture

The gateway retains its channel credentials and admitted gateway configuration. The Harness has its working files and model access. File operations between them are scoped to the Agent; the gateway accesses the remote workspace without mounting its storage. OCC retains authority over deployment configuration and the active revision. Gateway and Harness ownership

This separation is important because model-directed tool execution can create processes, modify files and make network requests. Its authority should be limited to the resources assigned to the Agent, while the configuration and credentials used to manage the platform remain under operator control. Dedicated native OpenClaw uses a provisioning SandboxDriver for network, filesystem and process containment; dedicated Codex can also run within a selected Sandbox.

Drivers connect the platform to infrastructure

Drivers implement the operations OCC needs from its environment. Compute provisions and manages runtimes. IAM evaluates resource authorization. Configuration and Secret Drivers manage their backing stores. A SandboxDriver applies execution containment, and a Credential Gateway can mediate access to upstream credentials.

The installation operator selects these trusted integrations. Agent configuration is interpreted within those choices. This gives OCE a consistent resource and lifecycle model while allowing infrastructure implementations to vary. Driver architecture

Identity and authorization

OCE distinguishes the identity of a person managing the platform from the identity of an agent operating within it. A human has a Principal; an Agent has its own stable ServicePrincipal. The Agent’s permissions are assigned independently of the person who creates or deploys it.

Authentication identifies the caller. Authorization determines whether that caller may perform a particular action on a particular resource. Roles collect permissions, and AccessBindings assign those Roles within an Installation, Namespace or individual resource. Matching deny Restrictions narrow the resulting access.

These controls distinguish the authority to inspect an Agent, edit its definition, deploy a revision or administer it. Permission to use a referenced resource, including a Secret, is checked separately. Authorization model

Workload identity and short-lived tokens

The workload-identity design connects the Agent’s platform identity to the software running on its behalf. Kubernetes provides local identity evidence through a short-lived ServiceAccount token issued for an intended audience. Verification establishes the issuing cluster and the workload identity represented by the token.

The exchange design uses that evidence to obtain a short-lived credential scoped to the Agent ServicePrincipal and revision. Gateway and Harness authenticate independently, so components placed in different infrastructure trust domains can each present their own identity evidence.

The purpose is to bind a runtime request to a known Agent and deployment, then evaluate that identity’s permissions. The Agent keeps a stable platform identity as its runtime is replaced, while workload credentials can be limited in scope and lifetime. Workload identity design

Credentials and mediated access

Credential handling has three separate responsibilities: storing the secret, authorizing its use and delivering authentication to the component that needs it.

OCE stores Secrets separately from configuration. Agent definitions and deployment revisions retain references to those Secrets. Binding a Secret requires authority to use that specific resource, in addition to the permission to change the Agent or Configuration. Deployment checks the access of both the deployer and the consuming Agent. Credential bindings

With direct delivery, infrastructure supplies the selected credential to its consumer. In dedicated execution, model credentials go to the Harness, while channel credentials remain with the gateway. The separation limits credential distribution according to each component’s role. Credential ownership

Credential substitution at the outbound proxy

Credential mediation moves upstream authentication outside the Harness. The Credential Gateway holds the real credential, and the Harness receives a placeholder in the environment variable its software uses for authentication.

When the Harness sends a request, the OpenShell supervisor proxy applies the credential policy. For a request matching the permitted executable, destination and path, it replaces the placeholder with the real credential. The external service receives an authenticated request, while the Harness retains the placeholder. OpenShell Credential Gateway

This keeps the upstream key out of the Harness’s environment and local credential files. Credential access is enforced by the trusted proxy and sandbox network boundary. Confirmed withdrawal of the provider attachment stops its placeholders from resolving, including for a running workload.

The workload-identity design and credential mediation serve complementary purposes. Workload identity identifies the Agent requesting access; credential mediation applies an upstream secret under infrastructure policy. An agent can therefore be given access to a service without being entrusted with the service’s reusable credential. Credential Gateway architecture

Deployment and configuration history

An Agent definition describes the workload to run. Deployment creates an immutable AgentRevision containing the admitted configuration, execution settings and credential references. Subsequent edits require a new deployment, preserving the distinction between editable configuration and the revision running in the environment.

Before deployment, the control plane verifies the deployer’s permissions, the Agent’s identity and both parties’ access to the required credentials. It records the admitted state, audit evidence and queued work in one database transaction. A controller worker then provisions the runtime and reconciles its state with that deployment record.

Because deployment is asynchronous, the worker checks current authorization before making infrastructure changes. Revoking a required grant can therefore block work that was previously admitted. The controller records lifecycle results under the current work ownership, allowing interrupted operations to be recovered without a stale worker overwriting newer platform state. Deployment lifecycle

The database transaction and infrastructure operations have separate failure boundaries. Reconciliation tracks the outcome of external operations and records the selected active revision. The immutable revision provides a configuration history; availability during replacement and recovery depend on the execution topology and deployment procedure. Reconciliation architecture

Credential revocation has its own lifecycle. With direct delivery, a credential already supplied to a process may require revocation at its issuer and workload shutdown or replacement. With mediated delivery, the proxy controls continued use of the upstream credential. Configuration history and credential lifecycle must therefore be managed together.

Runtime isolation and trust boundaries

OCE’s security architecture combines resource authorization with containment of execution. Authorization controls access to platform resources. Runtime controls bound the files, processes, credentials and network destinations available to the Harness.

For workloads managed directly by Kubernetes Compute, the hardening baseline includes non-root execution, dropped Linux capabilities, restricted privilege escalation, read-only root filesystems, seccomp and resource limits. A provider-managed Sandbox supplies its own containment under the selected Driver contract. The cluster enforces the associated admission and networking policy. Runtime security

Network isolation begins with default-deny rules and explicit exceptions for required communication, including gateway access, runtime communication and external services. The effective boundary is determined by those exceptions and the infrastructure that enforces them. Model endpoints, tools and telemetry destinations all form part of the Agent’s permitted reach. Network architecture

Runtime placement also determines which infrastructure is trusted. Dedicated gateway and Harness workloads can be placed on separate node pools. The architecture additionally describes placement across separate cluster trust domains. Placement policy must preserve the Agent’s ownership, identity and routing relationships across those boundaries. Runtime placement

Infrastructure administrators remain privileged. An administrator able to change workload specifications can alter what credentials a workload receives or what storage it mounts. Controller identities, namespace administration and workload admission therefore belong inside the deployment’s trusted computing base. Separating Pods and credentials limits ordinary runtime access; administrative authority must be governed separately.

Audit and operational accountability

OCC retains audit evidence for platform bootstrap, resource changes, authorization denials and deployment lifecycle events. Records associate an actor, action, affected resource and outcome, with request and deployment correlation where available. Required mutation audit evidence is committed with the corresponding state change.

This record connects configuration history to the people and identities responsible for platform operations. Operational logs support runtime diagnosis. Recording the Agent’s prompts, responses and tool activity requires appropriate Harness instrumentation and application records, with access and retention policies for that content. Audit architecture

How the boundaries fit together

An Agent’s effective authority is the combination of its platform permissions, runtime privileges, available credentials and access granted by connected systems. Each layer has a distinct owner: OCC governs platform resources; the infrastructure confines execution; credential services govern authentication material; and destination applications enforce their own access rules.

Self-hosting gives the organization control over platform placement. Data flows also depend on the selected model providers, tools and telemetry services. Residency and retention requirements must cover those destinations as well as the infrastructure running OCE.

OpenClaw provides the extensible agent foundation. The OpenClaw Enterprise team’s architecture brings instance management, tenant ownership, deployment history and security controls into a common operating model. It gives organizations a shared way to manage agents while assigning each one the resources and authority its work requires.