OpenClaw Enterprise Security: A Guide to Its Boundaries

OpenClaw Enterprise (OCE) documents several distinct security boundaries, and its documentation does not add them up to a single "secure" label. It treats authentication, authorization, the platform Namespace, the Kubernetes namespace, compute isolation, an optional sandbox, credential consumer paths and an audit record as separate layers. Each has a stated job and a stated limit. This article maps those jobs and limits, so a reviewer can see which layer owns which control and which questions fall to the operating team.

The map matters because vendor language and documented mechanisms are different kinds of statements. OpenClaw's announcement lists design goals that include multi-tenancy, "hard security boundaries," sandboxing, fine-grained permissions, governance and auditability. Those are goals and descriptions. The reference pages behind them explain what each mechanism does and, usefully, what it does not do.

Key Takeaways >- OCE's documentation treats identity, permission, tenancy, runtime isolation, credentials and logging as separate layers. A strength in one does not stand in for another.- Authentication establishes who a caller is. The authorization reference says an authenticated principal is not automatically authorized.- A platform Namespace is not a Kubernetes namespace. The optional sandbox does not replace compute isolation, workload IAM or credential isolation.- The audit record is narrow by design. It is not a general log of successful reads, prompts or model responses. Runtime log views and downloads are recorded before output is returned, while status reads are not. The current audit guide says OCC has no console view or public HTTP API to browse or export events, and configurable retention and export integrations are not implemented. Investigators must use the organization’s approved database access procedure. This makes database ownership, access, backup and retention part of the operating plan, not a feature to assume the product supplies.- Everything here is documented behavior. Documented is not observed, and observed is not independently assessed.

The evidence status of this article

This article is documentation analysis. It reads OpenClaw's public documentation as retrieved on October 1, 2026, and nothing else. Rise Productive has not deployed OCE, run an agent on it, penetration-tested it, audited it or independently verified any claim about it.

Two further facts shape how to read the rest. First, the source review found no independent security audit of OCE. Second, OCE is pre-1.0. The announcement says organizations can use it for internal pilot workloads, and it describes a 1.0 release planned for later in 2026. A plan is not a guarantee, and a pre-1.0 label tells a reviewer to expect the documented behavior to change.

Every product statement below is attributed to the document that makes it. Where the article offers reasoning, general security practice or a suggested test, it says so.

Two distinctions to fix before reading the map

Two distinctions carry most of the weight, and the documentation draws both of them itself.

The first is authentication versus authorization. The authorization reference says a user session or service API key establishes identity, and the selected IAM Driver then separately checks whether that principal may perform the operation. In the reference's words: "An authenticated principal is not automatically authorized."

The second is the platform Namespace versus the Kubernetes namespace. The Namespaces reference describes a Namespace as an isolated environment for a team, tenant or workload. That is an OCE concept. A Kubernetes namespace is a cluster object. The reference keeps the two apart. For example, bootstrap creates a platform Namespace named default, and that name does not select Kubernetes' built-in default namespace.

This article keeps the usage consistent. "Namespace" with a capital N always means the OCE platform concept, and "Kubernetes namespace" always means the cluster object.

Each layer at a glance

The table summarizes each layer's documented job, what the documentation says it does not do, and where the remaining responsibility sits. It is a map of ownership, not a test plan.

