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.

What this changes

This PR proposes execution-bound workload authentication, finite authority leases, and staged enforcement for Enterprise Agents.

Example: Agent execution A is replaced by execution B while A's certificate remains valid.

• Before: The accepted RFC requires current workload authorization but does not specify execution-bound SVID registration and lease withdrawal ordering.
• After: The proposal binds A's certificate to its retired assignment and requires current authority before protected operations.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	A coherent, illustrated RFC with no concrete introduced defect; readiness remains limited by unresolved product direction.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): The inspected local Markdown preview shows the changed document and diagram rendered legibly; it proves presentation only, consistent with the PR's explicit separation of proposal and runtime qualification.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Docs · Worth it: Needs a maintainer decision
User problem: Persistent Agent executions need permission withdrawal and replacement to remain effective even when certificates or connections survive.
Reason: The design addresses a coherent Enterprise concern, but optional authentication, outage behavior, and permission-change isolation require an owner decision.

Merge readiness

⛔ Blocked before merge - 1 item remains

Keep this PR open for an Enterprise design decision: its proposed authentication and lease contracts are distinct from current main, and the RFC remains unaccepted.

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

Decision needed

• Question: Should Enterprise adopt the optional execution-bound SVID profile and finite authority-lease contracts, including the separately selected read-outage refinement?
• Recommendation: Continue draft design review: Keep the proposal open while the Enterprise owner resolves profile scope and the explicitly unresolved origin, ordering, and withdrawal mechanisms.
• Why: The accepted contract uses pod-bound ServiceAccount tokens and current authorization; this PR adds optional profiles and operational guarantees without recorded owner approval.

Before merge

• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

The proposed boundary sits between Enterprise Agent executions, OCC authorization, and accepting services; it consumes authenticated execution evidence and current policy to permit or deny exact operations.

flowchart LR
Compute[Compute evidence] --> Registration[Execution registration]
Registration --> Identity[Execution identity]
Identity --> Service[Accepting service]
OCC[Current OCC authority] --> Lease[Finite authority lease]
Lease --> Service
Service --> Effect[Protected operation]

Loading

Technical review

Best possible solution:

Resolve the proposed authentication and lease direction through the repository's RFC acceptance process while preserving the existing baseline until acceptance.

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

This PR proposes new contracts rather than repairing a reproduced failure; no target code was run.

Is this the best way to solve the issue?

The proposal preserves baseline authentication and separates identity, authorization, withdrawal, and termination, but adopting its optional profiles remains an owner decision.

AGENTS.md: not found in the target repository.

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

Security

None.

Evidence

What I checked:

• Distinct proposed contracts: The pinned introduced diff adds only the RFC, supporting specification, diagram source, and images; no runtime implementation changes. (rfcs/0035-workload-identity-and-runtime-authority.md:16, 5bd2b5d2c482)
• Current main baseline: The accepted Enterprise RFC specifies stable workload identity, pod-bound ServiceAccount authentication, and current authorization; searches of main did not establish the proposed SPIFFE/SPIRE or enforcement-lease contracts. (rfcs/0027-openclaw-enterprise.md:293, 967d9aac7472)
• Feature history and original direction: History and GitHub identify the accepted Enterprise contract with RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35; its author supported Kubernetes ServiceAccounts while explaining that OCC retains additional policy responsibilities. (rfcs/0027-openclaw-enterprise.md:287, af708f0ddb6f)
• RFC acceptance boundary: The repository requires design discussion, acceptance, and an implementation issue before merging a new RFC; this proposal retains draft status and a blank issue. (README.md:88, 967d9aac7472)
• Companion work remains separate: docs: propose credential lifecycle and GitHub App access #68, docs: propose service-owned work authority #70, and docs: propose persistent Agent runtime lifecycle #71 remain open proposals by the same author for credentials, Work, and lifecycle; their bodies describe complementary responsibilities rather than replacement of this PR. (rfcs/0035-workload-identity-and-runtime-authority.md:42, 5bd2b5d2c482)
• Cross-repository proposal is not a merged fix: docs: specify GitHub credentials, identity, Work, and runtime lifecycle openclaw-enterprise#172 is closed without merging and explicitly describes proposed wiring rather than a running integration; it does not establish implementation or supersession here.

Likely related people:

• kevinlin-openai: Raw commit af708f0 adds rfcs/0027-openclaw-enterprise.md:287 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)

Labels

Label changes:

No label changes.

Label justifications:

• P3: This is a draft design proposal without a shipped runtime change or demonstrated urgent regression.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• proof: sufficient: Contributor real behavior proof is sufficient.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (9 earlier review cycles; latest 8 shown)

• 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
• reviewed 2026-09-11T19:10:46.368Z sha 5bd2b5d :: blocked before merge. :: none
• reviewed 2026-09-14T21:59:12.122Z sha 5bd2b5d :: blocked before merge. :: none
• reviewed 2026-10-04T22:44:33.035Z sha 5bd2b5d :: blocked before merge. :: none
• reviewed 2026-10-10T18:33:02.429Z sha 5bd2b5d :: blocked before merge. :: none

Reviewed October 14, 2026, 5:49 AM ET / 09:49 UTC (Revision 10).