# ADR: Runtime Trusted Delegation and Security Admission

> **Current extension (2026-09-08):** Sections 1.1 and 1.2 bind native-user
> admission and the already-published query/mutation APIs. They supersede the
> former mandatory-Connected-App and future-mutation wording. P6/P7 phase and
> source-version evidence below is historical; it is not current serving status
> or approval to deploy MCP. Shared delegation, revocation and timing invariants
> remain applicable to each admitted capability.
>
> **Historical status:** **APPROVED through P6-D**. P6a froze the owner and execution
> shape; P6b froze hard protocol ceilings; P6-D now approves the first-cutover
> timing policy in Section 8.1. This does not make `runtime-api` ready,
> authorize production traffic, or add an App installation. P7b must build the
> metadata view non-serving; P7c/S1 must atomically bind security and metadata;
> and V1 must execute the production clock, renewal, rotation, and revocation
> gates for the exact consumer selected by C0.
>
> **Applies to:** end-user delegation through an L1 workload, including
> `runtime.records.read-selected-root.v1`, `runtime.records.query.v1` and
> `runtime.records.mutate.v1`; operation semantics remain in each published API.
>
> **Historical P6 source revision:** NexusCRM
> `e06339fa10d88ef0f832aef594fc365912e596a5`; api-host `v0.5.0`
> (`77c66b28d48b4089682c918a2e82c226a27281eb`).
> **Delegation contract:** nexuscrm-contract root `v0.1.10` at reviewed merge
> `c01105baf6345bad21045530994f8da15e9ff988`; the unchanged wire carrier is
> `wire-go/v0.1.1` at `e2fe0a97787042f060ab913aaa18b69ca8cc9214`.
> The `v0.1.7..v0.1.10` release diff changes no file under
> `pkg/runtime/delegationv1`; the current algebra/golden suite is re-ratified
> against `v0.1.10`. api-host `v0.5.0` preserves Records admission while adding
> the F1-I sensitive Identity transport path; the original NexusCRM and
> exact-main P6-D implementation evidence remains unchanged.

## 1. Decision

Runtime Identity/Security is the single authority for admitting an end-user
delegation to a Runtime capability. It validates the intersection of:

```text
authenticated caller workload
× current user session and principal
× associated application state (only for an application-bound credential)
× Org-bound AppInstallation
× granted Runtime capability
× AuthEpoch
× SecurityEpoch and unexpired SecurityLease
```

No element can substitute for another. The selected-root semantic request
remains unchanged and contains none of these facts.