• Authentication: Documented job: A session or service API key establishes identity; What the docs say it does not do, or leave elsewhere: Does not grant access. Email addresses, display names and caller-supplied identity headers confer nothing; Where the remaining responsibility sits: The selected IAM Driver, plus whoever manages identity issuers and keys
• Authorization (IAM): Documented job: Checks each operation against its exact action, resource and Namespace. Denies without a matching grant; What the docs say it does not do, or leave elsewhere: Never accesses credentials. Revocation cannot retract bytes already delivered. IAM changes do not stop the Agent or revoke upstream credentials; Where the remaining responsibility sits: Operators who stop Agents and revoke upstream credentials when containment is urgent
• Platform Namespace: Documented job: Isolated environment that owns its Agents, service accounts, identities and access rules; What the docs say it does not do, or leave elsewhere: Is not a Kubernetes namespace. Bootstrap success does not imply infrastructure readiness; Where the remaining responsibility sits: Operators who provision and monitor the underlying infrastructure
• Kubernetes namespace: Documented job: With the Kubernetes Compute Driver, holds each Agent's gateway Deployment, ClusterIP Service and ServiceAccount; What the docs say it does not do, or leave elsewhere: For an operator-prepared namespace, restricted Pod Security labels and tenant-local RoleBindings must already be in place; Where the remaining responsibility sits: Cluster operators
• Compute isolation: Documented job: The Compute Driver owns baseline isolation, Agent identity, gateway and routing; What the docs say it does not do, or leave elsewhere: The development default uses a Docker network per Namespace and does not enable the Kubernetes driver automatically; Where the remaining responsibility sits: Whoever selects and configures the driver
• Optional sandbox: Documented job: Adds network, filesystem or process restrictions to the Harness; What the docs say it does not do, or leave elsewhere: No per-tool authorization, and no guarantee that every command is approved. Does not replace Namespace network controls, workload IAM or credential isolation; Where the remaining responsibility sits: The Installation operator who selects it, plus the team that defines tool policy
• Credential consumer paths: Documented job: IAM grants decide which identity may use an exact Secret. The docs' example grants operate on one model Secret to an Agent's ServicePrincipal; What the docs say it does not do, or leave elsewhere: IAM never accesses credentials and does not revoke upstream ones; Where the remaining responsibility sits: Credential owners named in the production handoff
• Audit record: Documented job: Records bootstrap, successful changes, authorization denials, lifecycle completion and runtime log views; What the docs say it does not do, or leave elsewhere: Not a log of all reads, prompts or model responses. No console or public API to browse or export it; Where the remaining responsibility sits: The platform operator and the organization's database access procedure

View image detail

OpenClaw Enterprise control boundaries include identity, authorization, Namespace, compute, sandbox, credentials and audit.

Actual size

Choose Actual size to read the graphic closely.

Each boundary has a separate job and an owner.

Authentication tells you who; authorization decides what

Authentication answers who is calling. Authorization answers whether that caller may do one specific thing. The authorization reference keeps the two apart and returns different status codes for each failure:

• 401 when the session or key is missing, invalid, expired or revoked.
• 403 when the principal lacks the exact grant, belongs to another Namespace or matches a deny Restriction.

Two kinds of principal

The reference describes two principal types:

• A Principal is a human, identified by a trusted issuer and an immutable subject.
• A ServicePrincipal is automation, scoped either to the Installation or to one Namespace.

Each Agent owns exactly one immutable, Namespace-scoped ServicePrincipal. The reference says ordinary service API keys are deliberately unavailable to Agent-owned principals. It also says unknown identities are denied. Email addresses, display names, caller-supplied identity headers and membership in another Namespace do not grant access.

The broad bootstrap grants

A fresh native-IAM bootstrap provisions two identities: a human administrator and one Installation-scoped, non-Agent ServicePrincipal. According to the reference, both are bound to the same administrator Role with no Namespace or resource filter, so their grants cover existing and future Namespaces. The docs say these grants "confer no Kubernetes or provider authority."

Here is Rise's reading of what follows from that. Inside OCE's own authorization model the grants are broad, so both identities deserve high-value handling. The reference also says removing the original human account does not remove the service identity. A reviewer who assumes that offboarding the founding administrator closes the door has missed the second identity.

Denial is explicit, not implied

A Restriction narrows permissions. The reference says a matching Restriction overrides both direct grants and Group grants, and that a Restriction never grants access. It also says deleting a binding does not establish effective denial, because other bindings or Restrictions may still apply. When something must be denied, look for an explicit Restriction. Don't assume a removed binding did the job.

Lists are authorized per resource. Permission to deploy an Agent does not automatically include permission to read it, and reading one Agent does not expose every Agent in the Namespace. Ordinary resource access does not authorize delegation either. The reference says managing Namespace policy requires Installation administer plus read on that exact Namespace.

What happens when IAM is unavailable

The reference says an unavailable IAM Driver, invalid policy, missing grant, mismatched scope or ambiguous identity all fail closed. When the IAM or audit dependency is unavailable, the API returns 503 DEPENDENCY_UNAVAILABLE, and no fallback authorization provider is used. Failing closed is a documented design choice. Whether a deployed system behaves that way during a real outage is a separate question that only a test can answer.

