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 14, 2026, 5:59 PM ET / 21:59 UTC (Revision 7).

ClawSweeper review

What this changes

Adds an illustrated proposal and enforcement specification for execution-specific workload authentication, finite authority leases, and staged Enterprise runtime enforcement.

Merge readiness

⛔ Blocked before merge - 3 items remain

This is a coherent RFC extension absent from current main, with no concrete patch defect found. It remains pending design acceptance under the repository’s RFC lifecycle.

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 focused, clearly bounded specification with matching rendered evidence and no actionable defect; design acceptance is a separate gate.
Proof confidence	🦞 diamond lobster (5/6) ✨ media proof bonus	Sufficient (screenshot): The committed desktop preview visibly demonstrates the changed RFC text and diagram in a local Markdown render; that is sufficient for this documentation change and makes no claim to prove SPIRE/gVisor enforcement.
Patch quality	🦞 diamond lobster (5/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The committed desktop preview visibly demonstrates the changed RFC text and diagram in a local Markdown render; that is sufficient for this documentation change and makes no claim to prove SPIRE/gVisor enforcement.
Evidence reviewed	6 items	Repository lifecycle requires acceptance: README requires maintainer discussion, acceptance, an implementation issue, and accepted frontmatter before merging a new RFC. The proposal correctly remains draft with its issue blank. Introduced scope and current-main boundary: The verified base-to-head delta adds two Markdown documents, one diagram source, and two PNGs; it changes no executable runtime, configuration loader, persistent schema, dependency, or workflow. Current main contains RFC 0027 but not this proposal. Live GitHub metadata confirmed the supplied base and head and that this PR remains unmerged; no fixing merged PR or release was established. Existing Enterprise identity contract: RFC 0027 specifies stable Agent identity, pod-bound authentication, and current authorization for each operation. Its merged provenance is #35, independently confirmed through GitHub; that foundational proposal does not supply this RFC’s optional SVID and lease contracts.
Findings	None	None.
Security	None	None.

How this fits together

The proposed Enterprise controller admits Agent executions and controls their access to protected operations. Execution credentials identify the caller, while current authorization and bounded leases constrain what accepting services may permit.

flowchart LR
  A[Agent and admitted work] --> B[Enterprise controller]
  B --> C[Execution registration]
  C --> D[Execution credential]
  B --> E[Current authority and finite lease]
  D --> F[Accepting service checks]
  E --> F
  F --> G[Permit or deny operation]

Loading

Decision needed

Question	Recommendation
Should this optional workload-identity and bounded-authority design be accepted as an extension to RFC 0027?	Accept the staged contracts: Accept the invariants while retaining separate implementation qualification gates for each attestation, transport, and lease profile.

Why: The repository requires explicit RFC acceptance, and selecting these Enterprise contracts requires architectural intent beyond documentation correctness.

Before merge

• Resolve merge risk (P1) - Exact-execution attestation, lease ordering, and measured withdrawal bounds remain unresolved implementation choices; accepting the RFC would not qualify a deployable security profile.
• Complete next step (P2) - Obtain RFC acceptance through the required maintainer discussion; after acceptance, create and link the implementation issue and set status to accepted before merging.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Proposal scope	428 Markdown lines, 19 diagram-source lines, 2 images; 0 runtime or test lines	The branch documents a security design without deploying its enforcement mechanisms.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Accept a staged design that preserves baseline authentication and keeps optional profiles unavailable until their origin, revocation, and migration guarantees are demonstrated.
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 design that preserves baseline authentication and keeps optional profiles unavailable until their origin, revocation, and migration guarantees are demonstrated.

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

Not applicable: this PR proposes new contracts rather than repairing a reproduced runtime defect; its rendered documentation was inspected.

Is this the best way to solve the issue?

Yes, as a staged RFC: it separates authentication from authorization and explicitly gates unqualified mechanisms, while final architectural acceptance remains a maintainer decision.

AGENTS.md: not found in the target repository.

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

Labels

Label justifications:

• P3: This is a design proposal with no deployed behavior change or demonstrated urgent 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 committed desktop preview visibly demonstrates the changed RFC text and diagram in a local Markdown render; that is sufficient for this documentation change and makes no claim to prove SPIRE/gVisor enforcement.
• proof: sufficient: Contributor real behavior proof is sufficient. The committed desktop preview visibly demonstrates the changed RFC text and diagram in a local Markdown render; that is sufficient for this documentation change and makes no claim to prove SPIRE/gVisor enforcement.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The committed desktop preview visibly demonstrates the changed RFC text and diagram in a local Markdown render; that is sufficient for this documentation change and makes no claim to prove SPIRE/gVisor enforcement.

Evidence

What I checked:

• Repository lifecycle requires acceptance: README requires maintainer discussion, acceptance, an implementation issue, and accepted frontmatter before merging a new RFC. The proposal correctly remains draft with its issue blank. (README.md:78, 967d9aac7472)
• Introduced scope and current-main boundary: The verified base-to-head delta adds two Markdown documents, one diagram source, and two PNGs; it changes no executable runtime, configuration loader, persistent schema, dependency, or workflow. Current main contains RFC 0027 but not this proposal. Live GitHub metadata confirmed the supplied base and head and that this PR remains unmerged; no fixing merged PR or release was established. (rfcs/0035-workload-identity-and-runtime-authority.md:16, 5bd2b5d2c482)
• Existing Enterprise identity contract: RFC 0027 specifies stable Agent identity, pod-bound authentication, and current authorization for each operation. Its merged provenance is RFC 0027: OpenClaw as the Open Enterprise Agent Platform #35, independently confirmed through GitHub; that foundational proposal does not supply this RFC’s optional SVID and lease contracts. (rfcs/0027-openclaw-enterprise.md:287, af708f0ddb6f)
• Explicit security qualification boundary: The specification requires final-submission checks, denies reuse of retired assignments, separates withdrawal from physical termination, and explicitly leaves deployment profiles unavailable until their mechanisms are demonstrated. These are proposed contracts, not newly executable authority paths. (rfcs/0035/enforcement-spec.md:289, 5bd2b5d2c482)
• Rendered documentation proof inspected: Inspected the committed 1080×2651 desktop preview and authority diagram directly. The preview visibly matches the revised identity mapping, staged delivery, online authorization, and qualification caveats. Prepared scratch downloads contained HTML despite their PNG names; the valid committed images resolved that inspection problem. This proves document presentation, not deployed security behavior. (rfcs/0035/review-preview.png, 5bd2b5d2c482)
• Review continuity and complementary drafts: The previous completed review examined the identical head and retained no findings or published rank-up moves. Its deployment-qualification caution is already explicit in the specification. Related open proposals docs: propose credential lifecycle and GitHub App access #68, docs: propose service-owned work authority #70, and docs: propose persistent Agent runtime lifecycle #71 cover mediation, durable work, and lifecycle respectively; none is a merged replacement. (rfcs/0035-workload-identity-and-runtime-authority.md:42, 5bd2b5d2c482)

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)

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 (6 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
• reviewed 2026-09-11T19:10:46.368Z sha 5bd2b5d :: blocked before merge. :: none