docs: propose workload identity and bounded enforcement

[freeqaz-openai]

What Problem This Solves

Certificates and connections can outlive an execution or its permissions. Persistent Agents need stable identity and current operation authority so replacement and renewal cannot restore retired access.

Why This Change Was Made

Map the current Agent-specific servicePrincipalId to the proposed stable WorkloadIdentity, with optional execution-bound SPIFFE/SPIRE SVID certificates. The certificate authenticates execution; each operation still needs current authority. Managed repository reads first need a root work record; any qualified subordinate helpers share that work and its scope. Approved publication adds exact-operation approval; a broad Work API, independently continuing children and public Stop/Start controls come later.

User Impact

The first GitHub profile keeps provider credentials outside Agent workloads and checks online OCC authority for every operation, including reads and credential maintenance. Both permission increases and decreases require a fresh Pod/gVisor sandbox and execution identity. Work and execution may be uncapped while every lease remains finite. Writer exclusion and physical termination require separate evidence; identity or lease expiry alone establishes neither.

This is a documentation proposal extending RFC 0027. It remains draft with a blank implementation issue pending acceptance.

Reading Guide

• Workload identity and runtime authority and detailed specification.
• Related drafts: #68, #70, #71.

Evidence

• Checked draft metadata, required sections, Markdown structure, links, anchors and whitespace; reran desktop/mobile rendering and independent cross-RFC review.
• Desktop preview uses a local Markdown render with GitHub-style CSS.
• Document checks only; provider, native runtime and deployment qualification require separate evidence.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 11, 2026, 3:10 PM ET / 19:10 UTC (Revision 6).

ClawSweeper review

What this changes

Adds an illustrated RFC and enforcement specification proposing execution-specific authentication, finite authority leases, and staged Enterprise runtime enforcement.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open: this is a coherent extension of the accepted Enterprise RFC, absent from main, with no concrete patch defect found. The related drafts cover complementary work rather than superseding it.

Priority: P3
Reviewed head: 5bd2b5d2c482a4452ce7ac27b87ef10077cdd1ec
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦞 diamond lobster (5/6)	A well-scoped, illustrated proposal with explicit safety boundaries and no actionable defects found; acceptance remains a separate repository decision.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The inspected current-head desktop preview directly demonstrates the changed RFC text and authority diagram in a local Markdown render; runtime authorization is explicitly outside this documentation PR's claims.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The inspected current-head desktop preview directly demonstrates the changed RFC text and authority diagram in a local Markdown render; runtime authorization is explicitly outside this documentation PR's claims.
Evidence reviewed	8 items	Repository policy and acceptance lifecycle: No root or nested AGENTS.md or matching maintainer notes were found. README requires a maintainer-discussion thread and RFC acceptance, followed by an implementation issue and accepted metadata before merge. Distinct from the accepted baseline: Current main defines stable workload identity and pod-bound token authentication in RFC 0027; the search found no SPIFFE/SPIRE or enforcement-lease proposal. The complete new RFC and supporting specification were read locally. Security requirements remain deployment-gated: The specification explicitly separates RFC acceptance from qualification of attestation, transport and lease mechanisms. It requires retired-execution denial, fresh permission contexts, current-authority checks and measured withdrawal before deployment.
Findings	None	None.
Security	None	None.

How this fits together

The proposed Enterprise controller assigns Agent executions and authorizes their operations. Execution certificates establish identity, while current permission checks and bounded leases govern access to protected services.

flowchart LR
  A[Agent execution] --> B[Execution identity verification]
  C[Controller assignment] --> B
  D[Current permissions and work scope] --> E[Operation authorization]
  B --> E
  F[Finite authority lease] --> E
  E --> G[Protected service operation]

Loading

Decision needed

Question	Recommendation
Should this staged workload-identity proposal be accepted as an extension of RFC 0027 while deployment mechanisms remain separately gated?	Accept the staged contract: Approve the invariants while retaining explicit implementation qualification gates for SPIRE, protected origin and outage leases.

Why: The repository explicitly reserves RFC acceptance for its discussion process; technical consistency and rendered documentation cannot establish that product decision.

Before merge

