@@ -586,7 +586,8 @@ would allow them to claim an existing sandbox identity.
 The Kubernetes Secrets credential driver (`openshell-driver-kubernetes-secrets`)
 stores secrets in workspace-specific namespaces when `workspace_mode` is managed
 or operator. In shared mode, all secrets render into the single configured
-namespace.
+namespace. Gateway-global secret material has no workspace and always renders
+into the configured credential namespace in every workspace mode.
 
 When runtime infrastructure changes, validate the relevant sandbox e2e path and
 update the matching driver README if a maintainer-facing constraint changes.
@@ -455,6 +455,17 @@ state is stored as a separate object scoped to the provider instance through
 `objects.scope`. Its non-secret configuration remains inline, while refresh
 tokens, client secrets, private keys, and other secret source material are
 stored through the active credential driver and represented by opaque handles.
+Delegated identity credentials use the same boundary: access and refresh token
+bytes exist only in the selected credential backend, while the generic
+delegated credential object retains issuer, subject, expiry, revocation state,
+and opaque handles. The sandbox record contains only its authorization window
+and a reference to that generic credential object. The CLI obtains delegated
+material through a browser Authorization Code flow with PKCE separate from its
+normal login. It transfers that bundle without writing it to the local login
+store and continues to authenticate gateway RPCs with the normal login. The
+gateway is therefore the sole owner of the delegated refresh-token chain. A
+healthy gateway-owned grant is shared by that user’s delegated sandboxes;
+create and extend carry only the requested authorization window.
 The provider record keeps only the current injectable credential handles and
 optional per-credential expiry timestamps. A refresh normally mints one
 credential, but a strategy may co-mint several (AWS STS mints the access key,
@@ -468,6 +479,24 @@ credential storage for defense in depth. Multi-replica deployments can use that
 default with a shared database and shared key-encryption key, or opt into an
 external backend such as Vault or Kubernetes Secrets.
 
+Credential-driver writes and generic object CAS writes form a compensating
+transaction. New delegated material is staged before its handles are committed.
+A failed CAS deletes the staged handles; a successful replacement records old
+handles as pending deletion before cleanup. Revocation and deletion first clear
+active handles and make the generic credential unusable, then delete backend
+material. Pending opaque handles remain durable across cleanup failures and a
+gateway worker retries them. Final deletion keeps a disabled tombstone until
+all backend material is gone, so a partial failure cannot silently orphan a
+reusable token.
+
+Delegated credential refresh also uses a short-lived lease in the generic
+credential record. Gateway replicas acquire the lease with object-store CAS
+before resolving or submitting the refresh token. Non-owners reload the record
+until the owner commits the rotated handles, and an expired lease permits
+recovery from a failed replica. The final CAS verifies that the credential is
+still active and that the writer still owns the lease, so revocation cannot race
+with refresh and restore usable token handles.
+
 Sandbox workload templates are workspace-scoped gateway resources. Workspace
 admins create and delete them; workspace users can read and list them. A
 template owns reusable workload intent: image, environment, CPU and memory
@@ -490,7 +519,9 @@ short-lived credentials still fail closed at their recorded expiry.
 Credential handles remain bound to the driver that created them. Before the
 0.1.0 compatibility boundary, gateways do not migrate inline refresh material
 or move handles between credential drivers; operators reconfigure affected
-grants when upgrading or changing backends.
+grants when upgrading or changing backends. Delegated identity has not shipped
+with inline token storage, so development deployments created from an earlier
+feature branch must delete and recreate those branch-only records.
 
 ### Optimistic Concurrency (CAS)
 
 
@@ -128,7 +128,8 @@ can contain a valid sequence gap.
 | Corporate proxy CONNECT response headers | 8 KiB | Fail the tunnel. |
 | Corporate proxy CONNECT handshake | 30 s total | Fail the tunnel; validated-address attempts share the aggregate budget. |
 | Token-grant HTTP request | 30 s request and connect | Fail credential resolution. |
-| Response-derived token cache TTL | 5 min default; 1 h response cap; 30 s expiry margin | A positive profile `cache_ttl_seconds` override replaces the response-derived calculation. |
+| Client-credentials token cache TTL | 5 min default; 1 h response cap; 30 s expiry margin | A positive profile `cache_ttl_seconds` override replaces the response-derived calculation without changing existing client-credentials behavior. |
+| Token-exchange token cache TTL | 5 min maximum | The cap applies to positive profile overrides. Response-derived TTLs apply the 30 s expiry margin after the cap, for a 4 min 30 s maximum. This bounds continued token injection after delegated-identity withdrawal or credential revocation. |
 
 ## Sandbox-Local Surfaces
 
 
@@ -374,20 +374,54 @@ Provider profiles can also declare dynamic token grants. For matching HTTP
 endpoints, the supervisor obtains or exchanges OAuth2 access tokens, caches
 them, and injects them before forwarding the request. `client_credentials`
 grants use the supervisor SPIFFE JWT-SVID directly as the client assertion.
-`token_exchange` grants ask the gateway to broker an intermediate token using a
-stored provider subject credential and the gateway's own SPIFFE JWT-SVID; the
-supervisor then exchanges that intermediate token for the final upstream token
-using its own JWT-SVID. The gateway validates that its own JWT-SVID has the
+`token_exchange` grants ask the gateway to broker an intermediate token using
+either a stored provider subject credential or the sandbox creator's delegated
+OIDC identity, plus the gateway's own SPIFFE JWT-SVID; the supervisor then
+exchanges that intermediate token for the final upstream token using its own
+JWT-SVID. Delegated identity is opt-in at sandbox creation. The CLI first checks
+for a usable gateway-owned credential for the authenticated user. When one is
+missing, revoked, or no longer refreshable, the CLI runs a separate device
+authorization and transfers its token bundle to the gateway without replacing
+the normal CLI login. Sandbox create and extend then send only a per-sandbox
+authorization window. Delegated access and refresh tokens live behind opaque
+handles in the gateway's active credential driver; the generic credential and
+sandbox records never contain their bytes. Rotation stages replacement handles
+before updating metadata and uses a shared-store CAS lease so gateway replicas
+cannot submit the same refresh token concurrently. Revocation disables
+resolution before cleanup, and deletion retains a disabled tombstone until
+cleanup completes. Within one gateway process, sandbox creation and delegation
+extension share the gateway-wide state guard with credential deletion so a
+credential cannot be deleted between its active-reference check and a new
+delegation write. Like the gateway's other cross-object state guards, this
+coordination is process-local pending DB-backed multi-writer synchronization.
+Only the delegating user can
+extend or withdraw that window. Only the delegator can start or interact with
+the sandbox. Workspace and platform admins can stop it for containment or
+delete it to recover resources, but cannot start it. Other workspace users
+cannot start, stop, delete, or interact with it. Ordinary sandboxes retain the
+workspace role model. The gateway rejects exchange after expiry, withdrawal,
+missing credential state, or credential revocation.
+The gateway validates that its own JWT-SVID has the
 requested audience, a SPIFFE subject, and a non-expired `exp` claim when
-present. It also validates that the stored subject credential is declared by the
-provider profile, and that the supervisor JWT-SVID is a well-formed
+present. For provider-credential subject tokens, it also validates that the
+stored subject credential is declared by the provider profile. For delegated
+identity subject tokens, it validates that the sandbox was created with active
+delegation for the stored credential principal. The gateway also verifies that
+the supervisor JWT-SVID is a well-formed
 three-segment JWT with a SPIFFE subject in the same trust domain as the gateway
 SVID. The gateway verifies the supervisor JWT-SVID signature with JWT bundles
 fetched from its SPIFFE Workload API. Token grant endpoints are HTTPS-only
 except for loopback and Kubernetes service DNS hosts, and returned access tokens
-must be bearer-compatible before they are cached or injected. Token response
+must be bearer-compatible before they are cached or injected. Delegated OIDC
+discovery and refresh use a dedicated 30-second HTTP client that ignores ambient
+proxy settings and rejects redirects. Token response
 lifetimes are capped and cached with an expiry margin unless a profile supplies
-an explicit cache TTL override. Cache entries are scoped by the sandbox provider
+an explicit cache TTL override. Every `token_exchange` cache entry, including
+an override, is capped at five minutes so withdrawal and gateway credential
+revocation bound continued token injection. Response-derived entries apply the
+30-second margin after that cap and therefore live for at most four minutes and
+30 seconds. This bound does not invalidate an access token that an upstream
+service has already received. Cache entries are scoped by the sandbox provider
 environment revision so provider credential updates miss the old token cache
 without changing endpoint matching semantics. Gateway-brokered intermediate
 tokens are cached separately by provider resource version, supervisor SPIFFE
 
@@ -97,3 +97,4 @@ serde_json = { workspace = true }
 temp-env = "0.3"
 tokio-stream = { workspace = true }
 url = { workspace = true }
+wiremock = "0.6"