View image detail

Authentication establishes identity while authorization checks permission for a specific action.

Actual size

Choose Actual size to read the graphic closely.

An authenticated identity still needs an authorization grant.

A platform Namespace partitions OCE resources, not the whole cluster

The Namespace is OCE's unit of tenancy. The Namespaces reference says a Namespace owns its Agents, service accounts, their identities and access rules. It says resources in one Namespace cannot be discovered, changed or used from another. Each Agent belongs to exactly one Namespace, and a different Namespace cannot use that Agent's ID to bypass authorization or ownership checks.

That is a platform-level boundary on who may see and act on OCE resources. By itself, it does not describe what the underlying infrastructure does.

Where the Kubernetes namespace enters

The compute layer decides what stands behind a Namespace. According to the reference, the default PostgreSQL-backed development Compute Driver creates one Docker network per Namespace. An explicitly selected Kubernetes Compute Driver instead provisions real tenant infrastructure in a Kubernetes namespace. That can be one the driver creates or an existing one the operator has prepared.

With the Kubernetes Compute Driver, the reference describes one isolated Kubernetes namespace per Namespace. Each deployed Agent gets one gateway Deployment, one ClusterIP Service and one ServiceAccount. The default development server and worker do not enable the Kubernetes driver automatically. So when a reviewer reads "isolated environment," the first question is which driver produced the isolation in front of them.

The existingNamespace option needs particular care. The reference says it requires Installation administer. It also says the operator-prepared Kubernetes namespace must already have restricted Pod Security labels and tenant-local RoleBindings in place. That cluster-side preparation is the operator's work.

Lifecycle states are not security states

A Namespace's status is provisioning, ready, failed or deleting. The reference says "Bootstrap success does not imply infrastructure readiness." If no eligible controller worker is running against the same PostgreSQL database, lifecycle work stays queued. Deploying an Agent requires the Namespace to be ready.

Deletion follows two documented rules:

• Deleting a tenant preserves a discovered, operator-owned Kubernetes namespace and any external resources. Only OCC-owned infrastructure is removed.
• A Namespace that still contains Agents, Secrets, credential sources or similar objects cannot be deleted. The request returns 409 NAMESPACE_NOT_EMPTY.

Both rules affect cleanup and ownership, not the isolation of a running Agent.

A preview is not a deployed Agent

The repository README says the default occ dev up starts a Compose control-plane preview that cannot deploy Agents. Deploying an Agent locally requires the Kubernetes-only development profile. The practical point for a boundary review: what you see in the preview is not the boundary of a deployed Agent.

View image detail

An OpenClaw platform Namespace and a Kubernetes namespace are different scopes.

Actual size

Choose Actual size to read the graphic closely.

The platform tenant and cluster namespace are distinct concepts.

Compute isolation is the baseline; the sandbox is optional

Compute isolation and the sandbox are different layers with different owners. The sandbox guide says the Compute Driver still owns baseline isolation, Agent identity, the gateway and routing, even when a Sandbox creates the Harness workload. The Harness is the process that runs the Agent's work.

What the sandbox adds

A Sandbox adds network, filesystem or process restrictions to the Harness, and selecting one is optional. The guide says a Sandbox currently requires the bundled Kubernetes Compute Driver and dedicated Agent execution. It cannot be combined with Docker, SSH, installed Compute Drivers or embedded execution. The Installation operator selects it, and an Agent cannot choose its own Sandbox.

That last rule is a boundary in its own right: the workload being constrained does not control the constraint.

What the sandbox does not add

The guide states its limits plainly:

• Selecting a Sandbox does not add per-tool authorization.
• It does not guarantee that every command is approved before it runs.
• It does not replace Namespace network controls, workload IAM or credential isolation.

Restricting a process is not the same as deciding whether a particular tool call should happen. When "sandboxed" appears on a diagram, ask what is restricted and what remains open.

The OpenShell integration and its documented caveats

OpenShell is the bundled sandbox integration for dedicated Codex. The guide notes that the stock OpenShell gateway version documented there cannot honor two things OCC requires: the projected identity and the app-server token Secret reference. OpenShell's paired Credential Gateway keeps the model API key out of the Harness. The guide also says local verification uses development-only workarounds and is not a supported production deployment path.

