@@ -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,18 @@ 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 a relative duration, and the gateway derives the
+absolute authorization window from its own clock.
 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 +480,36 @@ 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. If deletion fails, recording the staged
+handles as pending deletion retries CAS conflicts and merges into the latest
+credential without overwriting concurrent changes. 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 recorded backend material is gone. This compensation is not atomic across
+stores: a missing parent credential or failed cleanup-record persistence can
+still leave untracked material; the gateway logs a cleanup warning.
+
+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. The owner renews its lease with
+owner-checked CAS throughout exchange, validation, staging, and commit, and
+renews immediately before the bounded HTTP exchange. Renewal cannot revive an
+expired lease or overwrite a takeover. Safe reads, validation, renewal, and
+commit retries have bounded waits; credential writes finish before compensation
+rather than being cancelled mid-write. Renewal failure prevents further exchange
+or commit and triggers staged-handle cleanup. Renewal stops at commit or when
+the owning call ends; an expired lease permits recovery from a failed replica.
+The final CAS verifies that the credential is still active and that the writer
+owns an unexpired lease, so revocation cannot race with refresh and restore
+usable token handles. This does not make the OAuth exchange atomic with local
+persistence: a crash or partition after upstream rotation can still require
+reauthorization.
+
 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 +532,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 per entry from insertion | 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. Already-authorized exchanges may finish and populate caches after delegation withdrawal or credential revocation, so this is not a withdrawal-to-containment deadline. |
 
 ## Sandbox-Local Surfaces
 
 
@@ -60,7 +60,9 @@ identifies the calling binary, checks trust-on-first-use binary identity, reject
 unsafe internal destinations, and evaluates the active policy. On Linux, it
 maps an accepted proxy connection back to the workload socket by matching the
 complete local-to-remote TCP tuple before resolving every process that owns the
-socket inode.
+socket inode. If fork or descriptor passing creates multiple owners, they must
+have compatible policy identities; the proxy denies ambiguous shared ownership
+before middleware evaluation or upstream connection.
 
 CONNECT and absolute-form forward HTTP are explicit-proxy adapters over the same
 egress pipeline. Each adapter normalizes its request into an egress intent, and
@@ -374,20 +376,69 @@ 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
+duration; the gateway derives the absolute authorization window from its own
+clock. 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. These ownership restrictions govern direct sandbox access,
+not confidentiality against configuration administrators. Exchanges load the
+current provider profile; delegation does not pin its exchange configuration.
+Workspace admins can change workspace-scoped custom profiles, including the
+token endpoint, and redirect a subsequent exchange. The gateway sends the raw
+delegated access token as the subject token, not the delegated refresh token or
+normal CLI login credentials. Both provider-credential and delegated-identity
+subject-token paths therefore trust administrators who control exchange
+configuration with their subject tokens.
+The gateway rejects requests whose authorization checks
+observe delegation expiry, withdrawal, missing credential state, or credential
+revocation. Withdrawal is not instantaneous containment. Already-authorized
+refreshes or exchanges may finish and populate token caches. Provider profile
+lowering trims surrounding whitespace from subject-token source and credential
+identifiers before the gateway resolves them with exact matching.
+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 from insertion. This limits reuse of each
+entry, not elapsed time from delegation withdrawal or credential revocation;
+in-flight exchanges can populate caches afterward. 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"