Implement RFC 0027: OpenClaw Enterprise

[kevinslin]

Tracks implementation of RFC 0027: OpenClaw as the Open Enterprise Agent Platform.

Implementation work should be decomposed into focused follow-up issues and pull requests while preserving the RFC's tenant-isolation, authorization, workload-identity, sandboxing, secret-brokering, deployment, and audit boundaries.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 2:09 PM ET / 18:09 UTC.

Summary
This implementation tracker remains necessary. Current main contains the accepted architecture RFC, but it expressly defers the OCC API, OCC Console, storage, audit, and integration contracts needed to implement the requested enterprise platform; a maintainer must sponsor the first bounded contract before work can begin safely.

Reproducibility: not applicable. This issue tracks new enterprise control-plane capability, not a reproducible failure in existing behavior.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Which enterprise contract should be specified and sponsored first: exact-resource admission and authorization, namespace gateway and Kubernetes provisioning, or sandbox and secret-broker boundaries?	Specify authorization first: Define external identity admission and exact-resource authorization before deployment and integration work relies on those boundaries.

Why: The accepted RFC intentionally leaves the relevant OCC API, Console, storage, audit, and integration contracts for later RFCs, so selecting a first implementation slice is a product and security-boundary decision rather than a mechanical repair.

Next step
A maintainer must select and sponsor the first bounded enterprise contract; automation cannot safely choose that product and security direction.

Security
Needs attention: The issue is security-sensitive because it proposes new tenant-isolation, authorization, secret, sandbox, and audit boundaries that need explicit design review before implementation.

Review details

Best possible solution:

Create maintainer-sponsored follow-up work for one narrow enterprise contract—preferably exact-resource admission and authorization—with explicit API, threat-model, compatibility, and validation criteria; retain this issue as the umbrella tracker until those slices are complete.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this issue tracks new enterprise control-plane capability, not a reproducible failure in existing behavior.

Is this the best way to solve the issue?

No: implementing the entire tracker directly would bypass the RFC’s intentionally deferred API, storage, audit, and integration decisions; contract-by-contract sponsorship is the narrowest maintainable path.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• Implementing this as one broad effort would force unapproved choices for public control-plane APIs, authorization semantics, storage, audit, identity, and integration contracts.
• The tracker covers security-critical boundaries; an incorrect first slice could weaken tenant isolation, secret handling, or authorization before those contracts are independently specified.

Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f.

Label changes

Label changes:

• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P2: This is a broad planned enterprise capability program with no demonstrated current user-facing outage or regression.
• impact:security: The requested scope explicitly includes tenant isolation, authorization, workload identity, sandboxing, secret brokering, and audit boundaries.

Evidence reviewed

Security concerns:

• [high] Specify enterprise authorization boundaries before implementation — rfcs/0027-openclaw-enterprise.md:62
  The RFC requires exact-resource authorization and fail-closed behavior but defers the OCC API and related implementation contracts; an implementation slice needs a reviewed threat model and contract before coding begins.
  Confidence: 0.98

What I checked:

• Current-main design boundary: The accepted RFC names OCC as a new control-plane component, but lists the OCC API and OCC Console as non-goals and says their implementation belongs to later RFCs. (rfcs/0027-openclaw-enterprise.md:19, af708f0ddb6f)
• Deferred implementation work: The RFC’s near-term future work explicitly includes OCC API contracts and implementation, OCC Console, audit interface, and further platform primitives, confirming that the accepted document does not implement this tracker. (rfcs/0027-openclaw-enterprise.md:570, af708f0ddb6f)
• Merge and ownership provenance: Current main is the RFC merge commit, which added only rfcs/0027-openclaw-enterprise.md; blame assigns all lines of that document to the same commit and author. (rfcs/0027-openclaw-enterprise.md:1, af708f0ddb6f)
• No later implementation in this checkout: main has no commits or path changes after the RFC merge, and repository history contains no later enterprise/OCC implementation commit. (rfcs/0027-openclaw-enterprise.md:1, af708f0ddb6f)
• Repository lifecycle policy: The repository README says an accepted RFC should have an implementation issue and move to completed only once implementation is complete, which matches retaining this tracker. (README.md:67, af708f0ddb6f)
• Maturity classification unavailable: The required maturity shortlist helper could not locate qa/maturity-scores.yaml in this RFC-only repository, so no stable-surface label is supported.

Likely related people:

• kevinlin-openai: Authored the sole merge commit and every blamed line of the accepted RFC, including the deferred implementation boundaries and future-work list. (role: feature owner; confidence: high; commits: af708f0ddb6f; files: rfcs/0027-openclaw-enterprise.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.