The guide adds that if the selected Sandbox cannot enforce the required containment or preserve workload identity, deployment stops. That is a fail-closed statement at deployment time, and like every other statement here, it is documented, not observed.

There is also a naming trap. Upstream OpenClaw has a separate OpenShell sandbox plugin, in which only tool execution runs in OpenShell. The guide says OCE does not install that plugin and warns against combining the two. Keep them apart when reading diagrams or summaries.

View image detail

Compute isolation and an optional sandbox address different layers.

Actual size

Choose Actual size to read the graphic closely.

The compute driver sets the baseline; a sandbox adds selected execution constraints.

Credentials: follow the consumer path

IAM decides who may use a credential, but it never handles one. The authorization reference says, "IAM never accesses credentials." A Secret is a resource kind whose actions include operate. In the docs' example, a Role named "Use a model Secret" grants operate on secret and is bound to the Agent's servicePrincipalId for one exact Secret.

So IAM controls whether an identity may use a named Secret, and a separate component delivers the value. The Secrets guide adds a separate consumer and lifecycle boundary. A Secret belongs to one Namespace, and the control plane returns its ID and metadata, not its value. Model keys are bound through harnessAuth; gateway credentials are bound through secretBindings; a model key kept by a Credential Gateway follows a separate source path. The guide says permission to assign a Secret is operate on that exact Secret, and deployment also requires the Agent's service principal to have operate. Possessing the Secret ID or Namespace access alone does not grant consumption.

The same guide says changing a Secret does not restart a running consumer, there is no automatic rotation or value history, and deletion is rejected while a draft, active revision, Configuration or pending deployment still references the Secret. The documented response to exposure is to stop affected workloads, revoke the credential with its upstream provider, store a replacement and redeploy. These are current documented behaviors, not observations from a Rise deployment.

Workload identity through the Kubernetes driver

When the Kubernetes Compute Driver is explicitly selected, it provisions an Agent-specific Kubernetes ServiceAccount. It can also project a short-lived, audience-scoped ServiceAccount token into the Agent's revision Pods. The authorization reference describes that token as credential evidence for the Agent's existing ServicePrincipal, not as another platform principal. It also says that authenticating ServicePrincipal workloads through the controller API remains deferred.

That leaves several credential paths a reviewer should diagram separately:

• A model Secret that an Agent's identity is granted to use.
• A projected workload token tied to the Agent's identity.
• In the OpenShell pairing, a Credential Gateway that keeps the model API key out of the Harness.

Each has its own consumer and its own failure mode.

View image detail

Credential consumers use distinct model-key, gateway-token and Credential Gateway paths.

Actual size

Choose Actual size to read the graphic closely.

Follow each credential to its named consumer.

Revocation has an edge

The authorization reference says: "Revocation blocks later admission but cannot retract already delivered bytes." It adds that IAM changes do not stop the Agent or revoke upstream credentials. When immediate containment is needed, the reference says to stop the Agent and revoke upstream credentials. Both of those are operator actions outside IAM.

The operating guide covers the human side. Its production handoff records who responds to failures and who owns credentials and access. It also notes that Helm readiness alone does not verify API access, and that an active revision alone does not prove a model can answer.

View image detail

A secret update needs a controlled sequence: update, redeploy and verify.

Actual size

Choose Actual size to read the graphic closely.

Replacing a credential is an operational change that needs verification.

A data boundary the docs do not settle

This paragraph is reasoning, not a product claim. The documents reviewed here don't say where model inference runs. If the chosen model provider is external, requests leave the cluster. That is a data boundary the team has to map itself, and no layer in the table above covers it.

View image detail

Audit records have a defined scope and do not contain every prompt or model response.

Actual size

Choose Actual size to read the graphic closely.

Audit events should not be mistaken for a complete interaction transcript.

Audit: a narrow record, by design

The audit record is deliberately narrow. The audit log guide says it records four kinds of events: Installation bootstrap, successful resource changes, authorization denials, and lifecycle completion (such as activating an Agent revision). The events are stored in the controller's PostgreSQL database. Routine operational logs and the OpenTelemetry Collector neither export nor replace this record.

What an event carries

