diff --git a/rfcs/0027/baseline-and-proposal.dot b/rfcs/0027/baseline-and-proposal.dot
new file mode 100644
index 00000000..82ff03c0
--- /dev/null
+++ b/rfcs/0027/baseline-and-proposal.dot
@@ -0,0 +1,50 @@
+digraph BaselineAndProposal {
+ graph [rankdir=TB, bgcolor="white", pad="0.18", nodesep="0.36", ranksep="0.32", splines=polyline, fontname="Arial", fontsize=12];
+ node [shape=box, style="rounded,filled", fontname="Arial", fontsize=13, fontcolor="#24323B", color="#82949D", penwidth=1.1, margin="0.16,0.12"];
+ edge [fontname="Arial", fontsize=10, fontcolor="#425963", color="#6B818A", penwidth=1.2, arrowsize=0.7];
+
+ subgraph cluster_current_credentials {
+ label="EXISTING / Provider-managed model token, dedicated Codex\nThe separate Agent messaging gateway receives neither value.";
+ labelloc=t; labeljust=l; style=rounded; color="#BDCBD1"; fontcolor="#425963"; margin=16;
+ issue [label="ServiceAccountDriver\nIssue model token", fillcolor="#EFF3F6"];
+ compute [label="API-side Compute\nStore credential", fillcolor="#EFF3F6"];
+ secret [label="Account Secret\nToken + workspace ID", fillcolor="#EFF3F6"];
+ codex [label="Dedicated Codex\nReceive token +\nworkspace ID", fillcolor="#EFF3F6"];
+ { rank=same; issue; compute; secret; codex; }
+ issue -> compute -> secret -> codex;
+ }
+
+ subgraph cluster_proposed_credentials {
+ label="ADDITION / Proposed managed GitHub profile\nCurrent OCC authority is required for every GitHub dispatch; the existing model-credential path remains.";
+ labelloc=t; labeljust=l; style=rounded; color="#9FBFB6"; fontcolor="#355F54"; margin=16;
+ agent [label="Agent execution\nNo GitHub token", fillcolor="#E9F3F1", color="#578D82"];
+ connector [label="Trusted connector\nVerify execution + Work", fillcolor="#E9F3F1", color="#578D82"];
+ broker [label="CredentialGatewayDriver\n(proposed)\nBroker + mediator", fillcolor="#E9F3F1", color="#578D82"];
+ github [label="GitHub\nScoped request", fillcolor="#E9F3F1", color="#578D82"];
+ { rank=same; agent; connector; broker; github; }
+ agent -> connector -> broker -> github;
+ }
+
+ subgraph cluster_current_cutover {
+ label="EXISTING / Ordinary Kubernetes reconciliation: source call order\nActivation and a Recreate gateway rollout do not establish the full observed-stop contract below.";
+ labelloc=t; labeljust=l; style=rounded; color="#BDCBD1"; fontcolor="#425963"; margin=16;
+ select [label="Commit successor\nas active revision", fillcolor="#EFF3F6"];
+ activate [label="Request successor\nactivation", fillcolor="#EFF3F6"];
+ retire [label="Request predecessor\nretirement", fillcolor="#EFF3F6"];
+ { rank=same; select; activate; retire; }
+ select -> activate -> retire;
+ }
+
+ subgraph cluster_required_cutover {
+ label="REQUIRED / RFC 0027 activation order, specified by RFC 0037\nObserved predecessor termination gates successor execution and shared writes; serving has an availability gap.";
+ labelloc=t; labeljust=l; style=rounded; color="#A9BCD0"; fontcolor="#426381"; margin=16;
+ prepare [label="Isolated candidate\nExecution disabled", fillcolor="#EAF1F8", color="#6489B0"];
+ stop [label="Observe predecessor\nHarness + writers stopped\nResolve uncertain creates", fillcolor="#EAF1F8", color="#6489B0"];
+ permit [label="Select successor\nPermit execution", fillcolor="#EAF1F8", color="#6489B0"];
+ route [label="Enable routing\nafter readiness", fillcolor="#EAF1F8", color="#6489B0"];
+ { rank=same; prepare; stop; permit; route; }
+ prepare -> stop -> permit -> route;
+ }
+
+ issue -> agent -> select -> prepare [style=invis];
+}
diff --git a/rfcs/0027/baseline-and-proposal.png b/rfcs/0027/baseline-and-proposal.png
new file mode 100644
index 00000000..e7008840
Binary files /dev/null and b/rfcs/0027/baseline-and-proposal.png differ
diff --git a/rfcs/0027/runtime-access-overview.dot b/rfcs/0027/runtime-access-overview.dot
new file mode 100644
index 00000000..abbcc6d1
--- /dev/null
+++ b/rfcs/0027/runtime-access-overview.dot
@@ -0,0 +1,12 @@
+digraph RuntimeAccessOverview {
+ graph [rankdir=LR, bgcolor="white", pad="0.18", nodesep="0.28", ranksep="0.38", splines=spline, fontname="Arial", fontsize=11];
+ node [shape=box, style="rounded,filled", fontname="Arial", fontsize=12, fontcolor="#24323B", color="#82949D", penwidth=1.1, margin="0.16,0.12"];
+ edge [fontname="Arial", fontsize=10, fontcolor="#425963", color="#6B818A", penwidth=1.2, arrowsize=0.7];
+
+ reads [label="A: Managed reads\nMetadata, clone, fetch\nMinimal internal Work + operations", fillcolor="#E9F3F1", color="#578D82"];
+ publish [label="B: Coding + publication\nHuman Approve and publish\nExact candidate + separate effects", fillcolor="#EAF1F8", color="#6489B0"];
+ lifecycle [label="C: Broader durable Work + children\nStop task / Stop Agent / Start Agent\nQualify broader lifecycle behavior", fillcolor="#F7EDEE", color="#B7858B"];
+
+ reads -> publish;
+ publish -> lifecycle;
+}
diff --git a/rfcs/0027/runtime-access-overview.md b/rfcs/0027/runtime-access-overview.md
new file mode 100644
index 00000000..f3fdd9da
--- /dev/null
+++ b/rfcs/0027/runtime-access-overview.md
@@ -0,0 +1,53 @@
+# Enterprise runtime and access: RFC series
+
+This informational guide connects four **draft** proposals under accepted [RFC 0027](../0027-openclaw-enterprise.md). Each draft owns its requirements; this guide adds no authority, resource, or acceptance decision.
+
+## Four owners
+
+| Proposal | Owns |
+| --- | --- |
+| [0036: work authority](https://github.com/openclaw/rfcs/pull/70) | Service-owned logical work, immutable scope and selected duration policy, child admission, and delivery authority. |
+| [0035: identity and enforcement](https://github.com/openclaw/rfcs/pull/69) | Authenticated identity, execution assignment, bounded enforcement leases, and withdrawal. |
+| [0034: credentials and GitHub](https://github.com/openclaw/rfcs/pull/68) | Credential issuance, protected custody, mediated use, and cleanup. |
+| [0037: runtime and delivery](https://github.com/openclaw/rfcs/pull/71) | Stop/resume, bounded drain, writer exclusion, completed-state recovery, and completed-result delivery. |
+
+## Changes from the merged implementation
+
+The comparison below is anchored to merged source `3eeacb8`. The named profiles have different credential and runtime boundaries.
+
+| Boundary | Existing implementation | Addition or required change |
+| --- | --- | --- |
+| Identity and configuration | An [Agent-associated ServicePrincipal and revision selections](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/packages/contracts/src/index.ts#L309) for Provider and ServiceAccount. | 0035 binds authenticated execution to work authority. 0034 adds the proposed `repositoryAccess` selection and `credential_gateway` capability. |
+| Credentials | [Provider-managed model tokens](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/docs/reference/service-accounts.md#L85) reach dedicated Codex through Compute's account Secret. Ordinary [SecretDriver bindings](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/docs/flows/secret-storage-and-delivery.md#L113) reach the consuming gateway environment. | 0034 adds mediated GitHub access with protected tokens and current OCC authority per dispatch. Existing model and ServiceAccount credential paths remain. |
+| Replacement | The [ordinary Kubernetes controller](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/apps/controller/src/worker.ts#L987) selects and requests successor activation before requesting predecessor retirement. | 0037 requires observed predecessor termination before successor execution or shared writes, preserving RFC 0027's order and accepting an availability gap. |
+
+
+
+The messaging gateway remains Agent-owned, provisioned by Compute, and separate from the proposed credential gateway. In dedicated Codex, it receives neither managed account token nor workspace ID. Current [activation](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/apps/controller/src/drivers/compute/kubernetes/index.ts#L1647) and [retirement](https://github.com/openclaw/openclaw-enterprise/blob/3eeacb85d9e8e087bc3e74d792778e4ef3123412/apps/controller/src/drivers/compute/kubernetes/index.ts#L1817) calls do not establish the full observed-stop contract; their order alone does not prove concurrent writers.
+
+## Delivery stages
+
+
+
+| Stage | User-visible behavior | Required boundary |
+| --- | --- | --- |
+| **A: read** | Managed repository metadata, clone, and fetch. | Current authorization for each dispatch, protected credentials, and minimal internal Work and operation records. A standalone root Work may qualify first; same-scope subordinate helpers join only after their attribution and cancellation are qualified. |
+| **B: code and publish** | Coding plus explicit human **Approve and publish** for an exact frozen candidate. | Any configured, authorized human may approve, including the requester. The Agent cannot approve its own candidate; absent approval policy denies publication. |
+| **C: durable work and controls** | Broader durable Work and children, **Stop task**, **Stop Agent**, and **Start Agent**. | Qualify the broader work and lifecycle contracts; this stage does not add advanced scheduling or a task-database design. |
+
+Later publication modes may require an independent human **or** use an explicitly scoped automatic authorization policy. These are alternative modes, both bound to the exact candidate and current policy; automatic authorization does not also require per-operation human approval. Missing policy never selects a fallback. See [repository configuration](../0034/repository-configuration.md).
+
+## One operation
+
+1. **Admit.** OCC checks the requester's invocation permission and the service's own access separately. Minimal internal records bind root Work, immutable scope, selected duration policy, execution, and operation identity. Execution defaults to uncapped unless admission selects a finite limit; missing policy is not an uncapped selection. Qualified helpers remain subordinate to the same root's scope and cancellation. Broader durable-child behavior is later scope (0035/0036).
+2. **Dispatch and renew.** The trusted connector proves its identity and execution/Work binding. The proposed `CredentialGatewayDriver`, selected by the Installation, obtains online OCC authority for every GitHub dispatch and keeps tokens outside Agent execution (0034). It is separate from the Agent messaging gateway; broker and mediator may share a trusted service. Each enforcement lease and operation deadline is finite. Renewal respects every configured Work, attempt, and ancestor limit; certificate or token rotation extends none of them. Stage B also records approval and push/PR effects separately.
+3. **Stop or complete.** A completed model turn does not close logical Work. Cancellation and security revocation withdraw affected authority from the first supported profile. Stage C adds the broader user controls, bounded graceful drain, and separately admitted delivery of an already completed result to its exact audience; cancellation or security revocation also withdraws affected delivery (0036/0037).
+4. **Replace and clean up.** Changed permissions require a fresh isolation boundary; the selected Kubernetes/gVisor profile uses a fresh Pod and sandbox. Compute proves predecessor termination before shared writable replacement. When separately selected, recovery restores supported completed state; active-session migration and replay remain later scope (0037). Closed Work and uncertain effects cannot be revived or replayed. Credential cleanup survives Work closure and Agent deletion under retained platform authority (0034).
+
+## Acceptance boundary
+
+RFC 0027's accepted baseline denies operations when authorization is unavailable. The first GitHub profile retains that behavior, including reads and credential maintenance; previously fetched local files are a separate boundary. The broader authority drafts retain an optional **explicit amendment** for separately selected, qualified reads under existing unexpired enforcement leases, with all required local evidence intact. Writes, authority renewal, admission, and new assignment still require current authority. That amendment remains unaccepted and is not an initial GitHub release gate.
+
+Review shared contracts together and accept RFCs separately under the [repository lifecycle](../../README.md#rfc-lifecycle). Stages A and B need the relevant minimal identity, Work, operation, cancellation, and credential contracts; they do not wait for all of Stage C. Selecting SPIFFE for a connector does not select it for every Agent.
+
+Acceptance does not qualify a production runtime. Each owner retains its mechanism and integration gates, including protected Work attribution, measured withdrawal, recovery compatibility, and mediated provider access. Initial profiles name the helper/child and recovery subset they support. Component checks and explicitly substituted external interfaces support bounded source evidence; runtime and provider claims require the corresponding live evidence.
diff --git a/rfcs/0027/runtime-access-overview.png b/rfcs/0027/runtime-access-overview.png
new file mode 100644
index 00000000..37045994
Binary files /dev/null and b/rfcs/0027/runtime-access-overview.png differ
diff --git a/rfcs/0034-github-app-credentials.md b/rfcs/0034-github-app-credentials.md
new file mode 100644
index 00000000..f53379c5
--- /dev/null
+++ b/rfcs/0034-github-app-credentials.md
@@ -0,0 +1,94 @@
+---
+title: Credential lifecycle and GitHub App access for Enterprise Agents
+authors:
+ - Free Wortley
+created: 2026-09-05
+last_updated: 2026-09-14
+status: draft
+issue:
+rfc_pr: https://github.com/openclaw/rfcs/pull/68
+---
+
+# Proposal: Credential lifecycle and GitHub App access for Enterprise Agents
+
+## Summary
+
+Extend OpenClaw Enterprise's `SecretBroker` to manage issued credentials, starting with GitHub Apps. The OpenClaw Control Plane (OCC) authorizes each operation; a proposed `CredentialGatewayDriver` manages mediation and credential lifecycle outside Agent execution. Deliver managed repository reads first, then a coding workflow with human-approved publication, followed by broader durable work and lifecycle controls.
+
+## Motivation
+
+Agents need organization-managed repository, issue, and pull-request access. Shared lifecycle management avoids duplicating authorization, renewal, and recovery across providers. Scoped tokens still expose usable copies when leaked: GitHub installation tokens [expire after one hour](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app), and ending a session or replacing a token does not revoke them.
+
+## Goals
+
+- Keep provider credentials outside production Agent execution.
+- Enforce each Agent's repository grants and exact publication policy.
+- Preserve original-work authority and credential cleanup across turns and failures.
+
+## Non-Goals
+
+New IAM or public token resources; personal GitHub ACL synchronization; every Git protocol; hiding fetched history; disclosure prevention across every output channel. Active-session migration and replay remain later work.
+
+## Proposal
+
+### Configure repository access
+
+A Namespace administrator selects repositories through typed Agent configuration. OCC authorizes the exact Agent, Configuration, and referenced integration binding. A separately authorized deployment verifies GitHub installation scope and freezes repository IDs, checkout refs, read profiles, and publication policy into `AgentRevision`; saving the draft does not activate it. Effective access intersects these grants with current service authority and the GitHub App's available permissions. App-wide access and invocation user/channel allowlists grant no repository access by themselves.
+
+The current public Agent API has no repository field. The [proposed configuration and Driver contract](0034/repository-configuration.md) makes this addition explicit. Initial configuration is admin-managed in OCE; no external directory or personal GitHub ACL synchronization is required.
+
+### Assign ownership
+
+The Installation selects a proposed `CredentialGatewayDriver` for trusted mediation and broker/issuer lifecycle through admitted handles. OCC/IAM remains the sole platform authorizer. `SecretDriver` retains storage ownership; `ServiceAccountDriver` retains account provisioning. Compute owns execution and checkout; SandboxDriver verifies containment. The credential gateway is distinct from the Agent messaging gateway; one trusted deployment may host both broker and mediator.
+
+Each broker access lease binds genuine service-owned **Work**, its exact Agent/revision and execution assignment, or separately admitted preparation. Current operation grants, cancellation/withdrawal, protected custody, durable effect records, and unknown-outcome handling are required from the first read. A work ID or caller-supplied handle cannot establish authority. The [broker contract](0034/credential-broker-v1-spec.md) and [series overview](0027/runtime-access-overview.md) define these boundaries.
+
+The Agent receives a scoped, opaque **proxy credential**, invalid at GitHub. On each request, the mediator checks that credential, independently verified execution/Work origin, and current online OCC permission before replacing it with the real installation token on the trusted upstream connection. The App key and real token never enter production Agent execution. The [proxy credential contract](0034/github-app-v1-spec.md#scoped-proxy-credential) defines delivery, lifetime, and denial behavior.
+
+### Deliver in three stages
+
+| Stage | Release scope |
+| --- | --- |
+| A — Managed reads | Mediated repository metadata and clone/fetch, with verified checkout before Harness startup. |
+| B — Coding workflow | Selected issue/PR reads and trusted **Approve and publish** for an exact retained candidate. |
+| C — Durable work | Broader durable Work, separately admitted children, and Stop task / Stop Agent / Start Agent controls. |
+
+Stages A and B use root Work. Subordinate helpers may share its scope and cancellation only after that context is qualified; root-only execution may qualify first. Separately admitted durable children belong to stage C. These stages have [separate acceptance gates](0034/lifecycle.md#acceptance-matrix).
+
+```mermaid
+flowchart LR
+ Agent["Agent / Git client
Opaque proxy credential only"]
+ subgraph Trusted["Trusted OCE outside Agent execution"]
+ Connector["Host connector
Verify execution and original Work"]
+ Mediator["Credential gateway
Validate credential and operation
Strip caller auth; insert real token"]
+ OCC["OCC authority
Online decision for each dispatch"]
+ Publisher["Stage B publisher
Exact human-approved candidate
Separate push and PR effects"]
+ end
+ GitHub["GitHub
Repository and token scope"]
+ Agent -->|"A: metadata / clone / fetch
with proxy credential"| Connector
+ Connector -->|"Protected origin"| Mediator
+ OCC --> Mediator
+ Agent -->|"B: candidate"| Publisher
+ Publisher -->|"Approved effect"| Mediator
+ Mediator -->|"Verified upstream TLS
Real installation token"| GitHub
+```
+
+### Authorize publication
+
+Stage B requires explicit approval by a configured, currently authorized human; the requester may approve. The Agent cannot approve itself. Approval binds the non-public repository, exact objects, base and target refs, expected prior remote tip, and draft PR metadata. Changed candidates require new approval. Push performs an atomic expected-old update; draft PR creation is a separate recorded effect. Unknown outcomes never trigger blind replay.
+
+Later policy modes may require an independent human or automatically authorize narrowly configured operations, such as an allowlisted branch push or draft PR. Both retain current authority and exact candidate/effect controls. Neither is enabled in the MVP or used when policy is missing. [Publication details](0034/github-app-v1-spec.md#trusted-publication) also govern later transparent Git/`gh` adapters.
+
+### Enforce and close access
+
+Production is mediated only. Every dispatch, including reads, issuance, and credential maintenance, requires online OCC authority; outages deny dispatch. Native tokens are development/testing only. Permission increases and decreases require a fresh Pod/gVisor sandbox and eligible context. Checkout replacement requires observed writer termination; preparation failure preserves the serving workspace.
+
+Work and execution may be explicitly uncapped, while leases, credentials, and operation deadlines remain finite. Closure starts durable cleanup without implying process termination or provider revocation. Already accepted provider effects may finish.
+
+## Rationale
+
+A shared lifecycle reduces provider-specific recovery code. Mediation adds protocol and runtime integration work, but keeps reusable GitHub credentials outside execution. Copy resistance assumes trusted infrastructure and containment; relay through the original authorized container remains outside the guarantee.
+
+## Unresolved questions
+
+Which runtime attachment and protected dispatcher qualify first? Which exact read commands, deployment approvers/refs, approval lifetimes, and measured withdrawal bounds should the implementation support? The [acceptance plan](0034/lifecycle.md) records the required evidence; these components are not a released production path.
diff --git a/rfcs/0034/credential-broker-v1-spec.md b/rfcs/0034/credential-broker-v1-spec.md
new file mode 100644
index 00000000..4e7c4ef4
--- /dev/null
+++ b/rfcs/0034/credential-broker-v1-spec.md
@@ -0,0 +1,330 @@
+# Credential Broker v1 Specification
+
+This shared contract supports [RFC 0034](../0034-github-app-credentials.md), the provider-specific [GitHub profile](github-app-v1-spec.md), and [recovery and qualification](lifecycle.md).
+
+Status: draft; upstream OCE implementation is not claimed. **Must** identifies a conformance requirement.
+
+## Scope and ownership
+
+V1 manages credentials for admitted external access through an internal issuer behind the Namespace-scoped `SecretBroker`. It adds no public Token, Lease, Issuer, or permission resource. OCC identities, resource authorization, workload assignments, and the logical work records proposed by RFC 0036 remain authoritative.
+
+| Owner | Responsibility |
+| --- | --- |
+| OCC/IAM | Sole platform authorizer; configuration, resource lifecycle, canonical execution assignments, and current operation decisions. |
+| Proposed `CredentialGatewayDriver` | Installation-selected composition of mediation and broker/issuer lifecycle through admitted handles. See [configuration and Driver contract](repository-configuration.md). |
+| SecretBroker | Consume authorization; coordinate protected custody, inventory, delivery/use, and cleanup. |
+| Issuer | Perform authorized provider operations. |
+| `SecretDriver` | Manage backend storage. Protected custody and durable inventory also require the guarantees below. |
+| `ServiceAccountDriver` | Provision accounts. |
+
+Trusted platform services host the broker, issuer, and protected-material client outside Agent execution. The proposed credential gateway is distinct from the Agent messaging gateway. One deployment may cohost broker and mediator; routing messages confers no credential authority. The GitHub profile's host connector also runs outside execution.
+
+The issuer interface is local. Protected handles have no public constructor, serialization, or workload-facing byte accessor. Remote issuers require a separately specified authenticated protocol; JSON handles confer no authority. Brokers need no dedicated process per Agent or provider. Durable state survives process replacement and supports multiple service instances.
+
+Signing or forwarding with existing credentials may reuse these authority and custody boundaries but needs separate operation contracts. V1 does not migrate model or ServiceAccount credentials.
+
+### Contracts consumed from the RFC series
+
+Use [RFC 0035's execution-assignment contract](https://github.com/openclaw/rfcs/pull/69), [RFC 0036's original-work grant](https://github.com/openclaw/rfcs/pull/70), and [RFC 0037's stop/replacement semantics](https://github.com/openclaw/rfcs/pull/71). These remain draft dependencies. The [series overview](../0027/runtime-access-overview.md) is informational. Credential mediation needs their required semantics, not the entire completed-context recovery feature or an automatic switch to SPIFFE for Agent-to-OCC authentication.
+
+| Contract | Meaning for the broker |
+| --- | --- |
+| Canonical execution assignment | OCC owns one assignment and generation. Broker bindings and runtime observations reference it; the broker cannot independently choose the current execution. |
+| Logical work | RFC 0036 owns service-owned work, immutable scope and any configured horizon, requester provenance, and child lineage. |
+| Enforcement lease | RFC 0035 owns bounded enforcement authority and its issuance/withdrawal protocol. |
+| Invocation and provider permission | Requester invocation authorization is separate from service/workload provider permission. Provider effects do not use an ambient intersection with the requester's human permissions. |
+| Data and audience | Data eligibility and result audience require their own checks. |
+| Preparation and cleanup | Preparation uses a separately admitted control purpose; cleanup uses independently retained platform authority. |
+
+Stage A requires genuine root Work, immutable Agent/revision/assignment binding,
+current per-operation authorization, cancellation/withdrawal, protected custody,
+and durable operation outcomes. An interface declaration or record ID cannot
+supply missing authority. Stages A/B may qualify root-only execution first;
+subordinate helpers require the same qualified context, scope, and cancellation.
+Separately admitted durable children and user-facing lifecycle controls follow
+in stage C. Deferring those features does not defer the minimum authority or
+cleanup contract.
+
+The broker's access lease references the original logical work and digest, exact admitted repository grant, and current execution assignment. It can only narrow that authority. Logical work may span turns; a broker access lease cannot change its work or assignment. Early replacement retires the old assignment and admits fresh Work after current authorization and predecessor termination evidence. Continuing the same Work across execution replacements requires a later qualified profile, fresh assignment authorization, and new access leases. Old assignment leases remain closed.
+
+Business-operation receipts, credential-issuance records, and lifecycle operations have distinct identities and owners. Link their references so a token refresh, reconnect, or runtime replacement cannot create another attempt at an uncertain business effect. An issuance result is not the result of the business request that needed it.
+
+## Configuration and admitted records
+
+These internal, versioned records use existing OCC identifier codecs and add no API routes. Resolve references in trusted storage, never as caller-supplied URLs. Reject unknown versions, unknown authority-affecting fields, unsupported modes, and unbounded inputs before effects.
+
+| Record | Required contents and owner |
+| --- | --- |
+| Issuer binding | OCC: Installation and Namespace, exact broker and Secret references, selected issuer implementation/profile versions, protected provider-account binding, configuration generation, and enabled state. No key or token bytes. |
+| Admitted access | OCC: immutable internal `admittedAccessRef`, Agent/revision, binding/profile versions, provider-typed resource and permission grant, allowed mode, purpose, explicit finite-or-uncapped access ceiling, and limits. Its digest commits these fields. Current policy may narrow or revoke it. |
+| Admission selection | OCC: selected admitted-access references, supported narrower permissions, and horizon. Selected IAM authorizes invocation separately from service/workload access. Session references retain provenance and any explicit cancellation relationship. |
+| Logical work | Reference to RFC 0036's authoritative service-owned work and immutable digest: original selection, owner and requester, admitted-access references, scope/horizon, and child lineage. A model turn or connection does not define its lifetime. |
+| Enforcement lease | OCC authority: bounded permission for exact work, assignment, receiver, operation profile, and original absolute deadline, with issuance ordering and withdrawal evidence. The broker cannot issue or extend it. |
+| Execution binding | Reference to OCC's canonical assignment and execution generation, exact Agent/revision and incarnation. Runtime work requires a protected link to its original work and child/request channel. |
+| Access lease | Broker: immutable original work or preparation identity, execution binding, exact admitted-access reference and digest, scope ceiling fixed at admission, current generation/version, finite deadline within every configured original work/purpose horizon, and `open` or `closed` state. It grants no use beyond valid enforcement authority. |
+| Issuance record | Inventory: stable operation and provider-attempt identities, intent digest, original lease/binding/generation, provider outcome, protected material references, actual expiry/scope evidence, delivery state, and cleanup state. |
+
+### Binding changes and enrollment
+
+Binding changes cannot silently retarget active revisions. Planned key rotation must:
+
+1. Stage protected material and verify the same provider account.
+2. Atomically select the new generation and close affected leases.
+3. Require newly admitted revisions and leases pinned to the verified generation before further use.
+
+Failed verification leaves the binding unchanged and must be reported. Independently authorized emergency disable can close access immediately. Retain issued-token/revocation material and cleanup records until obligations finish. Retiring a source key is separate from token revocation.
+
+Enrollment reports `unverified`, `ready`, `disabled`, or `degraded`, with bounded reason codes. `ready` requires verified provider binding, available protected custody and inventory, and a supported issuer profile. It neither grants access nor mints tokens; workload readiness and mode qualification remain separate.
+
+## Current authority and workload origin
+
+For each issuance, delivery, and mediated operation, the broker must authenticate the caller and enforce OCC/IAM and runtime authority for:
+
+- the exact Installation, Namespace, Agent, revision, broker, Secret, and protected provider binding;
+- the admitted execution incarnation and original logical work, or separately admitted preparation purpose;
+- the permitted resource/operation intersection, binding/profile versions, lease generation, and deadline;
+- every applicable restriction and required audit decision.
+
+Agents use their explicitly granted service/workload authority. Human roles, sessions, provider credentials, and permissions do not transfer to Agents. Requester permission to invoke the service is checked at admission and other explicitly selected invocation boundaries, not used as ambient provider authority on each effect. Missing required evidence denies. Preparation requires separate admission and cannot fabricate logical work or use a runtime lease.
+
+### Current decisions and bounded read continuity
+
+The first GitHub production profile requires current online OCC authority for
+all dispatches, including reads, issuance and maintenance. The offline exceptions
+below describe a future, separately selected and qualified broker profile; they
+are not enabled by this RFC’s first GitHub release.
+
+| Action | Required authority |
+| --- | --- |
+| Writes, new admission, enforcement/access-lease renewal, expansion, and new execution assignment | Current authority. |
+| Existing application reads during an authority outage | An expressly qualified, unexpired enforcement lease, with all required evidence. |
+| Credential maintenance during an authority outage | The expressly preauthorized read-only exception below. Native delivery is ineligible. |
+
+For continued reads, protected origin, locally enforced withdrawal, operation semantics, scope, inventory, approval, freshness, and all other required evidence still apply. An HTTP method alone does not classify an operation as a read. Missing or untrustworthy clock/revocation state requires synchronization before serving.
+
+This future bounded read profile would extend RFC 0027's denial on unavailable authority; it is not an existing platform guarantee. Each lease fits every configured original work and ancestor horizon, purpose/stop deadlines, and every applicable withdrawal target after clock and enforcement allowance. Ordinary profiles may target minutes and sensitive profiles seconds; exact numerical bounds need qualification. Allocated operation budgets require durable consumption across restart. A lease cannot substitute for required live approval, freshness, or provider checks.
+
+Trusted credential maintenance may preserve those existing reads only when expressly preauthorized under the same enforcement lease. It must:
+
+- Admit no new work, broader scope, or later authority deadline.
+- Use an enforceable read-only credential profile; offline reuse or replacement of write-capable credentials is forbidden.
+- Satisfy custody, inventory, overlap limits, unknown-issuance holds, and provider-evidence requirements.
+
+Otherwise issuance denies during the outage.
+
+### Scope, narrowing, and recovery
+
+Effective access intersects service/workload authority, admitted revision grants, the original work selection, and applicable restrictions, using current decisions or the qualified read lease above. Each work/assignment receives fresh access leases for its exact selected grants. Every `beginAccess`, including the first for a grant, requires current authority and checks the retained original selection. Policy recovery permits use only within unchanged scope and still-open authority; it cannot reopen a closed lease.
+
+Enforcement expiry stops dispatch without itself completing logical work. Current authority may issue fresh enforcement evidence for still-open work and an eligible assignment; an independently unexpired, open broker access lease may then serve it. This does not reopen an expired enforcement lease, a closed access lease, or completed work.
+
+The lease's scope ceiling is immutable. Each issuance/use computes current effective scope within that ceiling and selects a supported provider profile. Policy narrowing changes eligible operations and credentials, not the recorded ceiling.
+
+| Condition | Required behavior |
+| --- | --- |
+| An open lease supports a narrower credential | It may issue within existing limits; record each issuance's exact scope and cache key. |
+| The permission intersection is unsupported | Deny; never round up permissions. |
+| A credential exceeds current effective scope | Make it ineligible, mark it cleanup-only, and revoke it. Policy recovery cannot return it to use. |
+| A native copy was already delivered | It remains provider-valid until actual revocation or expiry. |
+| Narrowing, renewal, or later policy recovery | Continue enforcing overlap limits and unknown-issuance holds. |
+
+A wider selection requires fresh work admission within current Agent authority. In the first GitHub profile, both permission increases and decreases also require a fresh Pod/gVisor sandbox and eligible context before the changed authority serves. Durable closure denies subsequent local admission; effective withdrawal requires the selected profile's accepting-service or expiry evidence. Replacing only a container in the old Pod is insufficient. Existing work and renewals cannot exceed their original selection. Logical-work closure closes its affected access leases. A session or turn ending closes work only when its admitted lifecycle explicitly requires that relationship. Preparation uses its separately admitted selection.
+
+### Protected work attribution
+
+Handles, unexpired identity certificates, caller-supplied work IDs, and ordinary cached decisions do not establish authority. A qualified enforcement lease requires its own protected issuance and withdrawal evidence.
+
+Container identity cannot distinguish work sharing a container. The runtime must protect the link between each credentialed effect and its original admitted work; old requests cannot borrow later work's authority. Issuers cannot supply missing origin proof.
+
+### One effective grant, two enforcement points
+
+Issuer permission selection and mediator request checks must derive from the same versioned grant, original selection, and applicable narrowing. A trusted protocol adapter validates each request and supplies canonical resource identities, operation, policy-relevant arguments, and an immutable request digest. OCC/IAM or its qualified read enforcement lease authorizes those facts; the broker consumes the exact effect permit at dispatch. Caller labels and parsed data confer no authority.
+
+Each supported provider operation must declare required permissions, constraints, read/write behavior, and uncertain-outcome handling. This protocol catalog has no policy authority. Unsupported constraints deny admission or the affected operation. Permission failures cannot trigger broader credentials, another account, or a less restrictive mode. Wider grants require authorized admission and new work.
+
+### Persistent processes and background work
+
+A process may persist across turns under its original Work. Lease closure denies new credentialed effects and starts cleanup even if a process or connection survives. Neither survival nor later work renews closed authority. Workspace replacement requires Compute to observe previous writers stopped.
+
+#### Reusable workers
+
+Each request belongs to explicitly admitted logical work with its own immutable selection and enforcement authority. Permissions do not carry forward between work records. Shared state must satisfy the admitted baseline; private data or additional authority requires qualified isolation.
+
+#### Long-lived work and attached children
+
+Service-owned work may outlive the initiating turn within its original scope. Execution and work may be explicitly uncapped; every configured horizon remains immutable. Broker/enforcement leases, credentials, and operation bounds stay finite. Stages A/B permit only qualified subordinate helpers sharing root context, scope, and cancellation; they do not receive independent durable Work. The following separately admitted child behavior belongs to stage C. Each attached child has its own admitted work record and immutable lineage. Fresh child renewal requires current authority and open, authorized logical ancestors; it does not require a live coordinator process or an unexpired parent execution lease. Ancestor cancellation withdraws descendants. Independent work requires its own admission.
+
+RFC 0036 owns work admission, child lineage, and cancellation relationships. The admission producer and protected dispatch mechanism require implementation and qualification. The broker cannot invent work or silently detach children. RFC 0037's completed-state recovery supplies no authority to resume provider operations; separately admitted finite delivery has its own exact scope and current write authorization.
+
+#### Required dispatch boundary
+
+A mutable current-turn pointer or workload-selected handle cannot establish work attribution. A trusted dispatcher must own the authorized request boundary, or differently authorized work needs execution isolation. Request labels cannot isolate mutually untrusted computations in a shared process.
+
+Without this boundary, restrict the process to one immutable authority context and deny after closure; mixed-authority reuse is unsupported. Qualification must cover concurrency, queued requests, cancellation, reconnects, and restart.
+
+## Broker operations
+
+These required local ports may adapt existing methods without adding another authority or inventory store.
+
+| Operation | Required input | Result and behavior |
+| --- | --- | --- |
+| `beginAccess` | Authenticated admission context; original work/preparation reference; exact `admittedAccessRef`, requested scope ceiling and execution binding; stable request ID. | Resolve authoritative records, check current authority, commit the authorized ceiling and unique lease binding, and return an opaque reference and deadline. |
+| `renewAccess` | Same original binding, lease reference, expected version, stable request ID. | Recheck authority and conditionally advance version/deadline within every configured original horizon. Preserve principal, purpose, resources, mode, and incarnation. Closed leases cannot reopen. |
+| `acquireCredential` | Authorized operation, open access lease/version, enforcement evidence, exact provider-typed grant. | Select an eligible recorded credential or run the durable issuance protocol. During authority outage, allow only the expressly preauthorized read-only maintenance exception. Return a protected reference to the trusted delivery/forwarding owner only. |
+| `deliverNative` | Current original authority, exact recorded credential and lease, immutable receiving child/channel, delivery ID. | Require admitted native mode and durably committed delivery intent before release on that exact channel. Return safe delivery status separately from issuance status. |
+| `authorizeUse` | Current authority or qualified read enforcement lease, original work binding, access lease/version, validated provider operation and request digest. | Authorize one mediated dispatch; the trusted protocol adapter uses protected credentials. It cannot expose an arbitrary signing or forwarding endpoint. |
+| `closeAccess` | Exact lease/version and authenticated lifecycle/cancel authority, cause, operation ID. | Commit terminal closure and cleanup obligations. Return local closure status separately from provider revocation and execution termination. |
+| `readStatus` | Authorized reader and exact operation/lease reference. | Return safe state and evidence metadata. Readback cannot authorize another provider attempt. |
+| `listOutstanding` | Existing management authority for the original ownership scope, binding/resource filter, bounded page size and snapshot cursor. | Enumerate unresolved records, including tombstones, without exposing protected material or requiring the deleted resource to exist. Read authority grants no cleanup effect. |
+
+### Management and status
+
+The accepting authority creates current-authorization context; caller fields or type brands cannot establish it. Management, workload-use, read, and cleanup capabilities are distinct.
+
+Management status includes original ownership, safe operation IDs, blocked scope, cause, evidenced/unproven expiry, last/next cleanup attempt, and authority/evidence needed to resolve a hold. This management path and custody responsibility survive resource deletion.
+
+### Operation results
+
+Every mutation and effect requires a stable request/operation ID and immutable intent digest; updates require expected record versions. Results use this closed family:
+
+| Result | Meaning |
+| --- | --- |
+| `ok` | Known committed operation, resulting version, and method-specific safe result. Protected references go only to the authorized local consumer. |
+| `denied` | Current authority or profile forbids this call; no new effect is admitted. Existing obligations from earlier calls remain. |
+| `conflict` | Request ID reused with different intent, or a new update names a stale version; no new effect is admitted. |
+| `unavailable` | A dependency is unavailable and evidence proves this call admitted no effect. |
+| `indeterminate` | An identified provider, commit, or delivery phase may have acted. Return its original operation reference and safe known state for reconciliation; do not replay. |
+
+### Lease identity and retries
+
+The unique access-lease key is:
+
+```text
+(Namespace, original work or preparation operation,
+ execution assignment/generation, broker binding, admittedAccessRef)
+```
+
+`admittedAccessRef` identifies an OCC-owned immutable grant, never a caller alias or profile name. Repositories sharing a profile still require distinct references and leases.
+
+- Look up identical operations before comparing expected versions. Lost begin/renew responses read known results under fresh authority.
+- Changing an immutable binding or scope ceiling conflicts even with a new request ID for the same lease key.
+- Renewal changes only the permitted deadline/version; recheck current effective scope separately.
+- Readback returns known version/state, `unresolved`, or `not-found`. `not-found` does not prove that no earlier effect occurred.
+- Listing uses a stable snapshot and records late obligations separately to prevent omissions during concurrent cleanup.
+
+## Issuer interface
+
+Each issuer exposes a fixed versioned profile and these ports. Broker calls are authorized and bounded; issuers cannot broaden accounts or grants.
+
+| Port | Contract |
+| --- | --- |
+| `capabilities` | Declares the provider-typed scope schema, fixed or requested lifetime semantics, individual/broader/unsupported revocation, observation support, and any evidenced idempotency behavior. A declaration is not qualification. |
+| `issue` | Takes the recorded issuance/provider-attempt IDs and intent digest, exact binding/profile generation and authorized effective scope within the lease ceiling, protected material capability, current one-operation permit, deadline, and cancellation signal. |
+| `revoke` | Takes the exact issued record and protected revocation capability, recorded cleanup claim/provider-attempt IDs, independently authorized cleanup responsibility, deadline, and cancellation signal. |
+| `observe`, if supported | Reads an exact earlier operation or credential's outcome under bounded read authority, without repeating its effect. |
+
+### Issuer outcomes
+
+`issue` returns one of:
+
+| Result | Required evidence and handling |
+| --- | --- |
+| `issued` | Protected credential/revocation references, returned scope, actual expiry or an explicitly supported expiry classification, and bounded provider evidence. |
+| `not-dispatched` | Evidence that no request crossed the provider boundary. |
+| `rejected` | Definitive evidence that the provider created no credential. |
+| `unknown` | The provider may have created a credential. Retain available protected material and evidence without enabling use. |
+
+`revoke` returns `confirmed`, `pending`, `unknown`, or `failed`, with evidence and a safe reason. Declare unsupported revocation before profile admission. `observe` returns evidence or explicit unresolved status. Aborts and exceptions do not prove that the provider did nothing.
+
+Provider success does not establish inventory persistence or delivery. The broker validates returned scope and expiry, retaining unexpected output only for cleanup. Providers unable to meet the selected native-exposure or mediated-use policy remain unavailable. Broader administrative revocation requires separate scope authorization and cannot be an automatic fallback.
+
+## Durable issuance and dispatch
+
+### 1. Reserve
+
+Check current authority, or the expressly preauthorized read-maintenance authority, plus limits and audit readiness. Before any provider call, commit issuance intent bound to the original lease, exact scope, generation, and operation.
+
+### 2. Claim
+
+Commit one provider-attempt claim with conditional version checks. Replicas and retries must resolve the same operation. Expired worker claims and missing acknowledgements do not prove no dispatch occurred.
+
+### 3. Dispatch
+
+The existing authority owner supplies a bounded operation permit, directly or through qualified local read enforcement. The broker consumes it for the exact request at dispatch, ordered against applicable closure and invalidation:
+
+- Locally observed withdrawal or expiry before consumption denies.
+- Consumption first means an in-flight operation may finish.
+- Disconnected read holders enforce the original deadline and selected withdrawal bound; write permits require current authority.
+
+Cancellation cannot promise distributed rollback.
+
+### 4. Record
+
+Before use/delivery, retain accepted material in protected durable custody and commit its inventory record, actual scope, and expiry. Late results after closure or rotation retain the original attempt and enter cleanup. Reconcile partial or uncertain persistence by exact operation identity.
+
+### 5. Use or release
+
+Validate the credential against the original work and applicable enforcement evidence. Delivery intent requires a known durable outer commit before the first byte or release callback; returning from an uncommitted transaction is insufficient. Unknown commitment suppresses release until exact readback.
+
+Enforce use/delivery authority at the actual boundary. Cancellation between mint and release must not expose credentials to later work.
+
+### Uncertainty and durable inventory
+
+Identical retries return or reconcile the original operation; different intent digests conflict. Provider profiles define safe retries after definitive no-effect evidence. `unknown`, timeout, new request IDs, or absent local read results never authorize reminting. Providers have no generic exactly-once guarantee.
+
+Inventory must retain outstanding and uncertain obligations across restart and deletion. Conditional claims, protected custody, and audit persistence must define commit/readback behavior. Insufficient capacity, audit, or storage availability denies new effects; obligations cannot be evicted.
+
+Token values, keys, authorization headers, and handle secrets cannot enter ordinary resource records, logs, metrics, or audit payloads.
+
+## Replacement, closure, and cleanup
+
+### Credential replacement
+
+Replacement issues a new credential under the same still-authorized lease without renewing it, revoking predecessors, or replaying failed business operations. Track every predecessor and successor; bound overlap per profile. Caches may reuse only exact permitted scope/binding/lease matches and cannot cache authority.
+
+### Closure and invalidation
+
+Access-lease closure or expiry, grant withdrawal, binding rotation, incarnation retirement, and explicit disable prevent new use/delivery and require cleanup of every affected issued or uncertain credential. Commit invalidation and a complete inventory-scan obligation together, including racing/late results. Resource deletion retains a tombstone, protected references, and cleanup responsibility.
+
+### Agent stop and result delivery
+
+Stage C introduces the user-facing Stop task / Stop Agent / Start Agent controls under RFC 0037. Stages A/B still require cancellation, authority withdrawal, and safe execution retirement. The following drain and completed-delivery behavior applies only to a separately admitted lifecycle profile. An Agent stop first closes admission of new work. If a selected graceful-stop profile admits finite drain, existing work may use or replace eligible credentials only within its unchanged original scope, enforcement evidence, and recorded drain deadline. Authority renewal requires current decisions and cannot extend the stop deadline. Completion, deadline, cancellation, disable, or retirement closes affected authority.
+
+The accepting-service protocol must order runtime-purpose withdrawal, work closure, and broker dispatch, including qualified disconnected readers and their withdrawal bounds. An open connection, renewed SVID, or refreshed GitHub token cannot bypass those bounds.
+
+An explicitly selected graceful-stop delivery profile preserves pending delivery of an already completed result when its separate finite responsibility was admitted before work closure; it cannot keep computation's access leases open. Any GitHub write used for that delivery needs its own exact admitted scope and current authority. Cancellation or security revocation withdraws affected delivery even if the Agent is already stopped. Already admitted provider effects and independently authorized cleanup remain separately tracked.
+
+### Cleanup authority
+
+Cleanup uses separately authenticated platform lifecycle authority limited to reducing the exact recorded access. It survives revocation of the initiating human and cannot issue replacements or perform user work. Durably claim and record each attempt; takeover must resolve or safely account for earlier uncertain attempts before dispatch. Claim timeout alone is not success.
+
+### Independent status dimensions
+
+Keep these status dimensions independent:
+
+| Dimension | States |
+| --- | --- |
+| Authorization | `open`, `closed` with cause and commit time. |
+| Issuance | `reserved`, `dispatched`, `issued`, `not-issued`, `unknown`. |
+| Delivery/use | `not-started`, `admitted`, `completed`, `unknown`, or `denied`. |
+| Cleanup | `not-required`, `pending`, `confirmed-revoked`, `confirmed-expired`, `unknown`, or `action-required`. |
+| Execution | Supplied independently by Compute: running, stopping, observed stopped, or unresolved. A closed lease does not imply a stopped process. |
+
+Expiry requires a timestamp and provenance; otherwise it is unproven. Completion requires that evidenced time to have elapsed, including the selected clock uncertainty allowance. Neither a future expiry nor guessed issue time plus nominal TTL proves completion.
+
+## Issuer service lifecycle
+
+| Stage | Required behavior |
+| --- | --- |
+| Startup | Validate the fixed issuer profile and dependencies before serving. |
+| `quiesce` | Stop admitting local calls and cancel/drain bounded in-flight work while retaining outcome records. |
+| `dispose` | Release local clients and material handles without implying token revocation. |
+| Restart | Resume from durable inventory under fresh service and cleanup authority. Cached permission decisions cannot revive. |
+
+Shutdown reports local completion separately from cleanup obligations. Unavailable issuers or backends report degradation without fallback to another account, issuer, credential class, or access mode.
+
+## Versioning and conformance
+
+V1 profile identity includes interface and provider schema versions. Reject unsupported authority-bearing fields and capability combinations. Backend, authority, and runtime replacements must satisfy the lifecycle and evidence rules as well as method signatures.
+
+The selected provider and mode determine required provider, client, preparation, and mediation checks in [the acceptance matrix](lifecycle.md#acceptance-matrix). Parser, mock, and component checks cannot establish real current authority, durable transactions, provider revocation, or origin binding.
diff --git a/rfcs/0034/credential-flow.dot b/rfcs/0034/credential-flow.dot
new file mode 100644
index 00000000..c9785805
--- /dev/null
+++ b/rfcs/0034/credential-flow.dot
@@ -0,0 +1,59 @@
+digraph CredentialFlow {
+ graph [
+ rankdir=LR,
+ bgcolor="white",
+ fontname="DejaVu Sans",
+ fontsize=14,
+ pad=0.12,
+ nodesep=0.28,
+ ranksep=0.38,
+ dpi=100,
+ label="Credential access is separate from the Agent messaging gateway.",
+ labelloc=b
+ ];
+ node [
+ shape=box,
+ style="rounded,filled",
+ fontname="DejaVu Sans",
+ fontsize=14,
+ color="#637580",
+ fontcolor="#243541",
+ fillcolor="#EFF4F7",
+ penwidth=1.2,
+ margin="0.14,0.12"
+ ];
+ edge [
+ fontname="DejaVu Sans",
+ fontsize=11,
+ color="#566C78",
+ fontcolor="#425964",
+ arrowsize=0.65,
+ penwidth=1.2
+ ];
+
+ agent [label="Agent execution\nManaged reads / coding\nNo GitHub tokens", fillcolor="#F8ECEF", color="#B87687"];
+ github [label="GitHub\nEnforce token scope\nand repository rules"];
+
+ subgraph cluster_trusted {
+ label="Trusted platform services outside Agent execution";
+ labelloc=t;
+ color="#BBCBCF";
+ fontcolor="#425964";
+ style="rounded";
+ margin=14;
+
+ origin [label="Trusted host connector\nVerify execution\nand originating Work", fillcolor="#EAF5F2", color="#5B978A"];
+ mediator [label="CredentialGatewayDriver (proposed)\nSelected by Installation\nBroker + mediator may cohost\nCheck operation; insert tokens", fillcolor="#EAF5F2", color="#5B978A"];
+ authority [label="OCC authority\nOnline each dispatch\nBound enforcement", fillcolor="#EAF0F9", color="#7192B8"];
+
+ publisher [label="Trusted publisher (B)\nExact human approval\nSeparate push / PR effects", fillcolor="#FAF0D9", color="#B49A59"];
+ publisher -> mediator [label="approved effect"];
+ { rank=same; authority; mediator; }
+ authority -> mediator [constraint=false];
+ origin -> mediator [label="protected origin"];
+ }
+
+ agent -> origin [label="A: token-free\nmetadata / clone / fetch"];
+ agent -> publisher [label="B: candidate"];
+ mediator -> github [label="scoped\nrequest"];
+}
diff --git a/rfcs/0034/credential-flow.png b/rfcs/0034/credential-flow.png
new file mode 100644
index 00000000..e9306bd1
Binary files /dev/null and b/rfcs/0034/credential-flow.png differ
diff --git a/rfcs/0034/github-app-v1-spec.md b/rfcs/0034/github-app-v1-spec.md
new file mode 100644
index 00000000..8df4a43f
--- /dev/null
+++ b/rfcs/0034/github-app-v1-spec.md
@@ -0,0 +1,630 @@
+# GitHub App Access v1 Specification
+
+Provider-specific contract for [RFC 0034](../0034-github-app-credentials.md), using
+[Credential Broker v1](credential-broker-v1-spec.md). Status: draft. **Must**
+identifies a conformance requirement. This spec describes target behavior;
+publication qualifies neither mode.
+
+## Scope and proposed release selection
+
+V1 targets organization-managed GitHub.com App installations, one repository per
+credential, HTTPS Git, and the bounded Git/`gh` workflow below. Personal
+credentials, GitHub Enterprise hosts, SSH, LFS, submodules, arbitrary uploads,
+and unlisted operations are excluded.
+
+| Mode | Release scope |
+| --- | --- |
+| Mediated | Required in production under [RFC 0027's credential boundary](../0027-openclaw-enterprise.md#secret-access). |
+| Native | Development/testing only; never a production fallback. |
+
+Delivery is sequential, with a separate production gate for each stage:
+
+| Stage | Qualified scope |
+| --- | --- |
+| A — Managed reads | Dedicated Kubernetes/gVisor execution; mediated repository metadata and HTTPS clone/fetch with verified preparation. |
+| B — Coding workflow | Selected issue/PR reads and trusted **Approve and publish** for an exact candidate. Add GraphQL read shapes only where qualified commands require them. |
+| C — Durable work | Broader durable Work and separately admitted children, plus Stop task / Stop Agent / Start Agent controls. |
+
+Stages A and B require genuine root Work and current operation authority.
+Subordinate helpers may operate only within that root's qualified context,
+scope, and cancellation; root-only execution may qualify first. Helpers do not
+receive independent durable Work. Local Git operations remain ordinary Git.
+Transparent `git push` and `gh pr create` adapters are later work using the same
+publisher and effect records. Model-credential proxies and token-forwarding
+components alone do not establish production GitHub mediation.
+
+Execution and logical work may be explicitly uncapped. Access/enforcement leases,
+provider credentials, and operation time/resource limits remain finite and fit
+every configured original horizon. No universal Agent or job duration is imposed.
+
+## Client versions
+
+Git 2.55.0 and `gh` 2.93.0 are the proposed qualification pins for both modes.
+Evidence must pin binaries, image digests, configuration, and exact command
+variants. Another version needs its own compatibility evidence and cannot
+qualify these pins. [Git credential helper interface](https://git-scm.com/docs/gitcredentials),
+[gh environment](https://cli.github.com/manual/gh_help_environment)
+
+## Enrollment and configuration
+
+### Enrollment
+
+The [proposed Agent configuration](repository-configuration.md) is admin-managed
+and frozen into `AgentRevision`; it is not an existing public repository field.
+OCC authorizes the exact Namespace administrator, Agent/Configuration operation,
+and each referenced binding, broker, and Secret. Invocation allowlists and the
+App's broader installation access cannot replace these service grants.
+
+1. An Installation operator selects the issuer and trusted GitHub.com endpoints.
+ The organization installs the App on explicit repositories within supported
+ permission profiles.
+2. A Namespace administrator binds the exact App installation to its
+ `SecretBroker`, referencing protected signing material through the selected
+ backend. OCC verifies Namespace ownership and authorization for the broker,
+ Secret, and integration binding. Public resources and revisions contain only
+ references and metadata.
+3. The issuer verifies App/installation identity, organization ownership,
+ repository membership, and available permissions against GitHub. Unavailable
+ checks report unverified or degraded enrollment. Configuration alone is not
+ verification; enrollment neither mints a runtime token nor activates an Agent.
+4. OCC admits one access record per repository grant for an Agent revision,
+ recording the binding/profile versions, repository ID and canonical name,
+ permission profile, mode, checkout commit, lease horizon, and configured
+ limits. Authorize every referenced resource, including when a revision has
+ several grants. Missing support or unresolved scope denies admission.
+
+### Admitted data
+
+Provider data has this closed shape. Field names are illustrative; this is not a
+public REST API:
+
+```ts
+type GitHubAccessV1 = {
+ schemaVersion: 1;
+ issuerBindingRef: OccReference;
+ issuerBindingGeneration: number;
+ providerProfileVersion: 1;
+ repositoryId: number;
+ repositoryName: string; // verified owner/name; ID is authoritative
+ permissionProfile: "checkout" | "views" | "coding";
+ accessMode: "native" | "mediated";
+ checkoutCommit: string; // resolved full object ID for the admitted repository
+ publicationPolicyDigest: string; // disabled or human-approval policy frozen in revision
+ publicationPolicyGeneration: number;
+ accessHorizon: Timestamp | null; // explicit uncapped grant ceiling; leases stay finite
+};
+```
+
+`OccReference` and `Timestamp` use validated OCC codecs. Publication policy is
+frozen from the proposed selection: stage A permits only `disabled`; stage B
+may admit the configured human-approval policy. The binding resolves
+host, App ID, installation ID, organization identity, and protected key version.
+Workload requests cannot supply another host, account, key reference, permission
+map, or longer horizon. Unknown fields and malformed or cross-Namespace
+references deny.
+
+### Configuration changes
+
+Visibility changes, transfers, and enrollment changes require denial and
+revalidation of affected access. Display-name changes cannot silently redirect a
+grant. Configuration/profile edits require new admitted revisions; revocation
+can deny active access immediately. Both permission increases and decreases require
+a fresh Pod/gVisor sandbox and eligible context before serving the changed
+authority; a new container in the old Pod is insufficient. Existing connections,
+background processes, caches, and queued requests cannot inherit the new context.
+
+Planned key rotation follows the
+[shared sequence](credential-broker-v1-spec.md#configuration-and-admitted-records):
+verify the replacement against the same App/installation, select its generation
+and close old leases, then admit new revisions. Failed verification preserves
+the working binding.
+
+## Session scope and multiple repositories
+
+### Admission and grant selection
+
+At logical-work admission, OCC records the selected immutable repository grants,
+supported narrower profiles, and any configured original horizon. IAM authorizes requester
+invocation separately from service/workload repository access. Chat requests,
+local remotes, and personal GitHub access confer no provider authority.
+
+Each work/assignment derives a separate access lease for each selected repository
+under the [shared authority rules](credential-broker-v1-spec.md#current-authority-and-workload-origin).
+Session references retain provenance and any explicitly admitted cancellation
+relationship; ending a model turn does not close logical work.
+
+Each command selects one explicit grant and a token scoped to it; ambiguous
+selection denies. No session-wide token combines permissions.
+
+| Example grants | Allowed work |
+| --- | --- |
+| `coding` on `org/service`; `views` on `org/library` | Pushes and PRs in `service`; reads only in `library`. |
+| `coding` on both repositories | Changes use two branches and two same-repository PRs. |
+
+### Trusted publication
+
+The first write interface is **Approve and publish**, backed by a trusted
+publisher outside Agent execution. Freeze and retain one immutable candidate
+before requesting approval. Its action digest binds:
+
+- Original work, invocation, execution assignment, authority revision, and scope.
+- Stable numeric repository and App installation identity.
+- Exact base ref and captured base OID; exact allowed target ref and expected
+ prior remote OID, or explicit authorized branch creation.
+- Proposed commit OID, complete retained object manifest and pack digest, with
+ finite object, byte, path, and capture limits.
+- Exact draft PR title/body and ordered actions: push, then create draft PR.
+
+Stage B requires explicit approval from a configured, currently authorized
+human. The requester may approve if eligible; the Agent and its helpers cannot
+self-approve. Eligibility requires current IAM `operate` permission on the
+exact Agent and membership in its configured human approver list, as proposed
+in [the configuration contract](repository-configuration.md#publication-modes-and-delivery). Configure exact repository and base/target ref allowlists,
+branch-creation permission, eligible human principals, and a finite approval
+lifetime. Missing policy denies publication. OCC and the selected IAM authority
+authenticate the approver and commit approval durably for that exact digest;
+a candidate ID, signature on a Git commit, or workload claim is not approval.
+Changed content, base, ref, expected prior tip, or PR metadata invalidates approval
+for the changed candidate. No broad branch-write permission substitutes for these
+checks. Validate and retain bounded, complete Git object graphs outside execution
+without repository hooks, filters, helpers, or ambient configuration. Isolate
+untrusted Git parsing from signing-key and credential custody.
+
+At each effect, recheck current online work, approval, IAM, and destination
+controls. Push uses one atomic expected-old ref update to the exact approved OID,
+with a separate fast-forward requirement. A preflight read or generic non-force
+update is insufficient. See the [Git push semantics](https://git-scm.com/docs/git-push)
+and [pack protocol](https://git-scm.com/docs/pack-protocol). Deny multiple refs, force updates, deletion, and tags.
+Only a confirmed, recorded push permits a separate draft-PR effect with explicit
+same-repository base/head and exact approved metadata. Do not implicitly fork or
+push. Unknown effects retain their original claims and observations and never
+trigger automatic replay, including after retries or restart.
+
+PR creation uses moving branch names: this proposal does not assume an atomic
+base/head OID precondition in GitHub's PR API. Retain and compare the attributed
+response's repository, refs, OIDs, title, body, and draft state with the candidate.
+A mismatch or unattributable result remains unknown; preserve the confirmed push
+as its own outcome. Matching an existing PR's text is not evidence this attempt
+created it. Fork-to-upstream PRs remain unsupported.
+[gh PR creation](https://cli.github.com/manual/gh_pr_create)
+
+#### Later authorization modes
+
+Two future modes may be selected independently: require a human other than the
+requester, or automatically authorize narrowly configured operations, such as
+an allowlisted branch push or draft PR. Automatic mode records a current policy
+decision for the exact candidate/effect without requiring per-operation human
+approval. Neither mode is enabled in the MVP, and missing policy never falls
+back to automation. Both retain current Work/IAM authority, the same destination
+and object/ref constraints, durable separate effects, and unknown-outcome rules.
+
+### Scope changes and closure
+
+Refresh and cleanup are independent per repository access lease. Removing one
+grant preserves others unless shared authority changes; closing logical work
+closes its leases and applies its admitted child-cancellation rules. Authorized
+execution replacement creates fresh assignment-bound leases after the stop
+barrier; it cannot reopen old leases. The
+[unknown-mint hold](#unknown-mint-hold) applies across aliases for the same
+provider target.
+
+Native restrictions require enforcement by GitHub permissions and repository
+rules; narrower unsupported restrictions require mediation or denial. Delivered
+native tokens retain their scope until revoke or expiry.
+
+## Preventing public publication
+
+V1 must deny public GitHub writes, including to repositories accessible to the
+App. Write destinations must be explicitly approved repository IDs in the
+enrolled organization with verified `private` visibility, or `internal` where
+explicitly approved. This applies to all grants sharing an Agent's workspace and
+context. Public reads confer no write authority; public-repository coding is
+unsupported.
+
+### Required checks
+
+- **Admission and credentials:** OCC verifies ownership and visibility before
+ admitting a write grant. The broker revalidates against GitHub before issuing
+ or delivering a write-capable token and before every mediated write. Public,
+ unknown, or unavailable visibility denies. Retain checked identity, visibility,
+ and observation time; admission snapshots or delayed webhooks alone are
+ insufficient.
+- **Every write surface:** enforce the destination rule on HTTPS pushes and
+ permitted REST/GraphQL mutations, including PR titles and bodies. Repository
+ creation, forks, transfers, and visibility changes are unsupported; no
+ administration permission is granted. Wrappers or a `github.com` allowlist
+ alone cannot enforce this rule.
+- **Changes:** ownership or visibility changes close affected leases and revoke
+ outstanding tokens, requiring revalidation and fresh admission. Delivered
+ native tokens remain governed by GitHub's permissions until actual revoke or
+ expiry, regardless of the broker's latest visibility decision.
+- **Enforcement:** the full guarantee requires the mediated checks and runtime
+ boundary below, denying direct writes, alternate credentials, and tunnel
+ bypass. Native scoped credentials and controlled clients only guard against
+ accidental wrong destinations.
+
+### Visibility race and guarantee limits
+
+Visibility checks and writes are separate operations. Organization controls must
+prevent destinations becoming public while access or accepted writes remain
+outstanding; revalidation and webhooks cannot close that race. Trusted
+administrators' deliberate publication and other permitted output channels are
+outside the guarantee. Making a repository public exposes its existing contents.
+[Repository visibility](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility)
+
+## Permissions and issuer behavior
+
+| Profile | Exact requested permissions | Intended operations |
+| --- | --- | --- |
+| `checkout` | `contents:read` | Fetch the approved repository and commit. |
+| `views` | `contents:read`, `issues:read`, `pull_requests:read` | Repository, issue, and PR reads. |
+| `coding` | `contents:write`, `issues:read`, `pull_requests:write` | Prepared-branch push and same-repository draft PR creation, plus reads. |
+
+All profiles include required `metadata:read`; workflow, administration, and
+secrets permissions are excluded. Coding tokens are not limited to drafts or
+particular branches: `contents:write` satisfies the PR-merge permission check
+even without `pull_requests:write`. The trusted publisher enforces the exact
+approved ref update and denies merge operations. GitHub repository rules with no
+App bypass provide defense in depth; they do not replace publisher constraints.
+[Merge permissions](https://docs.github.com/en/rest/pulls/pulls#merge-a-pull-request)
+
+### Issuance and validation
+
+The issuer signs an App JWT outside execution and calls
+`POST /app/installations/{id}/access_tokens` with one explicit `repository_ids`
+entry and the issuance's exact effective permissions. Validate these as a
+supported subset of the immutable lease ceiling and applicable enforcement
+authority. A `coding` ceiling narrowed to `views` must mint `views` permissions
+without changing the ceiling. Never use installation-wide defaults; unavoidable
+metadata read is the sole implicit baseline.
+
+Validate returned repository scope, permissions, and actual expiry before
+eligibility. Incomplete scope evidence or unexpected scope retains the token for
+cleanup only. [Installation token creation](https://docs.github.com/en/rest/apps/apps#create-an-installation-access-token-for-an-app)
+
+### Lifetime and revocation
+
+| Credential | Provider lifetime |
+| --- | --- |
+| App JWT | Expires within ten minutes. |
+| Installation token | Expires after one hour; no documented custom TTL parameter. |
+
+Tokens are opaque variable-length strings. Shorter OCE leases do not shorten
+provider validity; App key rotation does not revoke issued tokens.
+[App JWT](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-a-json-web-token-jwt-for-a-github-app),
+[installation token lifetime](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app)
+
+Declare new-token issuance, provider-fixed lifetime, and individual revocation
+using protected token material, without assumed mint-idempotency or lost-token
+lookup. Revoke each known token with `DELETE /installation/token`; `204` confirms
+revocation. Retain protected material through cleanup: a hash cannot call this
+endpoint. Installation suspension/uninstall requires separate operator
+authorization and is never an automatic fallback.
+[Revocation](https://docs.github.com/en/rest/apps/installations#revoke-an-installation-access-token)
+
+## Policy enforcement
+
+Enforce the [same effective grant](credential-broker-v1-spec.md#one-effective-grant-two-enforcement-points)
+at minting and on every mediated request. GitHub's token API accepts repositories
+and permission categories, without general fields for branches, arbitrary paths,
+individual mutations, current visibility, OCE work, or originating containers.
+Naming a profile cannot encode those restrictions.
+[Token parameters](https://docs.github.com/en/rest/apps/apps#create-an-installation-access-token-for-an-app)
+
+| Constraint | Enforcement |
+| --- | --- |
+| Repository and permission category | Explicit mint scope and validation of each request against the effective grant. |
+| Supported operation and parameters | Mediator validates actual Git/REST/GraphQL semantics, including same-repository targets and draft PR state. |
+| Exact publication and ref restrictions | Trusted publisher checks approved objects, exact allowed refs and expected-old update; deny merges, force, deletion, and multiple refs. GitHub rules add defense in depth. |
+| Approved non-public destination | Current ownership/visibility checks plus the organization controls required by the publication policy. |
+| Work purpose, horizon, withdrawal | Current online OCC/IAM decision for every dispatch, plus finite broker and enforcement leases. |
+| Execution origin | Trusted runtime/host mapping and enforced routing; no workload-visible proof is sufficient by possession. |
+
+### Narrowing and additions
+
+The profile is a ceiling: use supported narrower profiles for read-only work,
+never arbitrary per-request permission combinations. Never reuse or refresh
+broader tokens for narrower work. Finer operation classes require a versioned
+profile and compatible lease/cache accounting. GitHub specifies endpoint
+permissions and calls for testing actual GraphQL queries and mutations.
+[Permission guidance](https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app)
+
+Every operation added to the reviewed catalog must identify targets, provider
+permissions, request constraints, and outcome handling. Generic authenticated
+passthrough is unsupported. Unenforceable restrictions require denial or
+authorized admission of a narrower supported profile; permission errors never
+justify silently broader access.
+
+Ordinary Contents permissions lack per-token arbitrary path scope.
+App-registration `single_file` permissions configure paths but are outside this
+profile and do not establish Git compatibility. GitHub push rules may add path
+restrictions after separate qualification.
+[App registration](https://docs.github.com/en/apps/sharing-github-apps/registering-a-github-app-using-url-parameters),
+[repository rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)
+
+## Refresh and overlap
+
+### Cache identity
+
+Cache by exact binding/profile, Namespace/Agent/revision, assignment/incarnation,
+original work and access lease/purpose, repository/effective permissions, and
+generation. Never substitute broader admitted scope or share tokens across
+independently revocable leases. Every use requires current online authority, including reads and credential
+maintenance; native delivery also requires current authority.
+
+Supported narrower issuances under the same open lease have distinct exact-scope
+cache entries. All scopes share that lease's mint claim and two-credential overlap
+budget. Broader credentials retired after narrowing remain counted through actual
+revoke or evidenced expiry; no new scope resets capacity or an unknown-mint hold.
+
+### Replacement limits
+
+| Limit | Requirement |
+| --- | --- |
+| Refresh threshold | Begin replacement below five minutes remaining, while the original lease remains open. |
+| Mint concurrency | One active durable mint claim per lease; one original provider attempt per issuance. |
+| Overlap | Two credentials per lease, counting reservations, dispatched/unknown attempts, and provider-valid predecessors/successors. |
+| Capacity release | Only definite no-issuance, confirmed revocation, or evidenced expiry frees a slot. Local cache retirement does not. |
+| Full capacity | Deny minting; never evict unresolved records. Admission and status must expose these limits. |
+
+After failed refresh, the broker may serve a recorded unexpired token only while
+original authority, exact scope, and delivery/use checks pass. Do not run
+autonomous refresh after lease closure. Respect provider throttling on permitted
+retries and the shared no-remint rule for uncertain issuance.
+
+### Authority outages
+
+Require current online OCC authority for every GitHub dispatch: reads, writes,
+issuance, renewal, and credential maintenance. Existing tokens and unexpired
+leases do not permit offline dispatch. If any required authority, provider,
+custody, or inventory check is unavailable, deny the affected operation.
+Independently retained cleanup still owns its obligations and needs its own
+applicable authority; work authorization cannot stand in for cleanup authority.
+
+The shared broker's qualified offline-read/maintenance option is future profile
+work and is not enabled here. Accepted upstream operations may finish; report
+their outcomes and cleanup separately from the denied next operation.
+
+### Unknown-mint hold
+
+An unknown mint holds the stable provider target:
+
+| Target component | Identity |
+| --- | --- |
+| Platform | OCE Installation. |
+| Provider | Canonical GitHub host, App identity, GitHub installation ID. |
+| Resource | Repository ID. |
+
+The hold blocks issuance across binding aliases, Namespaces, profiles/permission
+changes, key or binding generations, revisions, incarnations, leases, and modes.
+Retain original ownership and permission evidence; configuration changes or
+renewed admission cannot bypass the hold. OCC's trusted inventory enforces it
+without disclosing another Namespace's records, prioritizing complete accounting
+over availability.
+
+Resolve the hold only with definite no-issuance evidence, evidence that expiry
+has elapsed, or verified sufficient administrative revocation. New request IDs
+and time since a timeout do not resolve it. Broader remedies require an
+identified scope and corresponding operator authorization. Other targets remain
+independent; never automatically switch accounts to bypass a hold.
+
+### Client behavior
+
+Mediated dispatches can use eligible replacement tokens without restarting the
+requester. Native mode supplies eligible tokens to new Git helper invocations
+and `gh` children; existing environments do not rotate. Dispatched operations
+may fail on expiry or revocation. Neither mode automatically replays an ambiguous
+push, PR mutation, or other write.
+
+## Native client contract
+
+The Git helper and `gh` launcher use the broker's native delivery port with a
+protected, immutable original-work and execution binding. Reject broader
+permissions, alternate credentials, unsupported remotes, or work substitution.
+Preparation helpers use a separate read-only identity.
+
+- **Git:** authenticate only canonical HTTPS GitHub remotes through the selected
+ helper. Keep credentials out of remote URLs, command arguments, persistent
+ configuration, and credential stores. Disable inherited helpers and unmanaged
+ credential fallback in the controlled client path.
+- **`gh`:** each new child receives `GH_TOKEN` in its environment only. Preserve
+ arguments and exit/signal behavior; never update existing environments or a
+ global current-turn token. Prevent inherited host/token configuration from
+ selecting another credential or destination.
+- **Custody:** helper store/erase handling must not persist material. Diagnostics
+ and failures use safe reason codes. Native workloads can read and publish
+ their tokens, so these rules cannot keep tokens out of adversarial workload
+ logs or artifacts.
+- **Failure:** denied, closed, expired, unsupported, or unavailable results fail
+ credential acquisition. Never fall back to personal credentials, App keys,
+ alternate installations, or a mediated-to-native downgrade.
+
+## Mediated origin and routing
+
+### Scoped proxy credential
+
+The first production client path uses a cryptographically unguessable, opaque
+**proxy credential**: fake at GitHub, meaningful only to the trusted credential
+gateway. It presents an existing broker access lease; it is neither a serialized
+issuer/material handle nor a connector-issued origin proof. It creates no new
+IAM grant or public token resource.
+
+After genuine Work or separate preparation admission, the gateway associates
+the credential with the exact Installation/Namespace, Agent/revision, execution
+assignment and incarnation, original Work or preparation, admitted repository,
+allowed operations, access-lease generation, and finite deadline. The association
+lives in trusted broker state and cannot be changed by the caller. Deliver the
+credential only to that admitted execution through the trusted launch or
+credential-delivery path. Enrollment alone does not authorize issuance or use.
+
+The qualified Git/gh client sends the credential through its supported HTTP
+authentication form. Qualification fixes its encoding, maximum length, and
+unambiguous parsing; duplicate or conflicting authentication fields deny. Each
+request requires all three: a valid proxy credential, the independently verified
+protected origin below matching its original execution and Work, and current
+online OCC authorization for the actual repository operation. Possession alone
+cannot establish origin or permission. Missing, unknown, expired, revoked, or
+mismatched credentials deny without anonymous, public-placeholder, or native-token
+fallback. A copied credential cannot be used from another execution while its
+original holder remains authorized.
+
+Real GitHub-token refresh may preserve the same still-valid proxy credential;
+it cannot widen scope, extend that credential's deadline, or reopen closed access.
+Proxy-credential renewal or replacement requires current authority and preserves
+the original binding within the existing lease/enforcement renewal contract.
+Closure or revocation denies subsequent dispatch even while a real token remains
+valid. Retain cleanup and already accepted upstream effect outcomes separately;
+local withdrawal cannot cancel an effect already accepted by GitHub or retract
+delivered data. Credential values never enter URLs, ordinary records, logs, or
+audit payloads. Agent-visible delivery contains only the proxy credential, never
+the App key, installation token, or protected issuer capability.
+
+### Trusted identity
+
+The proposed trusted host connector keeps its SPIFFE mTLS key outside Agent
+execution. It authenticates an exclusive runtime-owned local channel, resolves
+the actual container incarnation and original logical work through a protected
+mapping, and makes the broker request. The broker verifies its service identity
+and exact mapping; container-supplied identity headers are untrusted.
+
+Use [RFC 0035's identity and assignment contract](https://github.com/openclaw/rfcs/pull/69)
+to check three bindings separately:
+
+| Binding | Required identity |
+| --- | --- |
+| Connector | Its own service assignment. |
+| Represented execution | Agent execution assignment/generation from protected runtime evidence. |
+| Original work | [RFC 0036's original-work grant](https://github.com/openclaw/rfcs/pull/70). |
+
+A connector may represent only executions allowed by its server-owned mapping;
+its SVID cannot substitute for Agent authority. Installation configuration pins
+trust roots and permitted peers. Registration/attestation ownership, peer
+acceptance, evidence lifetime, and invalidation must be specified and qualified
+for the selected runtime. SPIFFE service authentication does not itself select a
+different Agent-to-OCC authentication profile.
+
+A shared host identity, socket pathname, Pod UID alone, same-Pod sidecar, or
+self-reported turn ID is insufficient. The mapping must change on container
+restart and distinguish sibling containers and each request's original work.
+Persistent workers require the
+[protected work-binding contract](credential-broker-v1-spec.md#persistent-processes-and-background-work);
+old queued requests cannot inherit successor authority. The dispatcher/channel
+remains a release blocker until demonstrated. Until then, constrain execution to
+one immutable admitted authority context and deny mixed-authority reuse; serial
+scheduling alone does not stop old requests inheriting new authority.
+
+SPIFFE identifies its authorized consumer and supplies private key material; an
+SVID key inside execution cannot establish copy resistance.
+[SPIFFE Workload API](https://spiffe.io/docs/latest/spiffe-specs/spiffe_workload_api/)
+
+### Runtime boundary
+
+SandboxDriver enforces routing and denies bypass through token endpoints,
+alternate brokers, direct credentialed GitHub routes, or general tunnels. Proxy
+settings establish only compatibility. Workloads receive neither GitHub material
+nor reusable connector-issued origin proofs. Native delivery must be unreachable
+or reject all mediated leases, including copied handles.
+
+The guarantee covers replay of container-visible integration credentials from
+another host/container while the original remains live. It assumes intact
+sandbox isolation and trusted host/control-plane/broker infrastructure; using
+the original authorized container as a relay is outside this guarantee.
+
+### Client transport
+
+The first deployment selects split DNS to an external trusted TLS/HTTP mediator
+for ordinary GitHub destinations. DNS answers must derive from the authenticated
+runtime attachment and current work; source IP, Pod name, or a caller receipt is
+insufficient. The mediator resolves upstream GitHub independently. DNS steering
+alone grants no operation authority: the installed network fence and mediator
+must deny cached-address, existing-connection, direct-route, and tunnel bypass.
+Qualify the complete runtime attachment and both TLS legs before release. Plain CONNECT
+cannot substitute credentials in encrypted HTTP; `GH_HOST` selects a GitHub
+host, not a generic proxy. Keep trust private to the selected runtime/client and
+validate upstream GitHub TLS independently.
+[HTTP CONNECT](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.6),
+[Git HTTP](https://git-scm.com/docs/http-protocol)
+
+## Mediated operation profile
+
+### Request validation
+
+The proxy validates the full provider operation before choosing a token:
+
+- Construct upstream URLs from trusted enrollment data; reject redirects,
+ ambiguous encodings/paths, host disagreement, and unsupported body semantics.
+- Validate the selected [proxy credential](#scoped-proxy-credential) and reject
+ other or ambiguous authentication forms. Strip that credential and all caller
+ cookies, proxy headers, and authorization before constructing the upstream
+ request. Insert the real installation token only on the independently verified
+ GitHub TLS connection; never forward the proxy credential to GitHub. Neither
+ credential presentation nor an access-lease handle authenticates origin.
+- Bound request/response size, execution time, and pagination in the selected
+ profile. Tokens must not enter downstream responses, headers, errors, logs, or
+ artifacts.
+
+### Supported surfaces
+
+| Surface | Stage and validation |
+| --- | --- |
+| HTTPS Git fetch | A: `info/refs` for `git-upload-pack` and `git-upload-pack` on the exact admitted repository. Validate service/method/path and supported protocol negotiation. Fetched history remains readable. |
+| Trusted publication | B: Freeze, approve, and publish one exact candidate through the publisher contract above. No direct Agent receive-pack or raw mutation route in the first profile. |
+| REST reads | A: exact repository metadata. B: selected commit lookup and bounded issue/PR list/view routes. Validate repository identity and route parameters, including pagination targets. |
+| GraphQL reads, if selected | B: Exact repository/issue/PR reads required by qualified commands. Use reviewed documents with constrained variables or a semantic validator covering aliases, fragments, batching, and node IDs. Arbitrary operations and mutations deny. |
+
+A `/graphql` allowlist or operation name cannot check permissions. Resolve node
+IDs to admitted repositories; reject additional operations/targets and
+unsupported protocol extensions. Arbitrary REST mutations, raw `gh api`
+passthrough, implicit fork/push, and unvalidated `gh` commands are unsupported.
+
+### Command qualification
+
+Stage A targets clone/fetch and repository metadata, including only qualified
+`gh api` read shapes. Stage B adds `gh repo view`, bounded `gh issue list/view`,
+and `gh pr view` only with their exact request manifests. Local history is
+permitted; strict history isolation is an optional separate mode. Integration
+uses explicit fast-forward updates; rebase requires configuration and explicit
+dirty/conflict handling. Publish argument variants and observed manifests for
+pinned clients. These remain compatibility targets pending qualification.
+
+Later `git push` / `gh pr create` adapters must capture and validate the complete
+candidate before any write, then use the same approval and publication effects.
+Unapproved calls return approval-required or use a separately bounded pending
+interaction. Retry references the original immutable candidate/effect; it cannot
+hold an unbounded stream or create a new effect. Qualify receive-pack framing,
+pack/object limits, exact one-ref mapping, PR request shapes, and lost-response
+behavior independently before enabling these adapters.
+[Pinned gh repository queries](https://github.com/cli/cli/blob/f96972ce1c11fdb8eaa556257fde962a363dffde/api/queries_repo.go)
+
+## Repository preparation
+
+1. **Authorize and contain.** OCC authorizes a separate read-only preparation
+ lease for the admitted candidate. Compute provides execution and an empty
+ candidate-owned staging volume; SandboxDriver establishes and verifies
+ admitted containment. OCC gates checkout and Harness startup on the required
+ observations. Native preparation uses an inventoried token; mediation
+ requires runtime-equivalent origin/routing guarantees.
+2. **Fetch and verify.** Fetch the exact repository and resolved commit using
+ fixed configuration and safe argument arrays. Disable repository hooks, setup
+ scripts, submodules, and LFS. Reject redirects, traversal, symlink escapes, and
+ inherited helpers. Verify the commit and repository identity, stop
+ preparation, and close its lease before handoff. Neither credentials nor
+ preparation authority enter the resulting checkout.
+3. **Promote safely.** Preserve the active workspace and uncommitted changes.
+ Compute owns the explicit staging/promotion protocol and must observe
+ previous writers terminate before replacement. Backends without safe handoff
+ are unsupported. Preparation failure preserves the serving revision; rollback
+ requires fresh admission and leases, never revived tokens or execution
+ generations.
+
+## Acceptance
+
+Stage A requires the shared broker, real provider scope/revocation evidence,
+safe preparation, genuine root Work and operation authority, online-only
+dispatch, mediated origin replay negatives, and its selected read protocols.
+Stage B adds selected coding reads and exact-candidate human-approved
+publication. Stage C separately qualifies durable children and lifecycle
+controls; active-session migration/replay remains later scope. Unsupported
+helper/child/execution combinations deny admission. Native helper evidence
+supports development/testing only. An issuer or helper alone cannot satisfy
+the [acceptance matrix](lifecycle.md#acceptance-matrix).
diff --git a/rfcs/0034/lifecycle.md b/rfcs/0034/lifecycle.md
new file mode 100644
index 00000000..ed6c7c6d
--- /dev/null
+++ b/rfcs/0034/lifecycle.md
@@ -0,0 +1,500 @@
+# Credential Lifecycle: Recovery and Qualification
+
+Draft recovery and acceptance plan for [RFC 0034](../0034-github-app-credentials.md).
+The [broker specification](credential-broker-v1-spec.md) defines shared
+requirements; the [GitHub specification](github-app-v1-spec.md) defines provider
+and client behavior. This appendix describes how to test them.
+
+## Production scope
+
+Production requires the [mediated profile](github-app-v1-spec.md#mediated-operation-profile)
+and online OCC authority for every dispatch. Stage A qualifies repository
+metadata and clone/fetch; B adds the coding workflow and exact-candidate
+human-approved publication; C adds broader durable Work, separately admitted
+children, and Stop task / Stop Agent / Start Agent controls. Native delivery
+is development/testing only.
+
+Genuine root Work, exact revision/assignment binding, current operation grants,
+cancellation/withdrawal, custody, and durable outcomes are required from A.
+Root-only execution may qualify first; subordinate helpers require the same
+qualified context, scope, and cancellation. Active-session migration/replay and
+offline read continuity remain later work, outside these initial GitHub gates.
+The [acceptance matrix](#acceptance-matrix)
+identifies required tests; [release evidence](#acceptance-evidence-and-current-implementation-limits)
+records their results.
+
+## Authority and identity
+
+The [broker contract](credential-broker-v1-spec.md) distinguishes these lifetimes:
+
+| Term | Distinction tests must preserve |
+| --- | --- |
+| Logical work | Service-owned work can remain open after a turn or provider token ends. |
+| Enforcement lease | Bounded authority has its own deadline; a valid provider token cannot extend it. |
+| Broker access lease | Closure denies further access and retains cleanup obligations. |
+| Provider token | Local denial is separate from confirmed provider revocation or evidenced expiry. |
+| Execution process | A process can survive access closure. Replacement requires observed writer termination. |
+| Issuer service | Restart requires durable recovery and fresh service authority. |
+
+The [RFC series](../0027/runtime-access-overview.md) assigns ownership as follows:
+
+| RFC | Responsibility |
+| --- | --- |
+| 0034 | Credential obligations |
+| 0035 | Execution identity |
+| 0036 | Original-work authority |
+| 0037 | Runtime lifecycle |
+
+Acceptance of those RFCs is separate from qualification of the combined
+production path.
+
+## What binds mediated access to the container
+
+Test the [trusted mapping from each request to its container and original work](github-app-v1-spec.md#mediated-origin-and-routing).
+A copied bearer, container-readable key, or claimed work ID must not substitute
+for that mapping.
+
+## Minting, refresh, and revocation
+
+Exercise the [issuance protocol](credential-broker-v1-spec.md#durable-issuance-and-dispatch)
+and [renewal policy](github-app-v1-spec.md#refresh-and-overlap). Track predecessor
+tokens after replacement and report local access denial, provider revocation,
+and evidenced expiry separately.
+
+## Recovery cases
+
+| Event | Required recovery |
+| --- | --- |
+| Broker fails before a committed provider claim | Reconcile the original reservation and claim. Dispatch only with authoritative proof that no earlier attempt could have reached the provider. |
+| Mint response is lost after possible dispatch | Retain the original attempt as `unknown`; expiry remains unproven unless evidence establishes it. A fresh request or lease cannot bypass the hold. |
+| Custody/inventory acknowledgement is lost after provider success | Read back the exact operation. Block delivery while persistence is uncertain; retain material for cleanup. Missing readback does not authorize reminting. |
+| Cancellation or rotation occurs during issuance | Close old authority. Attach late results to their original binding and revoke them. |
+| Refresh fails | Use an eligible recorded token only with valid original authority and all required checks, through current online authorization in the first GitHub profile. Unknown issuance or exhausted overlap blocks another mint. |
+| Delivery response is lost | Record possible exposure and reconcile the same delivery. Retain cleanup obligations. |
+| Issuer restarts | Recover durable state, obtain fresh service authority, and resume cleanup/readback without cached authorization. |
+| Work/service authority is revoked or Agent/Namespace is deleted | Withdraw affected access under its selected bound. Retain tombstones and protected references so independent platform cleanup can continue. Requester invocation permission and service/workload access remain separate. |
+| Revocation times out or a worker claim expires | Reconcile the pending/unknown attempt; timeout proves neither provider success nor failure. |
+| Protected token material is unavailable | Report action-required. Recover custody or perform separately authorized broader mitigation; a hash cannot revoke the token. |
+
+The [GitHub issuance hold](github-app-v1-spec.md#refresh-and-overlap) survives
+replacement leases and broker restarts. A new connection or request ID does not
+resolve uncertainty.
+
+## Lifecycle
+
+### Enrollment and preparation
+
+| Event | Coordination |
+| --- | --- |
+| Verify enrollment | OCC authorizes exact references; issuer verifies provider identity and scope. Readiness does not mint. |
+| Prepare candidate | Compute provides execution and staging; SandboxDriver verifies containment. OCC gates checkout on both and a separate read-only lease. |
+| Finish/cancel preparation | Close access, observe preparation stopped, and retain cleanup. Failure preserves the serving workspace. |
+
+### Active work and replacement
+
+| Event | Coordination |
+| --- | --- |
+| Activate or replace | Close old assignment authority, observe previous writers stopped, and promote verified staging through Compute. Early stages admit fresh Work. Cross-assignment Work continuation is a later qualified profile requiring fresh current assignment authorization and new leases; original scope and effect receipts remain fixed. |
+| End a turn or logical work | A turn ending does not finish service-owned work. Logical-work closure closes its access leases; queued requests cannot borrow another work record through a mutable pointer. |
+| Admit Work | From A, require genuine root admission, original scope, exact Agent/revision/assignment, current operation authority, duration selection, and cancellation owner. Leases and operations stay finite. Same-scope subordinate helpers require qualification; separately admitted durable children follow in C. |
+| Restart within a Pod | Change execution generation, close old leases, and reestablish origin. The same Pod UID or volume preserves no authority. Permission/context changes additionally require a fresh Pod/gVisor sandbox, eligible context, and observed old-writer termination. |
+
+### Stopping and result delivery
+
+User-facing stop/start controls and completed-result delivery qualify in C.
+Cancellation, withdrawal, and safe retirement remain required from A.
+
+| Event | Coordination |
+| --- | --- |
+| Stop with bounded drain | Close new work admission; retain only eligible original work until the recorded finite deadline. Recheck authority on each effect. Completion/deadline closes access; disable or retirement overrides draining. A restart cannot extend the deadline. |
+| Disable/retire/delete | Stop new access and affected execution independently of cleanup. Retain outstanding records until terminal evidence. |
+| Deliver a completed result | Graceful stop preserves only separately admitted finite delivery to its exact audience. Posting still requires current authority. Cancellation/security revoke withdraws delivery even while already stopped; an uncertain submission is never blindly replayed. |
+
+## Repository preparation
+
+For the [preparation contract](github-app-v1-spec.md#repository-preparation),
+document:
+
+- The actual workload and staging/promotion mechanism.
+- Cancellation and proof that previous writers stopped.
+- Rollback.
+
+A "prepared" flag alone is insufficient.
+
+## Timing targets and outages
+
+### Withdrawal and cleanup bounds
+
+Each selected profile must publish numerical withdrawal bounds and their clock,
+observation, and enforcement assumptions. Ordinary eligible work may target
+minutes; sensitive profiles may target seconds with lower outage availability.
+These are tolerance scales, not fixed TTLs or measured guarantees.
+
+| Measurement | Target and interpretation |
+| --- | --- |
+| Access withdrawal | Measure the selected end-to-end target, including authority observation, issue/revoke ordering, distribution, local enforcement, and clock uncertainty. A disconnected read holder stops by its original deadline; it cannot extend that deadline on reconnect. Record authority commit separately from observed holder withdrawal. |
+| Workload termination | Observe affected writers stopped before replacement. A timeout blocks unsafe promotion and reports unresolved termination. |
+| Upstream cleanup | Observe for up to 120 seconds, then report confirmed revoke, evidenced expiry, pending/unknown, or action-required. Durable cleanup continues after this window. |
+
+### Timing evidence
+
+Record each of the following, including clock uncertainty:
+
+- Authenticated request acceptance, authoritative observation, and durable commit.
+- Holder observation, operation admission, and provider dispatch.
+- Last success, first denial, and observed termination.
+
+Separate request-to-denial from commit-to-denial; failed or lost commits are not
+successful samples. Tightening a profile cannot advertise its new bound until
+outstanding older leases are accounted for.
+
+### Authority outages
+
+For the first GitHub profile, deny every dispatch without current online OCC
+authority, including reads, issuance, and maintenance. An existing token or
+unexpired lease cannot provide an offline fallback. Report already accepted
+upstream effects separately, and retain cleanup obligations under their own
+independent authority.
+
+The shared broker's future read-continuity/maintenance profile requires separate
+selection and O2 qualification. It cannot silently enable offline GitHub access.
+Native development/testing copies remain usable until provider revoke/expiry,
+including during OCE outages.
+
+### Retries
+
+Use bounded backoff only where retries are permitted, respecting
+[`Retry-After` and reset responses](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api#handle-rate-limit-errors-appropriately).
+Outages retain cleanup obligations; network recovery authorizes neither
+reminting nor replay of ambiguous writes.
+
+## Implementation sequence
+
+| Stage | Required result |
+| --- | --- |
+| A. Managed reads | Implement the proposed admin configuration and Installation-selected credential gateway with genuine root Work and current operation authority, durable broker/custody, verified issuer scope/revoke, safe preparation, gVisor origin and routing, and mediated metadata/clone/fetch. Measure denial and cleanup against live GitHub. |
+| B. Coding workflow | Add selected issue/PR reads and exact-candidate human approval; qualify atomic expected-old push and separate draft-PR effects, including lost responses and partial success. |
+| C. Durable work and lifecycle | Qualify broader durable Work and independently admitted child records with ancestry/cancellation, then Stop task / Stop Agent / Start Agent and their selected delivery behavior. |
+
+Each stage needs artifact-linked authority, provider, runtime, and recovery
+evidence. Qualification of A does not establish B or C. Later transparent
+`git push` / `gh pr create` adapters reuse the same publisher and effects;
+independent-human and scoped automatic policy modes require separate approval
+qualification. Active-session migration/replay is outside these stages.
+Interfaces, synthetic fixtures, and native checks do not qualify production.
+
+## Acceptance matrix
+
+Tests apply to the selected stage and permission profile; unsupported features
+must deny. Shared tests use each provider's own expiry/cleanup rules.
+
+| Gate | Required evidence |
+| --- | --- |
+| A | C1-C5, root/assignment portions of S1/P1, G1 reads and revoke, R1, M1-M3 reads, O1, and E1 through live metadata/clone/fetch. Publication remains disabled. |
+| B | A plus coding/permission-narrowing cases, G1 publication, G3/G4, selected coding reads in M3, and E1 with human-approved publication. |
+| C | B plus separately admitted children in P1 and selected stop/start/completed-delivery behavior in S1/E1. |
+| Later policy modes | G5 plus the same exact-candidate, current-authority, destination, and effect checks as G4. Neither mode is enabled in the MVP. |
+| Other profiles | G2 is native development/testing only. O2 requires separate future read-continuity selection and qualification. |
+
+| ID | Required test |
+| --- | --- |
+| C1 | [Authority](#c1-authority) |
+| C2 | [Issuance](#c2-issuance) |
+| C3 | [Renewal](#c3-renewal) |
+| C4 | [Cleanup](#c4-cleanup) |
+| C5 | [Scope narrowing](#c5-scope-narrowing) |
+| S1 | [Series integration](#s1-series-integration) |
+| P1 | [Persistent work](#p1-persistent-work) |
+| G1 | [Live provider](#g1-live-provider) |
+| G2 | [Pinned native clients](#g2-pinned-native-clients) |
+| G3 | [Public publication](#g3-public-publication) |
+| G4 | [Exact-candidate publication](#g4-exact-candidate-publication) |
+| G5 | [Later publication policy modes](#g5-later-publication-policy-modes) |
+| R1 | [Preparation/runtime](#r1-preparationruntime) |
+| M1 | [Copy resistance](#m1-copy-resistance) |
+| M2 | [Boundary enforcement](#m2-boundary-enforcement) |
+| M3 | [Protocol scope](#m3-protocol-scope) |
+| O1 | [Operations](#o1-operations) |
+| O2 | [Read continuity](#o2-read-continuity) |
+| E1 | [Complete mediated profile](#e1-complete-mediated-profile) |
+
+Each test below states its required evidence and outcomes.
+
+### C1: Authority
+
+- Deny forged/cross-Namespace references, stale revision/incarnation, closed
+ leases, and wrong work; allow legitimate current work.
+- Authorize the administrator's exact Namespace, Agent/Configuration mutation,
+ and each referenced binding/broker/Secret. Deny an Agent editor who lacks
+ binding authority. Freeze verified repository IDs, refs, profile and policy
+ generations; config edits cannot silently change a serving revision.
+- Check requester user/channel invocation permission separately from
+ service/workload repository permission. Neither personal GitHub access nor
+ App-wide installation scope can widen the intersection.
+- Exercise the selected credential gateway through genuine admitted handles;
+ configuration or reconstructed handles cannot supply missing Work/IAM/custody.
+- Give two grants with the same provider/profile distinct leases. Closing one
+ grant preserves the other; closing logical work closes both. A turn ending
+ alone does neither.
+- Narrowing restricts issuance, delivery, and mediated use. Existing work cannot
+ acquire a wider selection.
+
+### C2: Issuance
+
+- Concurrent/repeated requests and crashes retain one original claimed attempt.
+- Lost provider/commit acknowledgements reconcile without untracked remint or
+ premature delivery.
+- GitHub profile/permission edits, rotation, rebinding, and replacement leases
+ cannot bypass an unresolved target hold.
+
+### C3: Renewal
+
+- Cross provider expiry (one hour for GitHub) and model-turn boundaries while
+ logical work remains open.
+- Test both explicit uncapped work/execution and a configured finite horizon.
+ All leases and operation bounds remain finite; renewal preserves each
+ configured horizon and cannot turn missing policy into uncapped authority.
+- Successors retain original authority, predecessors remain inventoried, and
+ overlap stays bounded.
+- Token replacement never extends enforcement/work deadlines; closed work
+ cannot renew through later work.
+
+### C4: Cleanup
+
+- Cancel during mint/delivery. Test successful/failed key rotation and
+ new-generation admission.
+- Withdraw work/service authority, delete resources, lose a cleanup claim, and
+ restart. Account for every known/uncertain token.
+- Report local closure, effective distributed withdrawal, and provider outcomes
+ separately.
+
+### C5: Scope narrowing
+
+- From A, narrow or withdraw selected read authority without changing its
+ recorded ceiling; from B, also narrow a live coding lease to views. Deny old
+ authority immediately. Serving changed permissions requires fresh Pod/gVisor
+ isolation and new assignment-bound leases.
+- Deny writes and broader-token reuse; allow a supported narrower issuance/read
+ only when authority, capacity, and holds permit.
+- Retain the broader token's identity and cleanup obligation. All scopes count
+ toward the same overlap budget until evidenced revoke/expiry.
+- Policy recovery cannot revive cleanup-only credentials, closed work, or a
+ wider original work selection.
+
+### S1: Series integration
+
+- Verify connector identity, represented assignment, original-work grant, and
+ enforcement lease independently. Deny an allowed connector's claim for an
+ unassigned execution.
+- From A, cancellation/withdrawal denies new effects and retains cleanup.
+ In C, also verify Stop task, Stop Agent and Start Agent against the selected
+ lifecycle contract; any admitted drain retains its original deadline.
+- Fresh reassignment requires current authority and predecessor stop evidence;
+ old access leases remain closed.
+- In C, graceful stop preserves only separately admitted completed-result
+ delivery; cancellation/security revoke withdraws it while already stopped.
+- Correlate business receipts, credential attempts, and lifecycle operations
+ without replaying uncertain effects.
+
+### P1: Persistent work
+
+- Keep a worker alive across A's closure and B's admission. Deny A's
+ queued/retried requests; allow B without importing A's authority.
+- Test concurrency, narrowing, cancellation, reconnect, and restart. Continue
+ admitted work across turn completion.
+- From A/B, enable subordinate helpers only after proving the same context,
+ scope, root attribution, and cancellation. They cannot acquire independent
+ durable Work; unsupported helpers deny while root-only execution can qualify.
+- In C, renew a separately admitted child with a stopped coordinator and expired
+ parent execution lease while logical ancestors remain open; deny after
+ ancestor cancellation.
+- Enforce eligible shared state and private/additional-authority isolation
+ independently of equal repository scope. Unsupported attribution or admission
+ denies.
+
+### G1: Live provider
+
+Use disposable private repositories to verify that:
+
+- Selected reads succeed; outside-grant repositories and disallowed writes fail.
+- Actual returned scope matches, and revoke-then-deny is observed.
+- Publication obeys exact approved ref/object constraints and expected-old
+ updates; repository rules with no App bypass add defense in depth.
+
+### G2: Pinned native clients
+
+Run actual Git 2.55.0 and `gh` 2.93.0 processes against controlled endpoints with
+synthetic ephemeral tokens. Verify:
+
+- Helper/per-child delivery and denied/expired outcomes.
+- Refresh overlap and original-attempt retention.
+- No automatic replay of ambiguous writes.
+
+### G3: Public publication
+
+Use synthetic content for these checks:
+
+- Allow an approved non-public write; deny public write grants even where the
+ App has access.
+- Deny wrong remotes, public mirror pushes, and public PR/API mutations.
+- Actual visibility/ownership changes close affected access and retain cleanup.
+- Unavailable visibility checks deny the affected write. Recovery requires fresh
+ verification and still-open original authority, never reopening a closed
+ lease.
+
+The full guarantee also requires M2/M3 and visibility-change controls; native
+scope checks provide partial protection.
+
+### G4: Exact-candidate publication
+
+- Require a configured, currently authorized human and record the exact action
+ digest. Require current IAM `operate` on the exact Agent and configured human
+ approver membership. Allow the requester when eligible; deny Agent/helper
+ self-approval and wrong-Agent or list-only approval.
+ Missing policy, expired approval, or revoked approver authority denies.
+- Stage A denies publication; stage B rejects independent-human and automatic
+ policy modes until separately enabled and qualified.
+- Reject changed objects, manifests, base/target refs, expected prior tips,
+ repository identity or PR metadata after approval; capture and approve anew.
+- Enforce exact ref allowlists, branch-creation permission, and atomic
+ expected-old comparison at the actual update. A competing remote update must
+ fail the approved push even after a successful preflight read.
+- Reject force, deletion, tags, multi-ref updates, and raw mutation bypass.
+- Claim and record push and PR effects separately. Require confirmed push before
+ PR dispatch; retain partial success and unknown outcomes without replay after
+ lost responses, cancellation, reconnect or restart.
+- Compare the attributed PR response, including observed head/base OIDs, against
+ the candidate. A mismatch stays unknown without erasing the confirmed push.
+
+### G5: Later publication policy modes
+
+Separate future qualification; these modes are not MVP requirements or defaults.
+
+- Independent-human mode rejects requester approval and accepts only a distinct,
+ configured, currently authorized human.
+- Scoped automatic mode accepts only the configured repository, operation, and
+ exact branch/candidate under current policy. It records the exact decision
+ without requiring per-operation human approval; out-of-policy requests deny.
+- Missing, stale, or withdrawn policy never falls back to automation or another
+ mode. Both modes retain G4's exact candidate, destination, concurrency,
+ separate effect, and unknown-outcome checks.
+
+### R1: Preparation/runtime
+
+- Verify checkout before Harness startup, the commit, and preserved user work.
+- Verify cancellation, same-Pod restart, replacement, stopped previous writers,
+ and deletion.
+- Test both permission increases and decreases with a fresh Pod/gVisor sandbox;
+ deny reuse of the old context and sibling-container substitution.
+- Pin runtime/image artifacts.
+
+### M1: Copy resistance
+
+- While A succeeds, replay every integration-issued container-visible
+ credential from an external host and B, including B on A's host/Pod where
+ supported. GitHub and broker deny copies.
+- A's closed work cannot borrow its successor's channel.
+- Replay a valid opaque proxy credential from another execution while its
+ original Agent succeeds; the protected origin must mismatch and deny.
+
+### M2: Boundary enforcement
+
+- Keep upstream credentials outside execution.
+- Deny raw-token endpoints, direct/tunnel fallback, and forged origin/turn
+ assertions.
+- Verify key custody and the runtime-owned local mapping.
+- Deny missing, unknown, expired, revoked, wrong-Work, wrong-execution, and
+ wrong-repository proxy credentials, including ambiguous authentication fields.
+ No rejection may fall back to anonymous access, a public placeholder, or native
+ token delivery. Strip the proxy credential before inserting the real upstream
+ token; neither real-token values nor protected material enter Agent-visible
+ configuration, files, environment, responses, or diagnostics.
+
+### M3: Protocol scope
+
+- In A, run metadata and Git clone/fetch with real pinned clients. In B, add
+ selected issue/PR reads and any required GraphQL shapes; test the trusted
+ publication action independently.
+- Deny direct Agent receive-pack and PR mutations in the first profile. Later
+ transparent adapters require separate qualification against the same publisher.
+- Deny redirects, ambiguous targets, cross-repository node IDs, extra GraphQL
+ operations, malformed framing, and unlisted operations.
+- Broader token permissions cannot authorize unlisted merges/mutations.
+- Unsupported operations and provider denials cannot trigger wider tokens.
+
+### O1: Operations
+
+- Measure denial separately from termination/cleanup.
+- With valid tokens and leases retained, make OCC unavailable and deny reads,
+ writes, issuance and maintenance; recovery does not replay uncertain effects.
+- Test lost authority, throttling, unavailable custody/storage, restart, and
+ operator recovery; deny unsafe access and report actual outcomes.
+- Authorized operators can find unresolved tombstones after deletion/restart
+ and identify the evidence or action needed.
+
+### O2: Read continuity
+
+Future optional broker profile only; excluded from the first GitHub release.
+
+- During authority outage, allow only qualified reads within the existing
+ deadline; deny writes, new admission, renewal, and reassignment.
+- Exercise expressly preauthorized read-only token replacement, missing
+ maintenance permission, broader-token rejection, unknown-mint hold, full
+ overlap, and unavailable inventory.
+- Deny at the original deadline despite a newly minted token. Missing live
+ approval/freshness evidence denies.
+- Restart with uncertain clock/revocation state requires synchronization.
+- Measure each selected withdrawal bound, including disconnected holders and
+ tighter-profile transitions.
+
+### E1: Complete mediated profile
+
+1. Pin one implementation, configuration, runtime, and client manifest.
+2. With a disposable live App/repository, enroll/admit through the actual
+ authority, broker, issuer, and inventory.
+3. In A, prepare/activate and run metadata/clone/fetch; cross token replacement
+ under the same root Work and deny dispatch on OCC outage. In B, add selected
+ coding reads and human Approve and publish; observe separate push and draft-PR
+ outcomes. In C, add separately admitted children and selected stop/start flows.
+ Exercise the running Agent's pinned client with only its proxy credential:
+ observe valid credential, protected origin, and current permission checks and
+ real-token substitution at the trusted upstream boundary. Token replacement
+ preserves the still-valid original proxy binding; its expiry or revocation
+ still denies. A pre-start checkout alone does not prove this ongoing path.
+4. Close that work and observe denial while the process survives, plus separate
+ provider cleanup. New work cannot revive old requests.
+5. Separately observe required execution termination; restart and recover an
+ outstanding obligation.
+
+## Acceptance evidence and current implementation limits
+
+This submission runs documentation checks only. Implementation submissions must
+identify code, configuration, and mode and provide redacted evidence for
+applicable tests. Record:
+
+- Implementation commit and configuration/profile version.
+- Tool/image pins and environment.
+- Command/request manifest.
+- Positive/negative outcomes and unresolved results.
+
+Publish redacted evidence with synthetic identifiers; keep secrets and private
+infrastructure details outside this repository.
+
+Existing component results may be reused where behavior matches this contract;
+they do not establish the full lifecycle or mediated origin guarantee.
+
+## Upstream decision and implementation handoff
+
+RFC approval covers the proposed admin configuration and credential gateway,
+minimum original-work authority, and sequential A/B/C delivery. Read continuity,
+advanced scheduling, and active-session migration/replay remain outside those
+initial gates. Independent-human and scoped automatic publication are later,
+separately selected policy modes. Record remaining deployment choices:
+
+- Qualified runtime attachment, protected dispatch, and exact read command matrix.
+- Eligible human approvers, exact allowed refs, and approval lifetime.
+- Measured withdrawal bounds and which same-scope subordinate helpers qualify.
+
+Follow the repository's acceptance process: keep draft status until acceptance,
+then create an implementation issue with milestone and evidence owners. RFC
+acceptance does not qualify an implementation for production.
diff --git a/rfcs/0034/repository-configuration.md b/rfcs/0034/repository-configuration.md
new file mode 100644
index 00000000..68224899
--- /dev/null
+++ b/rfcs/0034/repository-configuration.md
@@ -0,0 +1,160 @@
+# Repository configuration and CredentialGatewayDriver
+
+Proposed configuration and ownership for [RFC 0034](../0034-github-app-credentials.md).
+The current public Agent create/update API has no repository field, and the
+current Driver capability list has no credential gateway. The shapes below are
+proposals, not existing endpoints or released capabilities. Existing internal
+credential selection contains `repository { profile, binding, grant }`; it does
+not expose this administrator workflow or establish production access.
+
+## Administrator workflow
+
+1. An Installation operator selects the credential gateway implementation and
+ protected storage. A Namespace administrator enrolls an exact GitHub App
+ installation and verifies its organization, repositories, and permissions.
+2. The administrator selects repository access on an Agent using the typed
+ structure below. Repository selection is platform configuration, separate
+ from model instructions or repository-supplied files.
+3. OCC authenticates the administrator and authorizes the exact Namespace,
+ Agent create/update, selected Configuration, integration binding, broker,
+ and referenced Secret. Permission to edit the Agent alone cannot grant use
+ of another binding. Cross-Namespace or unresolved references deny admission.
+4. A separately authorized deployment resolves the checkout ref to a full
+ commit OID, verifies repository identity and scope, and freezes the draft
+ selection and referenced generations into `AgentRevision`. Saving the draft
+ does not admit or activate a revision. Independently authorized withdrawal
+ can deny current access immediately without deploying the draft.
+
+This is native, admin-managed OCE configuration. Entra integration and personal
+GitHub ACL synchronization are not prerequisites. User/channel allowlists
+authorize invocation separately; they neither confer repository permission nor
+lend the requester's GitHub credentials to the Agent.
+
+## Proposed typed Agent selection
+
+Propose an optional `repositoryAccess: AgentRepositorySelection` property on
+both Agent create and update requests. This field does not exist in the current
+public API. Omission on create selects no repository access; omission on update
+preserves the draft selection. Supplying `repositoryAccess` replaces the full
+draft selection with its `repositories` array; an empty array selects no
+repository access. Saving changes only the draft and grants no new authority.
+A separately authorized deployment freezes it into a new immutable revision
+before activation. A repository with publication `disabled` selects eligible
+reads only. Independently authorized withdrawal can deny removed or restricted
+grants on active Work immediately, without activating the draft. Serving
+changed permissions requires the fresh Pod/gVisor boundary.
+
+```ts
+type AgentRepositorySelection = {
+ schemaVersion: 1;
+ repositories: Array<{
+ bindingRef: OccReference;
+ repositoryId: number;
+ checkoutRef: string;
+ readProfile: "checkout" | "views";
+ publication:
+ | { mode: "disabled" }
+ | {
+ mode: "human-approval";
+ approverRefs: PrincipalReference[];
+ refs: Array<{
+ baseRef: string;
+ targetRef: string;
+ allowCreate: boolean;
+ }>;
+ approvalLifetime: Duration;
+ };
+ }>;
+};
+```
+
+Field names are illustrative. References and durations need validated codecs;
+lists, refs, and inputs need finite profile limits. Reject unknown versions,
+unsupported fields, missing policy, empty approver sets for publication, and
+ambiguous repository selections. Publication must be explicitly disabled or
+configured. Stage A admits `checkout` with publication `disabled`; stage B adds
+`views` and `human-approval`.
+
+The admitted revision retains the binding generation, GitHub App/installation
+identity, canonical repository name and ID, resolved commit, read profile,
+publication policy, and policy generation. IDs govern authority; names aid
+review and cannot redirect access. Public resources contain references and safe
+metadata, never signing keys or tokens. The [GitHub access record](github-app-v1-spec.md#admitted-data)
+derives from this selection.
+
+Effective access is the intersection of current OCC/IAM service authority,
+the admitted Agent revision, the original Work selection, applicable restrictions,
+and the App installation's available repository permissions. The gateway
+requests one repository and an exact supported permission subset. It denies
+unsupported intersections; it cannot fall back to installation-wide access.
+
+Each runtime repository operation still needs genuine original Work, its current
+assignment and operation authority. Preparation is separately admitted; cleanup
+uses independently retained platform authority after Work or assignment closure.
+Configuration, admission snapshots, and successful enrollment are ceilings, not
+reusable authorization decisions.
+
+## Proposed CredentialGatewayDriver
+
+The proposal adds `credential_gateway` to the Driver capability registry, with
+`CredentialGatewayDriver` as its interface. The Installation selects its
+implementation through the Driver model. Selection names an implementation; only trusted composition can supply the admitted
+Work, IAM, inventory, custody, and runtime handles required to serve requests.
+Configuration strings or reconstructed objects cannot manufacture those handles.
+
+| Owner | Responsibility |
+| --- | --- |
+| OCC/IAM | Sole platform authorizer for configuration, work admission, current operations, withdrawal, and independently authorized cleanup. GitHub also enforces provider permissions. |
+| `CredentialGatewayDriver` | Hosts protocol mediation and composes the broker and provider issuers; consumes admitted handles, enforces exact operations, and owns startup, quiesce, recovery, and disposal of this capability. |
+| `SecretBroker` and issuer | Broker retains leases, protected custody, durable inventory and cleanup obligations; issuer performs exact authorized GitHub issuance/revocation. |
+| `SecretDriver` | Backend secret storage. |
+| `ServiceAccountDriver` | Service-account provisioning and its existing credential contract; no expansion into general GitHub mediation. |
+| Compute and SandboxDriver | Execution, safe checkout and termination observations; network/runtime containment and protected origin attachment. |
+
+The proposed Driver offers these narrow local operations:
+
+- **Admit access:** consume OCC's exact admitted selection and assignment,
+ returning an opaque access reference. It cannot create Work or widen a grant.
+- **Mediate:** consume current operation authority and protected origin; validate
+ the canonical provider request, acquire an eligible credential, and dispatch.
+- **Close and recover:** close local access, retain unresolved effects and
+ credential obligations, and run cleanup under separate current authority.
+- **Quiesce/dispose:** stop new calls and join bounded work while preserving
+ durable records. Process shutdown does not mean provider revocation.
+
+The [broker operations](credential-broker-v1-spec.md#broker-operations) and
+[issuer ports](credential-broker-v1-spec.md#issuer-interface) supply the detailed
+contracts. This capability adds no public Token, Lease, Issuer, or gateway
+resource. The credential gateway is separate from the Agent's messaging
+gateway. A deployment may cohost broker and mediator outside Agent execution;
+process layout does not change authority or custody boundaries.
+
+## Publication modes and delivery
+
+Stage B uses explicit human approval. Any configured, currently authorized human,
+including the requester, may approve; an Agent or its helper cannot self-approve.
+For this new approval operation, OCC calls the selected IAM Driver with the
+human principal, existing `operate` action, and the exact Agent resource,
+including its Installation and Namespace. It also requires membership in the
+revision's configured human approver list and current candidate/repository
+policy. This mapping is proposed, not an existing approval endpoint. Neither
+Agent invocation permission alone nor list membership alone suffices. Each
+publication effect rechecks this approval's current eligibility alongside the
+Agent's own Work and repository authority.
+
+Later revisions may add two separately selected modes: independent-human
+approval, or scoped automatic authorization under current policy. Automatic
+authorization would record a decision for the exact candidate and effects,
+without requiring a human approval for each operation. Neither later mode is
+enabled in the MVP, and absent policy never selects automation.
+
+All modes retain the same exact repository/ref/object constraints, current Work
+and IAM checks, durable push/PR effects, and handling of unknown outcomes.
+See [trusted publication](github-app-v1-spec.md#trusted-publication).
+
+Stage A qualifies mediated metadata and clone/fetch first; B qualifies the
+coding workflow and publication. Broader durable Work and separately admitted
+children, together with Stop task / Stop Agent / Start Agent controls, follow
+in C. Root Work and operation authority are prerequisites from A; the broader
+features are not. [Acceptance](lifecycle.md#acceptance-matrix) must prove the
+selected stage through genuine owners and runtime integration.
diff --git a/rfcs/0034/review-preview.png b/rfcs/0034/review-preview.png
new file mode 100644
index 00000000..6d45b8c4
Binary files /dev/null and b/rfcs/0034/review-preview.png differ