• Resolve merge risk (P1) - Exact-execution attestation, lease ordering and withdrawal bounds remain implementation choices; accepting the design must not be interpreted as qualifying a deployable security profile.
• Complete next step (P2) - Complete the required maintainer-discussion and acceptance process; after acceptance, create the implementation issue, link it in the RFC, and change the RFC status to accepted before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Change scope	428 Markdown lines, 19 diagram-source lines, 2 images; 0 runtime or test lines	The change defines and illustrates a design without implementing its authorization mechanisms.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Accept a staged identity-and-authority contract that preserves the token baseline and keeps every optional runtime profile unavailable until separately qualified.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Accept a staged identity-and-authority contract that preserves the token baseline and keeps every optional runtime profile unavailable until separately qualified.

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

Not applicable: this PR proposes a future authentication and authority model rather than reporting a reproducible defect in this repository.

Is this the best way to solve the issue?

Yes, as a design proposal: it preserves the accepted identity boundary, stages delivery, and explicitly distinguishes authentication, authorization withdrawal and physical termination.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label changes:

• add rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦞 diamond lobster, so this older rating label is no longer current.

Label justifications:

• P3: This is a design-document proposal with no immediate runtime change or reported production regression.
• rating: 🦞 diamond lobster: Overall readiness is 🦞 diamond lobster; proof is 🦞 diamond lobster and patch quality is 🦞 diamond lobster.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The inspected current-head desktop preview directly demonstrates the changed RFC text and authority diagram in a local Markdown render; runtime authorization is explicitly outside this documentation PR's claims.
• proof: sufficient: Contributor real behavior proof is sufficient. The inspected current-head desktop preview directly demonstrates the changed RFC text and authority diagram in a local Markdown render; runtime authorization is explicitly outside this documentation PR's claims.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The inspected current-head desktop preview directly demonstrates the changed RFC text and authority diagram in a local Markdown render; runtime authorization is explicitly outside this documentation PR's claims.

Evidence

What I checked:

• Repository policy and acceptance lifecycle: No root or nested AGENTS.md or matching maintainer notes were found. README requires a maintainer-discussion thread and RFC acceptance, followed by an implementation issue and accepted metadata before merge. (README.md:78, 967d9aac7472)
• Distinct from the accepted baseline: Current main defines stable workload identity and pod-bound token authentication in RFC 0027; the search found no SPIFFE/SPIRE or enforcement-lease proposal. The complete new RFC and supporting specification were read locally. (rfcs/0027-openclaw-enterprise.md:293, 967d9aac7472)
• Security requirements remain deployment-gated: The specification explicitly separates RFC acceptance from qualification of attestation, transport and lease mechanisms. It requires retired-execution denial, fresh permission contexts, current-authority checks and measured withdrawal before deployment. (rfcs/0035/enforcement-spec.md:321, 5bd2b5d2c482)
• Rendered documentation proof: The prepared proof-image-1.png contained HTML and could not be decoded. The exact checked-out review-preview.png was successfully inspected instead: it visibly renders the current identity mapping, delivery stages, enforcement text and diagram without apparent clipping. This proves document presentation, not runtime security. (rfcs/0035/review-preview.png, 5bd2b5d2c482)
• Re-review continuity: The previous completed review contained no findings or published rank-up moves. The current revision clarifies identity representation and delivery stages. A local previous-head comparison failed retrieving a promised blob with HTTP 403; the pinned GitHub comparison supplied the changes. The prior deployment-qualification warning is future implementation context, not a new documentation proof blocker. (rfcs/0035/enforcement-spec.md:9, 5bd2b5d2c482)
• Enterprise design history: Feature history and blame connect the accepted Enterprise identity contract to af708f0. Raw commit inspection records parent cf89a2b; GitHub identifies the RFC file as added by that commit and associates it with kevinlin-openai. The accepted baseline came through RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35. (rfcs/0027-openclaw-enterprise.md:293, af708f0ddb6f)

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:293 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: af708f0ddb6f; files: rfcs/0027-openclaw-enterprise.md)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (5 earlier review cycles)

• reviewed 2026-09-08T22:14:32.736Z sha 424fb2f :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T00:41:28.414Z sha 8514c17 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T21:12:22.349Z sha e070f14 :: blocked before merge. :: none
• reviewed 2026-09-09T21:43:00.366Z sha 28ee5d2 :: blocked before merge. :: none
• reviewed 2026-09-11T07:47:45.452Z sha ae85f91 :: blocked before merge. :: none