Each event identifies the time, Installation, actor, action, affected resource and outcome. It may also include the Namespace, request ID and authorization decision. When a service API key is issued or revoked, the event holds the non-secret key and principal IDs, not the credential.

What it is not

The guide says the record "does not represent a general log of all successful reads, Agent prompts, or model responses." A reviewer who needs to reconstruct what an Agent was asked, or what it answered, will not find that in the audit record.

Runtime log views are the one documented exception among reads:

• Each view writes a single access event before any output is read. The event records the version, source, Pod, container, line count and view ID, but never the log text.
• If the event cannot be written, no output is returned.
• Log downloads work the same way.
• Runtime status reads are not audited.

Authorization also gates container log text. The authorization reference says reading it requires Agent read_logs or administer, plus Agent read. A matching read_logs Restriction denies log text even to someone who holds administer, and each follow poll is authorized again.

Access to the record

According to the guide, OCE has no console view or public HTTP API for browsing or exporting audit events. Configurable retention and export integrations are not implemented. Investigations go through the platform operator, using the organization's approved database access procedure.

This article does not call the record complete, tamper-proof or compliant, because the sources reviewed make none of those claims. Whether the arrangement meets a team's retention or evidence needs is for that team's reviewers to decide.

View image detail

Audit access has operational boundaries: no public browse API, no configured export integration and an approved database procedure.

Actual size

Choose Actual size to read the graphic closely.

Access to the event record follows the organization’s approved database procedure.

Label every statement: documented, observed or independently assessed

When OCE comes up in an internal security review, give every statement one of three labels. Never let a statement carry a higher label than its evidence supports.

Documented means the vendor's public documentation says it. Every product claim in this article sits at this level. "Unknown identities are denied" is a documented design statement: it tells you what the authors intend and what you can plan around.

Observed means someone on your team saw the behavior on a real deployment. Suppose a team member sends an ungranted request to a disposable fixture and records the 403. That result can be labeled observed, with the date, version, configuration and method attached. An observation holds only for that version and setup, which matters for a pre-1.0 product.

Independently assessed means a party outside both the vendor and your team examined the system against stated criteria and published its method and result. The source review for this article found no independent security audit of OCE, so nothing here sits at this level.

Applying the labels

In a review document, tag each claim inline. For example: "The IAM Driver fails closed when unavailable (documented; authorization reference, retrieved 2026-10-01; not observed)." The tag is short, and it stops the claim from hardening into an assumption.

Also watch for label drift. A vendor phrase such as "hard security boundaries" describes intent. Pasted into a slide, it can quietly start to read as an assessed fact. Keeping the source and label attached to each statement makes that drift easier to spot.

Context lenses, not evidence

Two external frameworks can help organize a review, but neither is evidence about OCE.

The Kubernetes Pod Security Standards define three policy levels: Privileged, Baseline and Restricted. Restricted is the most restrictive, following current pod-hardening practice. It is one cluster-level hardening baseline, not a conclusion about the whole OCE system. The OCE docs require restricted Pod Security labels on operator-prepared Kubernetes namespaces, so the standard gives useful vocabulary for that one piece. It does not show that OCE conforms to anything.

The NIST AI Risk Management Framework Core is voluntary. Its core functions are Govern, Map, Measure and Manage, applied across the AI lifecycle. It can help structure the questions a team asks. It is not a certification, and NIST has not assessed OCE.

View image detail

Keep documented, observed and assessed claims in separate evidence lanes.

Actual size

Choose Actual size to read the graphic closely.

Label the evidence type before drawing a conclusion.

Threat-modeling questions, layer by layer

These questions are for the documentation, the operating team and, where authorized, a test fixture. They are not a checklist with pass or fail thresholds. Any "suggested check" means a check on an authorized, disposable fixture with synthetic data. Rise has not performed any of them.

One question comes before all of the layers: does this task deserve an agent at all? The Work Worth Doing test helps answer that before anyone maps the boundaries of an agent path. For the separate pilot go/no-go decision, use the companion OpenClaw Enterprise internal pilot readiness guide.

Authentication

• Which identity issuers does the deployment trust, and who administers them?
• Who holds the Installation-scoped ServicePrincipal created at bootstrap, and where is its key stored?
• The service identity persists after the founding human administrator is removed. What is the offboarding procedure for each?
• Suggested check: present an expired key and a revoked key, and confirm they return 401, distinct from the 403 that a valid but ungranted key receives.