The 2026-09-08 [independent L1 MCP Worker decision](https://github.com/pingcap-inc/nexuscrm-app-packs/blob/49e9998af867edfc3f5715eee2bfc8e8e0b8c2f7/docs/design/mcp-l1-worker.md)
supersedes the earlier MCP-specific requirement to add `ExchangeResource` and
resource-profile authority. The Worker reuses published Runtime identity and
CRM APIs. It neither verifies user tokens locally nor creates a parallel
permission authority. A native user session does not require Connected App
registration; existing credential validity and any restrictions of a credential
already bound to a Connected App remain enforced by their Runtime owner.
Workload/API capability admission does not replace current user object/FLS/RLS
checks. No MCP-specific business scope or read-only ceiling is introduced.

The production call path is two-stage:

```text
existing public session authentication
→ Runtime Identity issuer creates a short-lived, audience-bound delegation
→ L1 calls RecordsService with workload authority + delegation
→ api-host transport policy authenticates the workload
→ Runtime security admission validates delegation and authoritative state
→ one immutable TrustedCall is installed
→ Records handler projects TrustedCall to the current UserSession bridge
→ selected-root metadata/CRUD/RLS/FLS/repository path
```

The first stage is not a second record-data RPC. For the idempotent selected-root
read, a delegation is intentionally reusable within its short lifetime, but
only for the exact authorized workload, installation, audience, session,
epochs, and capability set. Every use is revalidated by Section 6; reuse never
bypasses revocation or epoch checks. A data call never forwards the raw user
bearer token. Mutation replay/idempotency uses the distinct published mutation
capability and command contract in Section 1.2; it never inherits read authority.

### 1.1 Native user admission without Connected App

The existing Runtime path is concrete; it does not turn an empty scope into a
grant or allow L1 to choose a principal:

1. `runtimeidentity.SessionLifecycle.createFederatedSession` verifies the existing
   federated provider token, resolves the current principal, and creates a native
   session with the provider's configured `FederatedScopes` and no ConnectedAppID.
   The existing test `TestSessionLifecycleFederatedTokenIsVerifiedBeforePrincipalResolution`
   exercises this path and its `api` session-scope mapping. No new MCP login scope
   or application registration is introduced by the Worker.
2. `nexuscrm-persistence/session_authorizing.go` initializes
   `ConnectedAppAuthorized` to true exactly when the durable ConnectedAppID is
   empty. An associated app is validated when one exists. Disappearance of a
   previously constrained app/scope does not turn that credential into a native
   unconstrained session.
3. `PublicSessionAuthorityFrom` uses `AuthService.AdmitRuntimeIdentitySession`
   for strong current bearer/session/user admission. The existing audience rule,
   session revocation, user activity and permission floor remain enforced.
4. `NewSessionCapabilityPolicy` maps the **existing, nonempty** durable session
   scopes to published Runtime API grants. The issuer intersects those grants
   with the installed workload/installation capabilities and requested capability.
   An absent scope, missing mapping or empty intersection grants nothing and
   fails closed. The MCP Worker does not synthesize `api`, disable this check or
   add a second business-permission table.
5. Each data RPC revalidates delegation/session state and uses the current user
   object, field and record permissions. Workload registration authenticates the
   caller/API compatibility; it never grants the service account's data rights
   to the user.

These source facts were checked at Core `4324361c21c6ffc01e114f549058e65a64ed5294`.
They prove an existing no-Connected-App authority path, not a completed MCP client
login/credential-transfer journey. Existing app-bound OAuth credentials keep
their original restrictions; legacy MCP OAuth/PAT compatibility is not implied.

### 1.2 Query and mutation capability contract

MCP uses existing generic APIs, with no new MCP RPC or permission primitive:

| Operation | Required Runtime grant | Operation authority |
| --- | --- | --- |
| Query page / trusted-current-user query | `runtime.records.query.v1` | published `queryv1` and `RecordQueryService.QueryRecords` |
| Selected root read | `runtime.records.read-selected-root.v1` | published `recordsv1` and `RecordsService.ReadSelectedRoot` |
| Create/update/delete | `runtime.records.mutate.v1` | published `recordmutationv1` and `RecordMutationsService.MutateRecords` |
| Mutation status/reconciliation | `runtime.records.mutate.v1` | the same command contract and `GetMutationStatus` |

The normative mutation grammar, digest, limits and retry classifications are
[published recordmutationv1 at v0.6.13](https://github.com/pingcap-inc/nexuscrm-contract/tree/v0.6.13/pkg/runtime/recordmutationv1).
The current single-record Runtime executor implements create/update/delete only.
The contract's UPSERT arm does not prove current execution support; it must not
be advertised by MCP or emulated with a query-then-write race. Bulk-ingest upsert
is a different use case, not this single-record command.
The Worker consumes that published contract and the corresponding API-host
`RuntimeRecordMutationClient`; its Go module pins select compile dependencies,
not a Core service-release compatibility gate.

- Acquire a delegation for the operation's actual capability. Query admission
  does not authorize mutation/status, and protocol discovery must not require
  a user's write permission. Runtime rejects missing mutation grants before effects.
- A single-record mutation declares `SINGLE_RECORD` and a supported batch mode;
  Runtime owns CRUD/FLS/RLS, validation, automation, transaction boundaries and
  its normal audit trail. The actor comes from TrustedCall, not an MCP argument
  or workload service account. Do not claim that several independent commands
  form one transaction.
- The trusted L1 adapter derives one stable command ID from the caller's
  idempotency key. Runtime scopes it to the admitted Org/installation/principal
  and binds the canonical command digest. Exact retries preserve ID and content;
  changing content under the same key must not execute a second command.
- The published client reconciles ambiguous transport outcomes with the exact
  command's status. Only the existing positive nonterminal command binding
  permits its bounded replay. Missing status is not proof of non-commit;
  disconnect/cancel/deadline is not rollback. Do not replace that policy with
  blind retries or fresh command IDs.
- Deployment acceptance must prove allowed writes for a native writer and
  denied writes for read-only/FLS/RLS-restricted or revoked users, rejection of
  a query-only delegation on mutation/status, and the normal Runtime audit
  actor/command trail. Test permission changes, same-key changed-payload
  conflicts and an outcome-ambiguous write followed by status reconciliation.
  Bind those results to the real Worker/Runtime artifacts; protocol/fake-port
  tests do not supply this business acceptance.

## 2. Historical post-P6d facts and gaps

At the post-P6d NexusCRM tree:

- `backend/internal/runtimeapi/process.go` accepts the api-host workload
  authority and one concrete Runtime `SecurityAdmission`; the old independent
  `SessionResolver` constructor path is deleted. `RecordsServer` reads only the
  private immutable `TrustedCall` installed by that admission interceptor.
- `backend/internal/runtimeapi/bootstrap.go` deliberately installs rejecting
  workload/security admission, zero bootstrap receipts, no database, and
  `ServingEnabled=false`. No verifier key, binding, session, issuer, or static
  grant enters the command closure.
- `backend/cmd/runtime-api/main.go` always assembles that non-serving
  bootstrap. The projected workload-identity file is validated only as a
  mount by `backend/internal/runtimeconfig/config.go`; it grants no authority.
- api-host `runtimegrpc.Policy` owns protocol, deadline, compression,
  admission, workload-authority invocation, and its private caller context.
  It cannot resolve NexusCRM sessions, App installations, or security epochs.
  Its `VerifiedCaller` remains an opaque handle; Runtime security binding
  resolves that handle to the canonical workload ID before P6b comparison.
- `nexuscrm-auth.AuthService.ValidateSession` and its bearer-free
  `ValidateRuntimeSession` reuse the same durable session/user/Connected App
  owner. Runtime validation bypasses the ordinary 60-second HTTP caches and
  projects only the current user/profile/role facts required by selected-root.
  In the public bearer path, disappearance of a previously constrained durable
  scope/App/grant invalidates the session; it is never converted to the legacy
  empty/full-access sentinel. `SessionClass` remains on its existing JWT
  session-bound owner and is not authority for selected-root.
- `_System_Session` contains session, revocation, scope, Connected App, and the
  monotonic AuthEpoch fact. The Runtime security repository owns the protected
  per-Org audience/SecurityEpoch, AppInstallation-to-canonical-workload grants,
  replica leases, and delegation revocation tombstones. P6d connects that owner
  to admission and readiness: caller-bound crypto verification is followed by
  one authoritative admission snapshot and the existing durable session read
  before the private `TrustedCall` can be installed.
- `shared/pkg/constants.DefaultOrgID` documents the current product as
  single-tenant. A constant or deployment environment value therefore cannot
  prove cross-org authorization.

The production command remains deliberately non-serving and contains no key,
issuer, static grant, or L1 dependency. P6d proves the promotable composition
and real process path in integration tests. P6-D decides the timing policy in
Section 8.1; P7 still owns its authority-clock lease/key enforcement and the
atomic metadata/security serving view.

## 3. Ownership

| Fact | Single owner | Runtime read path |
|---|---|---|
| Workload credential verification | api-host transport adapter using an operator-bound verifier | verified workload fact in the private gRPC context |
| Session, user activity, associated Connected App state when present | Runtime Identity in `nexuscrm-auth` plus its Runtime persistence ports | authoritative validation during issuance and admission |
| Delegation signing keys and key rotation | Runtime Identity secret/key provider | issuer signs; admission verifies an allowed current/overlap key ID |
| Org identity of the Runtime data partition | Runtime security-state row in the Runtime database | admission compares the delegation before any record lookup |
| AppInstallation → handler/workload-consumer capabilities | Catalog-authored binding projected by a fenced command into Runtime security state | admission reads only the active Runtime projection |
| Independent delegated user API caller registration | deployment serving policy, disjoint from handler/workload-consumer identities | explicit `user_api_callers` registration plus exact prepared Catalog installation/epoch; see Independent delegated user API callers below |
| AuthEpoch and minimum SecurityEpoch | Runtime Identity/Security state | admission rejects older delegations |
| SecurityLease | Runtime Identity/Security authority | a serving replica must hold an unexpired lease at or above the minimum epoch |
| Object CRUD, RLS, and FLS | bound Runtime metadata/security view and Records engine | published read/query/mutation owner paths |

The Runtime projection is not a second authoring surface. Catalog owns
AppInstallation declarations; Runtime owns the fail-closed serving projection
and acknowledges the fenced activation. P7 binds that projection and the
metadata view into one serving-state transition. Until P7, P6 can prove the
security state machine but cannot make the process ready for production.

Configuration may select cryptographic providers, endpoints, certificate/token
files, and bootstrap connectivity. It may not author Org, AppInstallation,
capability, epoch, revocation, or lease truth.

## 4. Delegation facts

The canonical semantic claims signed by the issuer are exactly:

```text
DelegationID
OrgID
PrincipalID
SessionID
CallerWorkloadID
AppInstallationID
RuntimeAudience
Capabilities[]
AuthEpoch
SecurityEpoch
IssuedAt
ExpiresAt
```

The cryptographic envelope additionally identifies `SigningKeyID`; it is key
selection metadata, not a second semantic authorization claim.

It contains no user display data, Profile/Role name, permission maps, FLS/RLS
maps, record identifier, selected fields, Catalog receipt, database value, or
CRM envelope. Capability names are sorted and unique before signing.
`Capabilities[]` is the post-intersection Runtime grant. Public OAuth scopes
are issuer inputs and are not copied into the delegation as a parallel grant
set.

`DelegationID` is the revocation, reuse-binding, and audit-correlation key; it
is not an idempotency key. Repeated use of the byte-identical delegation for
the selected-root read is allowed until expiry only while workload binding,
session/principal/associated-app-if-present state, installation authorization, capability,
AuthEpoch, SecurityEpoch, and lease validation all still succeed.

The token is opaque to L1. P6b owns its cryptographic encoding, fixed signing
algorithm, metadata key, and hard protocol ceilings for token/identifier/set
size, lifetime, and verifier skew. The released contract and immutable vector
are specified by
[nexuscrm-contract `v0.1.10`](https://github.com/pingcap-inc/nexuscrm-contract/blob/v0.1.10/RUNTIME_DELEGATION_V1.md).
P6-D approves the shorter production lifetime, configured skew, and key-overlap
interval in Section 8.1; P6d owns the revocation lookup representation and
authoritative state. P6b cannot change the P6a selected-root reuse decision or
turn `DelegationID` into an idempotency key. A hard ceiling must not be
described as an approved production setting.

## 5. Issuance

The issuer accepts an already authenticated workload credential, a requested
AppInstallation/capability set, and either a raw public user-session bearer or
the private result of the same host-owned AuthService validation. It must not
accept a caller-authored `UserSession`. Raw user bearer material is allowed only
at this identity boundary and is never copied into the delegation or Records
metadata.

Before signing, the issuer must:

1. authenticate the caller workload and bind its audience;
2. run the existing authoritative session validation, including durable
   revocation, current principal activity, associated Connected App state when present, and
   database-owned scope/App facts; any process cache must be fenced by the
   accepted SecurityEpoch/lease or bypassed for the security-critical read;
3. derive Org from Runtime security state, not from a caller field;
4. load the active AppInstallation binding for that Org;
5. intersect workload, installation, existing durable session-scope grants (and
   associated app restrictions only when present), and requested
   Runtime capabilities;
6. bind current AuthEpoch and SecurityEpoch;
7. mint a unique DelegationID and bounded expiry; and
8. sign with an active key ID.

Issuance fails closed on any missing or unavailable authority. It does not
fall back to the public JWT claims, pack activation, route presence, an
environment variable, or a caller permission map.

Independently deployed L1 consumers use the published IdentityContext exchange
RPC over workload-authenticated transport to the same Runtime issuer. A second
L1-owned issuer or token verifier is forbidden.

## 6. Data-RPC admission

Admission order for `ReadSelectedRoot` is:

```text
transport envelope / deadline / compression
→ fail-fast replica admission
→ authenticate workload credential
→ bind the lease-backed replica Org/audience serving context
→ resolve the opaque caller handle to its canonical workload
→ verify delegation signature, key ID, audience, time, canonical shape,
  required capability, and canonical workload
→ revalidate session/principal/associated-app-if-present and DelegationID revocation
→ require signed Org == replica Org and validate AppInstallation + workload + capability binding
→ validate AuthEpoch + minimum SecurityEpoch + SecurityLease
→ install immutable TrustedCall
→ bind P7 RuntimeMetadataView/receipts
→ Records handler / repository
```

The Runtime security admission interceptor, not api-host transport policy and
not the Records handler, owns steps after workload authentication. It installs
one private `TrustedCall` containing the validated delegation facts and the
authoritative current user-session projection required by the existing Records
engine. The handler must not perform a second identity lookup or accept an
independently supplied session.

This replaces the old `Authority` + later `SessionResolver` split. Test-only
constructors may mint signed delegations and supply explicit binding/session
fakes, but production commands contain only the rejecting non-serving
composition until P6d supplies authoritative state.

## 7. Stable failures and disclosure

| Condition | Result | Repository read |
|---|---|---|
| absent, malformed, expired, bad-signature, revoked delegation | `UNAUTHENTICATED` | forbidden |
| missing/invalid workload credential | `UNAUTHENTICATED` | forbidden |
| authenticated workload differs from delegation | `FORBIDDEN` | forbidden |
| wrong Org or inactive/unauthorized AppInstallation | `FORBIDDEN` | forbidden |
| capability intersection does not contain the requested RPC capability | `FORBIDDEN` | forbidden |
| session revoked, principal inactive, associated Connected App disabled | `UNAUTHENTICATED` | forbidden |
| AuthEpoch is old | `UNAUTHENTICATED` | forbidden |
| SecurityEpoch is old or lease expired | `STALE_STATE` on a valid delegation; `UNAVAILABLE` only when no safe current-state determination is possible | forbidden |
| no authoritative replica Org/audience context exists | `UNAVAILABLE`; the Runtime cannot safely audience-bind even a syntactically valid token | forbidden |
| authority persistence/verifier unavailable | fail closed; no legacy fallback | forbidden |

Public errors never reveal whether an Org, installation, workload binding,
session, or Connected App exists. The object Read/RLS/FLS matrix remains owned
by the selected-root ADR after security admission succeeds.

An absent delegation is rejected before replica lookup. If no authoritative
replica Org/audience context has ever been loaded, Runtime cannot distinguish a
valid delegation for that unavailable authority from one with a bad audience;
it masks all present tokens as `UNAVAILABLE` rather than inventing an audience
or misreporting `STALE_STATE`. Once a context has been loaded, malformed and
bad-signature tokens remain `UNAUTHENTICATED` even after its lease expires.

## 8. Atomicity and staleness

One call binds one immutable security view. Runtime cannot validate a
delegation at epoch `E`, refresh policy at `E+1` midway, and then report mixed
receipts. P7 must bind the accepted security view and metadata view before
repository access.

Security-critical revocation does not wait for ordinary metadata TTL. Session
and DelegationID revocation, associated Connected App disablement, installation disablement,
capability removal, and epoch advancement must either be read authoritatively
for the call or protected by an approved unexpired SecurityLease. Once the
lease expires, a partitioned replica becomes not-ready and rejects new work.

Readiness records why serving stopped. A known epoch/lease mismatch or expiry
is `STALE_STATE`; an authoritative owner read failure or missing replica state
is `UNAVAILABLE`. That reason remains stable for later calls until an explicit
successful refresh replaces it. Refresh may update epoch/lease facts for the
same authoritative Org/audience, but missing, malformed, or differently bound
refresh state cannot erase or replace the last identity used to authenticate
delegations. The preserved identity never restores readiness or authorization.
The replica renewal owner is also the sole writer of the cached process lease:
a delayed per-call admission snapshot cannot roll its expiry backward. Such an
attempt still fails closed when its observed lease has expired, but an older
same-epoch expiry cannot invalidate a later, still-valid explicit renewal.

### 8.1 P6-D timing policy

P6-D separates observed implementation facts from approved production policy.
The contract's 10-minute lifetime and 30-second skew are observed hard protocol
ceilings, not defaults. The current P6d path performs one authoritative Runtime
security-state read for every attempt; it does not use a lease as a permission
cache. The selected-root Runtime attempt cap is already 2 seconds.

The first-cutover policy is:

| Decision | Status | Value | Owner and meaning |
|---|---|---:|---|
| Delegation lifetime | **APPROVED** | 60 seconds | Runtime Identity issuer rejects a longer production token |
| Verifier clock skew | **APPROVED** | 5 seconds | Runtime Identity verifier applies it only to delegation `iat`/`exp` |
| Planned old-key overlap | **APPROVED** | 65 seconds | Runtime Identity retains the old verification key for `lifetime + skew` after signing cutover |
| Compromised-key overlap | **APPROVED** | 0 seconds | emergency retirement invalidates outstanding delegations rather than preserving a compromised key |
| Revocation tombstone tail | **APPROVED** | 5 seconds | a tombstone remains through `exp + configured skew` |
| SecurityLease duration | **APPROVED** | 30 seconds | maximum authority-issued readiness fence; not permission-cache lifetime |
| SecurityLease renewal target | **APPROVED** | 10 seconds | the serving-state controller refreshes explicitly; a failed refresh rejects that operation but cannot invent global revocation, so process eligibility remains bounded by the unexpired authority-issued lease while every request still performs its current authority read |
| `MaxSecurityStaleness` | **APPROVED** | 0 seconds | an attempt whose admission begins after commit performs a current authoritative read; no intentional cache window exists |
| In-flight authorization window | **APPROVED** | 2 seconds | existing Runtime attempt-context cap for a call admitted before commit; not a client response-delivery SLO |
| Lease-backed stale serving | **REJECTED** | disabled | every later attempt still performs the authoritative security read |

`MaxSecurityStaleness` is therefore not 30 seconds. For the first slice, a
committed revocation or epoch change is visible to the next admitted attempt;
there is no intentional cached-authority allowance. One immutable request view
cannot change mid-call, so a call admitted before commit retains the existing
2-second Runtime attempt-context cap. That cap is not a promise about protobuf
marshal, transport delivery, or when a client receives bytes. A retry is a new
attempt and must revalidate. A future cached security snapshot requires a new
measured ADR and may not silently inherit the lease duration as a staleness
allowance.

A renewal transport or deadline error is absence of a new authority result, not
evidence that the last authority-issued lease was revoked. It therefore does
not extend the lease and does not authorize a request: the process remains
eligible only until the lease's existing exclusive expiry, and each request
still performs the current authoritative admission read. A request whose read
fails returns `UNAVAILABLE`; a later request retries its own read. An observed
missing state, epoch/lease mismatch, revocation, or lease expiry still fails
that attempt closed immediately. A lease-expiry observation fences process
readiness unless it is demonstrably superseded by a later same-epoch renewal;
the older observation never authorizes the failed attempt. This isolates
transient and delayed reads without introducing permission caching or non-zero
`MaxSecurityStaleness`.

Planned rotation is two-phase. Runtime Identity distributes the new public key
as an accepted overlap key and receives serving-replica acknowledgement before
switching the signer. At signing cutover the new key becomes current and the old
key remains overlap for 65 seconds, then retires. Suspected compromise skips
overlap and retires immediately. Delegation revocation expiry is derived from
authenticated claims as `ExpiresAt + 5s`; a caller cannot shorten it.

Lease time belongs to the authority, not to a replica's wall clock. P7 must
issue and renew the 30-second expiry from authority/database time and publish a
conservative remaining lifetime; a replica clock may only shorten that
lifetime. Delegation verifier skew never extends a SecurityLease. Until P7
implements this owner and binds the security view atomically with metadata, the
production command remains non-serving. V1 must then drill normal rotation,
emergency rotation, clock health, renewal pause/partition, and revocation during
an in-flight attempt before route cutover.

## 9. Required executable matrix

The P6 integration gate uses the real api-host interceptor chain, Runtime
security persistence, current auth/session repositories, generated Records
client, selected-root adapter, and TiDB. It must prove:

- valid workload + installation + capability + session reaches exactly one
  selected-root repository read;
- missing, malformed, expired, bad-signature, wrong-audience, and revoked
  delegations never reach the record repository;
- workload mismatch, cross-org, cross-AppInstallation, inactive installation,
  and missing operation capability are generic forbidden and never reach the repository;
- session revocation, user deactivation, and associated Connected App disablement take
  effect within the approved security-staleness bound;
- old AuthEpoch, old SecurityEpoch, expired lease, authority partition, and
  key rotation fail closed with the approved category;
- diagnostic Org/App/workload duplicates cannot override trusted facts;
- cancellation during workload, session, installation, or epoch validation
  stops the next owner;
- races do not share TrustedCall or user-session state across requests;
- production images contain no test issuer, static grant, default Org grant,
  caller-supplied permission map, raw-user-token Records path, or L1 package.

The cross-org negative must use two distinct authoritative org bindings. Merely
changing a string in a fake delegation against `DefaultOrgID` is not proof.

## 10. Historical P6 implementation sequence

P6 remains one phase but lands in review-sized, dependency-ordered PRs:

1. **P6a — contract and current-tree owner inventory.** Approve this ADR and
   replace vague #3555 status with executable gates.
2. **P6b — neutral delegation model and crypto vectors. Done.** Released
   stdlib-neutral semantic/crypto types as nexuscrm-contract `v0.1.4`, the
   inert metadata carrier as `wire-go/v0.1.1`, and an immutable compatibility
   vector without changing the Records request or protobuf.
3. **P6c — transport workload and Runtime admission seam. Done.** api-host stays
   at transport altitude; Runtime verifies the P6b delegation, revalidates the
   current session through the AuthService owner, installs one immutable
   `TrustedCall`, and the production `SessionResolver` split is deleted. No
   static or test authority enters a command closure.
4. **P6d — authoritative persistence and real-path matrix. Done.**
   Contract #10/root `v0.1.5` authenticates caller-bound claims before the
   installation selector is known, without changing wire bytes. M1 adds
   Runtime-owned security state, session/delegation revocation,
   AppInstallation serving projection, and fenced lease persistence. M2 binds
   that owner into admission/readiness and executes the real TiDB/cross-process
   matrix. No production route or serving command is enabled.
5. **P6-D — security-staleness decision. Done.** Approves the Section 8.1
   values, rejects lease-backed stale serving, and records finite P7/V1
   enforcement gates without enabling production authority or traffic.
   The consumer pin was subsequently re-ratified at contract root `v0.1.10`;
   `pkg/runtime/delegationv1` is byte-unchanged from the previously approved
   `v0.1.7` release.

P6 is complete. P7b may now build the metadata view only as a non-serving path;
P7c/S1 then binds the accepted security and metadata views in one serving
cutover. V1 remains blocked until C0 selects an exact real consumer and P7c/S1
is complete.

The machine-readable P6-D oracle intentionally retains the phase names used at
approval time. Its `P7` gates map to the current P7b non-serving build followed
by the P7c/S1 atomic serving cutover. Its `P5` production-route gates map to V1
after C0 selects the exact consumer. This nomenclature mapping changes neither
the approved timing values nor their owners, and avoids rewriting historical
decision evidence as later phases land.

## 11. Historical P6 Definition of Done and downstream gate

P6 is Done only when:

- one issuer and one admission path own all trusted facts;
- the data RPC contains no user bearer or caller-authored authority fact;
- the production handler receives one immutable TrustedCall and performs no
  second session-authority read;
- every negative in Section 9 fails before record repository access;
- an expired security lease makes the replica not-ready and fail closed;
- real TiDB and cross-process tests prove revocation and isolation;
- exact dependency guards exclude test/L1/static authority from Runtime images;
- `MaxSecurityStaleness`, the shorter production delegation lifetime,
  configured verifier skew, key-overlap interval, lease duration, and renewal
  target are explicitly approved by P6-D; and
- P6 exposes the accepted security epoch and lease evidence as immutable inputs
  that P7c/S1 can bind without a second security-authority read.

Those criteria close P6. They do not make Runtime ready or satisfy a P6-owned
prerequisite by predicting future P7 behavior. The downstream P7c/S1 gate must
atomically bind those P6 inputs to the metadata receipts without a parallel read
path, and V1 remains blocked until that cutover is proven.

## Independent delegated user API callers

Runtime serving v4 may explicitly declare `user_api_callers`, a sorted subset
of its authenticated `authorized_workload_ids`. These identities are user API
clients, not Catalog handler owners or workload consumers. This path currently
supports `runtime.records.query.v1` and `runtime.records.mutate.v1` (including
mutation status). MCP is one L1 consumer; no MCP name or product rule appears
in L0. The declaration is deployment-owned process admission, not a user's
object/field/record permission grant. It does not create a Connected App.

The caller keeps its own workload credential and caller-bound delegation. It
may not also own a selected handler or declare Catalog/workload-consumer
capabilities. No handler identity substitution, RuntimeSecurityBinding SQL
write, Catalog ownership reassignment or Catalog publication is performed.
Existing Catalog-owned workload consumers retain their original grant path.

For this explicit class, the immutable prepared Catalog serving set supplies
installed query/mutation API availability only for its exact organization,
installation and the security epoch freshly read from Runtime persistence. A
missing view, wrong installation/organization, changed epoch or conflicting
existing workload binding denies admission. The same authority is used by
identity issuance and per-RPC admission. There is no fallback from a failed
ordinary workload binding to this class: the caller must be independently
registered in the deployment policy before the process starts.

The fresh Runtime read still owns audience, epoch, replica lease and delegation
revocation. AuthService still owns durable user session/auth epoch and current
permission-state subject; object/FLS/RLS and command idempotency execute normally.
The user client's scope cannot admit workload-only internal execution or
Catalog disclosure RPCs. Removing the caller registration and restarting the
process rejects that client's outstanding delegations; service credential
rotation uses the existing stopped workload-credential replacement path.

This clarifies the earlier workload-equals-handler assumption for delegated
user query/mutation calls only. Metadata/schema ownership and service-handler
activation remain Catalog responsibilities. Deployment validation must prove
a real independent caller, authorized reads/writes, denied access and session
revocation, rather than only an injected client or a successful process probe.