Authorization

• Which Roles are bound with no Namespace or resource filter, and who holds them?
• Where denial is required, is there an explicit Restriction rather than just a missing binding?
• Who can manage Namespace policy, given that it requires Installation administer plus Namespace read?
• Suggested check: delete one binding and confirm whether access actually ends. The docs say other bindings or Restrictions may still apply.

Platform Namespace

• Which team, tenant or workload does each Namespace represent, and is that mapping written down?
• What does ready prove for a given Namespace, and what does it not, given that bootstrap success does not imply infrastructure readiness?
• Suggested check: with synthetic data in two fixture Namespaces, confirm that an identity in one cannot list or read resources in the other.

Kubernetes namespace and compute

• Which Compute Driver is actually running, and was it explicitly selected?
• If existingNamespace is used, who applied the restricted Pod Security labels and RoleBindings, and who monitors them?
• Which network policies, node pools and cluster roles are defined outside OCE, and who owns them?
• Is anyone treating a development setup with a Docker network per Namespace as evidence about a Kubernetes deployment?

Optional sandbox

• Is a Sandbox selected at all? The docs say selection is optional.
• Which network, filesystem and process restrictions does it actually apply, and what stays open?
• The sandbox does not provide per-tool authorization, so where is tool-level approval enforced?
• Suggested check: attempt an out-of-policy network call from the Harness, then record the result and the version.

Credential consumer paths

• Which Secrets is each Agent's identity allowed to use, and is each grant scoped to one exact Secret?
• Which component consumes each credential: the model Secret, the projected ServiceAccount token or, where used, the Credential Gateway?
• IAM revocation does not revoke upstream credentials. Who does, and how quickly?
• If the model provider is external, what data leaves the cluster in requests, and who approved it?

Audit record

• What will an investigator need to answer, and can a record that excludes reads, prompts and model responses answer it?
• Who is the platform operator who provides database access, and what is the approved procedure?
• OCE's current audit guide says configurable retention and export integrations are not implemented. Who sets backup, retention and access controls for the controller's PostgreSQL database?
• Who can view runtime logs, and who verifies that an access event is written before each view or download? Which status reads remain outside the record?

View image detail

Assign IAM, cluster, credential and application boundaries to named owners.

Actual size

Choose Actual size to read the graphic closely.

An ownership map makes the operator’s responsibilities explicit.

Reading the layers together

Read the layers as a chain in which each link has an owner. The announcement's phrase "hard security boundaries" doesn't say which link it means, but the reference pages do:

• Authorization checks exact grants.
• A Namespace partitions OCE resources.
• A Compute Driver provisions and isolates the infrastructure.
• A Sandbox can optionally restrict the Harness.
• IAM authorizes credential use but never touches the credentials.
• The audit record captures a narrow, defined set of events.

The gaps sit at the joins. IAM changes do not stop Agents. A Namespace is not a Kubernetes namespace. A sandbox is not a tool-approval system. And no audit event tells you what an Agent was asked. The documentation names each of these gaps itself, which is to its credit. Each one marks a place where the team's own controls, tests and procedures have to be in place, and has to be observed working.

Bottom line

OpenClaw Enterprise's documentation gives reviewers a useful boundary map, and that map shows layers that do not substitute for one another. Everything in this article is documented behavior only. Before relying on any layer, decide what your team needs to label as observed. Gather that evidence on an authorized, disposable fixture with synthetic data, and record that no independent assessment of OCE was found. Then write down, by name, who owns each gap the documentation leaves open.

Sources

1. OpenClaw: OpenClaw Enterprise announcement (September 29, 2026)
2. OpenClaw Enterprise repository README
3. OpenClaw Enterprise authorization reference
4. OpenClaw Enterprise Namespaces reference
5. OpenClaw Enterprise sandbox guide
6. OpenClaw Enterprise audit log guide
7. OpenClaw Enterprise operating guide
8. Kubernetes Pod Security Standards
9. NIST AI Risk Management Framework Core
10. OpenClaw Enterprise Secrets guide
11. OpenClaw Enterprise security reference
12. Rise Productive: What Is Work Worth Doing?