Enterprise Readiness (SOC 2)

Version: 1.0 Date: 2026-04-04 Audience: Engineering, Security, Product, Operations, GTM, Executive Leadership

1) Executive Summary

Yuzu has strong product depth (agent/server/gateway architecture, RBAC, policy engine, OTA, and broad plugin coverage), but SOC 2 Type II and enterprise procurement require controls and evidence beyond feature completeness. This plan defines the capabilities, process controls, artifacts, and timeline needed to:

1. Pass a SOC 2 Type II audit window.
2. Successfully onboard and support a first large enterprise customer.

Guiding principle: Prioritize controls and evidence pipelines that satisfy both SOC 2 and real enterprise customer security reviews, so every investment serves both outcomes.

2) Outcomes and Success Criteria

2.1 SOC 2 Type II Outcomes

• Audit scope and system description finalized.
• Control set implemented across Security, Availability, and Confidentiality trust criteria (minimum), with optional Processing Integrity where required.
• Evidence collection automated for at least 80% of recurring controls.
• Clean internal readiness assessment and successful external audit period completion.

2.2 First Enterprise Customer Outcomes

• Security questionnaire and architecture review passed.
• Customer-required controls (SSO, least privilege, auditability, encryption, incident response) demonstrably in place.
• Production onboarding completed with documented runbooks and named escalation paths.
• Contractual security commitments (SLAs/SLOs, incident notification, vulnerability remediation windows) accepted and operationalized.

3) Strategic Workstreams

3.1 Workstream A — Governance, Risk, and Compliance (GRC)

Deliverables

• Control framework: SOC 2 control matrix mapped to owners, systems, and evidence sources.
• Risk register: Product and operational risks ranked by likelihood/impact with mitigations and review cadence.
• Policy set: Security policy suite (access control, change management, incident response, vendor management, backup/DR, secure SDLC).
• Audit evidence index: Single source listing each control, evidence artifact, generation cadence, and owner.

Implementation Steps

1. Define audit boundary and in-scope systems.
2. Select GRC tooling (or structured repo + ticket workflow if lightweight).
3. Appoint control owners (Engineering, Security, IT, People, Legal).
4. Establish monthly control health reviews.

3.2 Workstream B — Identity, Access, and Administrative Security

Target State

• SSO enforcement for admin users.
• Role-based least privilege and separation of duties.
• MFA requirements for privileged actions.
• Periodic access reviews with manager/security attestation.

Required Features / Controls

• Enforce OIDC SSO for production admin access.
• Disable local-password fallback in hardened mode (or tightly constrain break-glass account policy).
• Add 2FA/TOTP for high-risk approvals (aligned with roadmap hardening).
• Session management controls: revocation shipped (DELETE /api/v1/sessions admin force-logout, DELETE /api/v1/sessions/me self-revoke including API tokens; audit actions session.revoke_all / session.revoke_all.self; Prometheus counter yuzu_auth_sessions_revoked_total). Expiration in place via the existing 8-hour cookie max-age. An inactivity (idle) timeout is shipped as --session-inactivity-secs (YUZU_SESSION_INACTIVITY_SECS) but is off by default (0 disables it), so it takes effect only where an operator sets it. The explicit secure-cookie-attribute review remains open.
• API token governance: scoped permissions, expiration defaults, rotation process, token inventory.
• Local-password policy (CC6.1, #5342) — scope it honestly in a questionnaire: local accounts can change and reset passwords in the product, enforced only by a 12–1024-byte length bound; there is no complexity rule, password-history/reuse check (a same-password change is accepted), expiry/maximum age, or must-change-at-next-sign-in flag. Answer those CAIQ/CC6.1 items as not implemented (SSO enforcement above is the compensating control).
• Residual (#1836): OIDC IdP-group→RBAC deprovisioning (#1832) propagates on the user’s next SSO login, not immediately on IdP-side group removal (a Settings save that changes the admin group does stop a sign-in that was in flight from being minted under the old group; see the OIDC known limitations) — a live session/cookie or an already-issued token retains its prior roles until re-authentication. Session revocation (above) is the operator’s manual mitigation in the interim; automatic mid-session role re-check is tracked in #1836.
• Residual (#5692): This statement covers v0.13.0 and later builds only; earlier releases were not examined. From v0.13.0 until the #5692 fix, OIDC sign-in could not complete in a production configuration: the server did not learn jwks_uri, so every ID token failed signature verification and sign-in failed closed. Do not cite OIDC SSO as an operating control for that window; SAML is a separate implementation, not verified by this change; its known gaps are tracked in #5704. Since the fix it is verified end to end against Keycloak 26.4.0 only (Linux test host, plain http and https via a TLS-terminating proxy); Microsoft Entra ID is supported by the standard, not verified by the project.
• OIDC egress control (#5692): the server’s OIDC requests (discovery, JWKS, Test Connection, token POST) go to hosts named by the IdP’s discovery document or typed into Test Connection. They are resolved by the server, every address is classified, and the connection is pinned to a permitted address: link-local and cloud-metadata addresses are always refused; loopback, RFC 1918, carrier-grade NAT and unique-local addresses are refused unless the process operator starts the server with --oidc-allow-private-networks (not settable from the dashboard or REST). Disclose: no per-host allow-list, no HTTP proxy on the discovery and JWKS path (the Windows token POST uses the system default proxy), the Windows token POST is only pre-checked, strictly (a mixed answer with any refused address is refused outright; DNS rebinding between the check and WinHTTP’s own lookup is not covered; it does not follow redirects and accepts only HTTP status 200), and an http:// issuer or --oidc-skip-tls-verify removes the integrity of the JWKS trust root (the server warns for a non-loopback http:// issuer; plain http:// to a PUBLIC address is refused outright, but http:// to a loopback or private address is allowed with --oidc-allow-private-networks and stays exposed to anyone on that network path). See docs/user-manual/authentication.md “Network and trust”.
• UCE surface (forward ref): the use-case-engine host inherits SSO transitively through this server’s OIDC (docs/uce-host-requirements.md §4.6/NF-9 — Yuzu-as-identity-provider). This doubles #1836’s blast surface: a stale IdP group also gates UCE artifact-minting until the operator’s Yuzu session is force-revoked or the ≤5-min artifact TTL / NF-9(d) liveness floor expires, and it adds a second login-event stream outside the server’s audit perimeter (uce-host-requirements.md NF-6). An access-control reviewer working from this section must follow NF-9 for the second surface.

Evidence

• SSO configuration records, role assignment exports, access review sign-offs, and sampled auth logs.
• MFA step-up gate (CC6.6, REST/dashboard only, 37 routes): yuzu_auth_mfa_step_up_gate_total{outcome,source,surface} counts every evaluation, and every refusal by the central check, except the defensive no-session 401 (counted on the metric only), writes a best-effort mfa.step_up.required audit row (result=error; reason= or, for a stale proof, age_secs=/window_secs=; cid= equal to the response’s X-Correlation-Id; stage=pre_authz; see docs/user-manual/audit-log.md). Caveat for a questionnaire: MCP tools and the 73 REST routes still classified pending are not enforced (in particular the legacy PUT /api/config/{key} writes the same runtime-configuration keys as the step-up gated PUT /api/v1/config/{key} and is not itself gated, and so is the MCP tool set_runtime_config); the gate passes un-enrolled accounts and API-token and MCP-token callers by design, and with --mfa-step-up-window-secs at 0 or less no stale proof is refused (so none is recorded) and SAML sessions pass.
• Gateway-peer authorization (gateway-upstream service): refusals of peers whose certificate parsed are written as session.gateway_peer_denied, which is inside the auth-sample export but is a bounded sample; the complete count is the Prometheus counter yuzu_server_gateway_peer_denied_total, and refusals with no key to attribute are counter and log only (docs/user-manual/audit-log.md). The audit row server.gateway_peer_authz_disabled (written when the server starts with --insecure-gateway-peer) is not in the export, whose action prefixes are auth., mfa., session. and engine_principal.; pull it by action. Pins are fixed at boot, so there is no pin-change audit row: a pin change is a server restart and a configuration change.
• RBAC enforcement-state changes (A1): every PUT /api/v1/rbac/enforcement / set_rbac_enforcement toggle attempt either persists an attributable rbac.enforcement_changed row (docs/user-manual/audit-log.md) naming the caller, the before/after state, and the post-transition administrator count, or fails closed rather than silently succeeding unaudited (REST 503; MCP audit_persisted:false) — the yuzu_server_rbac_enforcement_enabled gauge transition serves as an independent trace of the same event during that window. A refused attempt — whether it is denied structurally BEFORE the admin gate ever runs (a service-scoped token or an engine session, both refused unconditionally) or denied by the gate/store-level guard itself after clearing those structural checks (not a durable Administrator, the caller-authority/regime check, or the destination-survival check) — is ALSO captured as a denied row with cause, not silently dropped — exactly the lockout-risk-relevant evidence this section exists to promote. The yuzu_server_rbac_enforcement_enabled gauge plus the threshold-free YuzuRbacEnforcementChanged alert and its direction-aware YuzuRbacEnforcementDisabled warning-severity companion (docs/prometheus/yuzu-alerts.yml) give a real-time, cross-replica-convergent signal independent of the audit log for the same event.

Addendum — the access-review export was readable by any authenticated user on a default install until #2376 (CC6.2/CC6.1). Recorded here because this section cites “role assignment exports, access review sign-offs” as CC6.2 evidence, and that evidence surface carried a real access-control gap for the period before #2376 shipped. RBAC ships disabled by default, and with it disabled the pre-RBAC legacy fallback in require_permission allowed every Read to any authenticated non-engine session — so GET /api/v1/access-reviews/export, which produces the complete fleet-wide grant population, was readable by a plain user on the shipped default posture, despite being nominally gated on the dedicated AccessReview:Read securable that #2324 cut for exactly this purpose. The same was true of GET /api/v1/rbac/roles and the engine-principal grant graph.

#2376 closes it: those three reads now require an admin effective role regardless of the RBAC toggle, enforced at a single chokepoint (authz_topology_floor.hpp), with a dedicated yuzu_auth_topology_floor_denied_total{permission} counter as the queryable CC7.2 signal. An auditor testing this control should attempt each read with a non-admin session on an RBAC-off install and expect 403. For any assessment covering a period before #2376, treat the grant-population export as having been accessible to all authenticated principals unless RBAC was explicitly enabled on that deployment. Full decision record: docs/security-reviews/authz-topology-floor-2026-08-05.md.

Addendum — the access-review export now states whether RBAC was actually enforced (CC6.2, RBAC delivery plan A3). #2376 above closed who can read the grant-population export; it did not address a separate gap this section’s own evidence framing had: listing every grant proves nothing about whether that population governed real access at all, since RBAC ships disabled by default. GET /api/v1/access-reviews/export (and its MCP twin export_access_review) now carry a top-level rbac_enforcement field — enabled | disabled | degraded — and POST /api/v1/access-reviews freezes the same value onto the campaign row at open time, so a closed review campaign records what RBAC’s state actually was when the population was certified, not just the population itself. Caveat an assessor should know: the stamp is a point-in-time read, not a continuously monitored guarantee — a transient RBAC-store partition can produce a degraded reading (the read couldn’t confirm state; gates still denied defensively) or, on a cached-enabled replica, a stale-but-unflagged enabled reading, and a closed campaign’s frozen stamp never self-corrects on a later read the way the live export does on its next pull. Full discussion, including the operator-facing metric to correlate against (yuzu_server_rbac_read_degrade_total{reason=~"generation_refresh_failed.*"}): docs/user-manual/rbac.md → “The access-review export’s rbac_enforcement stamp inherits this same degrade-vs-outage ambiguity”; field reference: docs/user-manual/rest-api.md → GET /api/v1/access-reviews/export.

Addendum — service-scoped token fleet-wide confinement, durably closed (CC6.1/CC6.3, guardian-confinement-2298 PR 3 — “the flip”, 2026-08-18). require_permission’s service-scoped branch previously admitted any operation the ITServiceOwner role granted — since that role holds broad CRUD across most securables, a token bound to one IT service’s agents could, in practice, reach fleet-wide data with no per-agent narrowing, across every route gated this way (not an enumerated list). The ITServiceOwner ceiling described here applied on those two gates only; the fleet-read gate (require_fleet_read) did not apply it until the #3526 addendum below. This PR inverts the default: a (securable, operation) pair must now also clear a server-side allow-list that ships empty, so a route not yet migrated to real per-request confinement denies a service-scoped token outright rather than admitting it unfiltered — including routes not yet found. Mirrored at the MCP tools/call layer via ServiceScopeClass. This closes the confinement class the “Narrowed 2026-08-14” clause of “The machine-health audit exemption” bullet above (Workstream E) narrowed piecemeal, and is the durable fix that docs/user-manual/server-admin.md’s matching PR2 Upgrade Notes entry’s own “This note does not claim the underlying class is fully closed” caveat anticipated. For any assessment covering a period before this PR, treat a service-scoped token as having had the reach of its minting principal’s ITServiceOwner grants, not the reach of its own service tag, on any route gated solely by require_permission/require_scoped_permission that lacked its own per-request confinement. Three items this PR identifies but does not itself close, to be filed as follow-up issues at this PR’s landing: (1) whoever can set an agent’s service tag effectively moves that agent’s scope membership — this PR does not harden that write path (ADR-1006 Consequences); (2) a known remainder of the per-file deny_service_scoped_* family (PreflightRoutes, schedule_routes.*, and inline checks in device/network/inventory/Echo routes) still names a .permission that cannot admit a service-scoped caller — the same false-self-remediation defect this PR’s own hardening round found and fixed in five sibling sites (.claude/routed-concerns-access-control.md clause 5); (3) the ~15 pre-existing per-file deny_service_scoped_* helpers and the 7 MCP double-deny sites this default-deny makes redundant are scheduled for Phase 2 consolidation, not retired here. Full design: docs/adr/1006-service-scope-default-deny.md; closed route inventory: docs/security-reviews/service-scope-flip-route-inventory-2026-08.md.

Addendum — POST /api/v1/result-sets/from-inventory-query service-scope regression, closed (CC6.1/CC6.3, #4980, 2026-09-25). The addendum above’s closed route inventory (row 25) correctly reported this route’s service-scope gap as closed on 2026-08-18 — that closure was real. An unrelated confinement fix on 2026-09-12 (606b9ec72, closing a real management-group scoping gap on this same route) replaced the route’s require_permission gate with the ADR-0017 fleet_read_fn admit-then-filter chokepoint, whose service-scope branch admits-and-confines a service-scoped caller UNDER RBAC-ON rather than denying it outright (it still hard-403s under RBAC-off, same as require_permission) — silently reopening the cross-service-reach class the flip had closed, on this one route, in RBAC-enabled deployments only. #4980 closed it again with a dedicated deny_fleet_wide_service_scoped call that no longer depends on which underlying gate this route uses, matching the route’s 8 non-dispatch siblings. For any assessment covering the period 2026-09-12 through #4980’s merge, on a deployment with RBAC enabled, treat this one route as NOT covered by the flip’s confinement guarantee above — a service-scoped token holding Inventory:Read could, during that window, mint a result set that its minting principal’s other tokens/session could then read back (owner-scoping keys on the minting principal’s identity, not the token’s own service tag). RBAC-off deployments (the default) were never exposed by this regression. No other route in the closed inventory is affected; this is a single-route regression-and-fix, not a reopening of the flip’s broader closure. Correction also recorded in the route inventory doc itself.

Addendum — POST /api/v1/scope/preview service-scope gap, closed (CC6.1/CC6.3, #4981, 2026-09-28). This REST route did not exist at the time of the 2026-08-18 service-scope sweep (docs/security-reviews/service-scope-flip-route-inventory-2026-08.md) that produced the closed route inventory above — it was added on 2026-09-12 (b00d3cadc), after the sweep, and was never audited into it. It shipped from day one without the deny-first pattern the sweep established for every sibling result-set route: a service-scoped API token was admitted and its match set silently narrowed, rather than denied outright, the same shape #4980 (the addendum above) fixed on a different route. For any assessment covering 2026-09-12 through #4981’s merge, treat POST /api/v1/scope/preview (REST only) as NOT covered by the flip’s confinement guarantee above. The MCP twin, preview_scope_targets, is NOT part of this gap — it has existed since 2026-03-25 and has been structurally denied to a service-scoped token since C8’s default-deny landed on 2026-08-18 (the same day as the sweep), via its kToolSecurity entry’s default ServiceScopeClass::denied; #4981 made no service-scope change on the MCP side. #4981 also fixed a separate, more severe, non-service-scope defect shared by BOTH surfaces: a bespoke per-agent attribute resolver did not evaluate from_result_set:/props. scope atoms, so a negated reference (NOT from_result_set:<id>) silently matched the caller’s entire visible fleet regardless of the referenced set’s real membership — a preview tool giving a misleadingly broad blast-radius answer before a real dispatch. That defect, and the REST service-scope gap, are both now closed: the REST route is denied outright via the shared deny_fleet_wide_service_scoped chokepoint (MCP’s own, pre-existing structural C8 default-deny needed no change), and the match evaluation on both surfaces now runs through the same fail-closed ladder real dispatch uses. The sibling, deliberately out-of-scope gap on /api/scope/estimate (owner-check failure there degrades to “zero members” rather than aborting) remains open, tracked as #5003. Correction also recorded in the route inventory doc itself.

Addendum — service-scoped tokens on GET /api/v1/upload-grants and the ITServiceOwner ceiling on every fleet-read route, closed (CC6.1/CC6.3, #3526). Two gaps in the confinement guarantee above, both closed by one change. (1) GET /api/v1/upload-grants (operator-facing list, UploadGrant:Read) has been session-authenticated since the route was added (2026-08-14, 82319412d, git log -S'"/api/v1/upload-grants"'), and its only gate resolved the list view from the MINTING user’s username. A service-scoped API token therefore inherited its minter’s UploadGrant:Read view, the whole fleet for a minter holding a global grant, and the route was not covered by the flip’s closed inventory (the sweep exempted “upload-grant planes” as a class; the correction is recorded in docs/security-reviews/service-scope-flip-route-inventory-2026-08.md). The MCP twin list_upload_grants refused a service token throughout. For any assessment covering 2026-08-14 up to the point this change is deployed, treat GET /api/v1/upload-grants as NOT covered by the flip’s confinement guarantee. The route now refuses a service-scoped session outright (403, audited as upload_grant.list.access_denied). (2) The ITServiceOwner ceiling on require_fleet_read. That gate admitted a service-scoped token on its minter’s grant plus the service-tag narrowing alone, without checking that ITServiceOwner holds the (securable, operation) pair, so an operator who had revoked a pair from ITServiceOwner still saw service tokens served on every fleet-read route. The gate now applies the same ceiling as require_permission and require_scoped_permission; a definitive miss is a 403 and a failed read is a retryable 503, both audited as auth.fleet_read_required. Under the seeded defaults the ceiling admits the same requests as before for every pair ITServiceOwner holds, so the observable change is limited to deployments that revoked a pair and to pairs the role does not hold (the Enrollment fleet reads are the documented case; see docs/user-manual/upgrading.md). Breaking for service-scoped tokens only; human sessions, engine principals and MCP tiers are unchanged. Evidence for this entry is the governance ledger for #3526.

Addendum — machine-identity resource-bounding (CC6.6, PR 4.4). Engine principals (ADR-1005 class) resolve authority from default-deny RBAC, and assignment refuses the admin / Administrator role names and the built-in roles. A custom role is not blocked, including one that covers every permission (maintainer ruling 2026-10-23, #2485): that case is detected afterwards by the no-admin audit route, which is a pull-only, point-in-time check. ok:true means no role held by an engine principal covers the whole permission grid at the time of the run; a role granting all but one pair is not reported, and nothing schedules or alerts on the check. It evaluates three separate reads (grants, roles, role permissions), not one snapshot. The cadence is the operator’s, and the engine_principal.audit.no_admin run rows (violations=N scope=all|active, then up to ten detected principals) are the evidence the control operated. A dropped success-row write is signalled only by Sec-Audit-Failed on REST (the MCP tool gives no signal). The Tokens page also runs the check incidentally, in the browser, when a viewer holding AuditLog:Read loads the principals panel; that is not a schedule and not a control, so a period with no rows is not evidence that the check ran or that it passed. A machine-identity access review must therefore include the engine grants and a no-admin run. The route and its MCP twin fail closed when a read cannot be answered, so a degraded store is never reported as clean. Risk to be recorded in the risk register: a custom wildcard role on a machine identity is detected, not prevented, with pull-only detection. See the engine-principal routed-concern row in .claude/routed-concerns-access-control.md. PR 4.4 adds the complementary resource-bounding control: a per-principal in-flight concurrency cap and request-rate cap enforced at the server’s single pre-routing chokepoint, so a compromised or malfunctioning engine principal cannot exhaust server capacity via unbounded concurrent or high-rate requests. Credit this pairing (RBAC-bounded identity with a detective check, plus a bounded-resource machine credential) as a CC6.6 control for any privileged/machine-identity access review. See docs/user-manual/engine-principals.md “Per-principal quota cap” for the operator-facing reference.

Addendum — engine-credential rotation confirm pinning (CC6.1/CC6.3, #2384). The overlap-pair rotation’s maker-checker confirm step is pinned to the exact credential being confirmed: the confirm call (REST and MCP) requires the successor token_id the rotate response returned, a stale or mismatched id is rejected with no state change, and the success audit row records token_id=<confirmed id> — binding the attestation evidence to one specific credential. This closes a rotation-confirm replay hazard (a blind retry of an old confirm landing after a second rotation started could previously revoke that later rotation’s still-live credential). Credit as a CC6.3 credential-rotation control with per-credential attestation evidence; the operator-facing flow is docs/user-manual/engine-principals.md §4 and the audit contract is the engine_principal.credential.confirm row in docs/user-manual/audit-log.md.

Addendum — engine-principal revocation latency for LIVE streams (CC6.2, #2367). Answering “how quickly is a revoked machine identity cut off?” now has three distinct figures, and they should be quoted separately:

• New sessions and new delegations: immediate. Session synthesis and the REST/MCP on-behalf-of target checks read the principal store authoritatively on every call. A revoked engine principal cannot obtain a new session or a new delegation at any point after the revoke commits.
• Live held-open streams, same server: next heartbeat tick (~3 s). The per-tick liveness re-check is served from a 15 s cache, but the revoking server invalidates that cache synchronously as part of the revoke write.
• Live held-open streams, other replicas: bounded by the 15 s cache TTL plus a tick. The cache is per-process, so a peer replica honours its own entry until it expires. This is the same class of residual property the 60 s API token cache already carries, and is the figure to quote for a multi-replica deployment.

These figures apply to streams authenticated by an engine principal. Streams authenticated by an ordinary API token have a different, currently-open profile: a token-cache hit is still treated as a fresh confirmation, so for those the cache residency and the outage grace window can still add — the non-additive guarantee below is engine-specific (pre-existing, tracked as #2447). Do not generalise the engine figures to all streams when answering a questionnaire.

An auth store that is unreachable is deliberately not treated as a revocation (it would cut every stream on the fleet at once); such streams ride a bounded grace window and then close with a distinct auth_unavailable reason. For engine streams that window is measured from the last authoritative confirmation, so cached answers cannot extend total survival beyond it. Credit as a CC6.2 revocation control with the bounds above; the operator-facing reference is docs/mcp-server.md “Revocation.” and the upgrade note in docs/user-manual/server-admin.md.

Addendum — per-device dispatch confinement, one seam for every operator surface (CC6.1/CC6.3, #1788/ADR-0033). Every operator-facing dispatch path — POST /api/command, MCP execute_instruction/execute_bundle, REST POST /api/v1/bundles, the dashboard execute route, Echo purge_source, POST /api/instructions|workflows/{id}/execute, and /auto deployment staging/execution (DeploymentRoutes, joined this release — previously dispatched under system authority with no per-device confinement at all) — now intersects its resolved target set against ONE derived visibility decision (derive_exec_visible → dispatch_confined_arms) before sending, instead of four independently hand-rolled arm-classification copies. A service-scoped token is confined to devices tagged with its own service on every one of those surfaces; a global administrator, a JIT-elevated session, or a legacy-RBAC-disabled admin remains full-fleet (their actual authority, not a bypass); the derivation fails closed (a present-empty visible set, never “unfiltered”) if the underlying store is unavailable. (2026-08-17: “unavailable” now also covers a mid-scan read failure on an otherwise-reachable tag store, not just prepare-time/ connection failures — TagStore::agents_with_tag_checked, closed by the PR #3216’s hardening round.) Credit as a CC6.1 least-privilege control and a CC6.3 access-enforcement control with consistent enforcement across every listed surface; operator-facing reference is docs/authz-model.md. Residual, not yet closed, for THIS seam specifically: a purely management-group-confined operator (no global grant) reaching one of the surfaces above is narrowed but not yet reachable — that principal is still denied earlier by the base require_permission gate (the ADR-0017 “correct-but-unreachable” World-A gap) until the admit-then-filter list gate lands (#1714/#1715); do not cite management-group-scoped dispatch on THESE surfaces as an affirmative CAIQ/CC6.1 answer until that lands. The BACKGROUND dispatch paths (scheduler, Guardian push, the policy evaluator) dispatch as system, not on behalf of an operator, and are explicitly out of scope for this control — tracked with the core-owned dispatch chokepoint (#1714/#1715).

REST /api/v1/quarantine (POST/DELETE/GET) is a SEPARATE control, already fully reachable — do not fold it into the residual above. It gates on the per-target scoped_perm_fn chokepoint (check_scoped_permission), not require_permission → dispatch_confined_arms, and is EXEMPT from the ADR-0017 World-A gap: a management-group-confined operator with Security:Execute/Security:Read only through a group succeeds on all three routes TODAY for devices in their group(s), not merely “narrowed” for a future gate. Credit affirmatively as a CC6.1/CC6.3 control now, citing docs/authz-model.md’s quarantine_device paragraph and the MCP quarantine_device twin as the reference implementation.

Amended (#6065 PR-Q): POST and DELETE /api/v1/quarantine are no longer scoped-gate only. The paragraph above describes the route before #6065. Since PR-Q, POST runs the shared dispatch chokepoint (classify_and_authorize_dispatch for quarantine.quarantine, an AdminOrApproval pair) AFTER the scoped gate and BEFORE the attempt audit row and the store write. Evidence to cite for CC6.1/CC6.3: with RBAC on, a non-administrator holding Security:Execute is refused 403 approval_required and a group-only holder 403 forbidden, each writing a quarantine.enable row with result=denied and detail reason=<label> securable=Security, plus yuzu_server_dispatch_denied_total{reason}; with RBAC off the legacy gate already requires the admin role, so there is no change. A group-confined operator no longer “succeeds” on POST or DELETE; GET is unchanged. DELETE /api/v1/quarantine/{agent_id} (release the server record) runs the same check for the quarantine.unquarantine pair, so a caller who cannot create a record cannot end one; a refusal leaves the record active and writes a quarantine.disable row with result=denied. Residual, stated so a questionnaire answer is not overstated: a release still ends the server record only (the DELETE handler dispatches no unquarantine, so the endpoint firewall stays applied until the plugin’s own release action runs), and REST has no approval-ticket path, so this is a refusal, not a four-eyes control; activation of the four-eyes feature is a separate, postponed decision (epic #6060).

Addendum: who can list the issued certificates (CC6.1/CC6.3, 2026-10-23). The issued-certificate inventory (GET /api/v1/ca/issued, filtered or not, MCP list_issued_certs, and the list in the Settings certificate panel) carries every enrolled agent’s subject, SAN and issuing identity. Before this change any Security:Read holder was served it, a management-group-confined one included. It is now withheld from a confined caller and from one with no Inventory:Read grant, and every API and MCP call is audited as crypto.ca.certificates.view. Who is served, stated plainly so a questionnaire answer is not rounded up: with RBAC enforcement off (the shipped default), every Security:Read session, unchanged; with RBAC on, a caller with a global Inventory:Read grant or an elevated (JIT) session. Refused (403): a caller whose Inventory:Read is granted only for management groups, and a Security:Read holder with no Inventory:Read grant at all (holding no grant is not an affirmative admission to a fleet-wide list, and removing a caller’s last scoped grant never widens what it can see). A caller whose access check hits a read failure partway through is answered 503 and is never served the list. Detective control, with its limits: on the route and the MCP tool each success row ends standing=available, each refusal is a denied row ending withheld=confined or withheld=refused, and each failed check is a failure row; the drill’s success rows carry no standing token, the audit row can be missing during the same outage (correlate with yuzu_server_audit_emit_failed_total), and no certificate-specific alert fires on a failed check: the only signals are the shared read-degrade counters and breaker (YuzuRbacReadDegraded, YuzuRbacBreakerOpen for RBAC reads; yuzu_server_mgmt_group_read_degrade_total and YuzuMgmtGroupReadDegraded for management-group reads); a management-group store that is not wired raises no counter, and one that is not open raises none on the CA routes (the fleet gate answers before reading it) but is counted as store_not_open on list-gated routes. The Settings panel and the /crypto drill write no row for a refused caller (confined or holding no grant). Do not state that confined operators cannot read the certificate inventory without these qualifications.

Addendum: the last-Administrator guard for account lifecycle (CC6.1/CC6.2, #4966). Deactivating, deleting or demoting the last active local administrator account is now refused on the Settings user delete and role change and on every SCIM deprovision and group-derived demotion site (a 409 on SCIM, audited as scim.user.last_administrator_refused). Read it as what it is: a recovery rule that keeps the fleet from losing its last administrator through an ordinary operation, not proof that anyone can sign in (a counted administrator may have no usable credential or step-up factor), and not an HA claim. Limits an assessor should know: administrators who sign in only through SSO are not counted until #5182; a rolling upgrade or a rollback runs without the guard on the binaries that lack it; direct SQL against the database is outside the rule; the SCIM Group role recompute has documented known limits and no alert rule ships for it yet (tracked in #5673; the interim SIEM keys are in docs/user-manual/scim-provisioning.md, “Pilot playbook”). Operator remedy and the break-glass exit: docs/user-manual/rbac.md, “If the guard refuses an action you intend”. Risk-register entry: an identity provider that removes a person who is the fleet’s only administrator leaves that person active (loud: audit row, counter, critical event), until an operator promotes a second administrator and demotes the first.

Addendum: approver assurance for approve and reject (CC6.1/CC6.3, #6061, #6079). Approving or rejecting an approval request requires an interactive human session (local or OIDC), a human principal that is not an engine principal, Approval:Approve, a reviewer whose account name differs from the submitter’s (residual (e); this is not a check that two different people were involved), and an enrolled MFA factor with a fresh proof. API-token and MCP sessions are refused with a typed 403 (MCP: -32003). Two checks apply, in this order. The central MFA step-up check (37 named routes; docs/user-manual/authentication.md) runs first and passes an account that has no factor, so on top of it the approver’s own factor rule applies: a local account must have an enrolled TOTP factor and a proof no older than the approver window that was not made before its current enrolment; an OIDC session needs the identity provider to have asserted an MFA-method amr on an ID token issued within the window; a SAML session is refused (#4935; with the step-up window above 0 the central check answers it first with its generic 403, otherwise the approver rule answers with the typed refusal; a SAML-only deployment has no working approver path until that is decided, tracked in #6098). The window is min(--mfa-step-up-window-secs, 300) and 300 when that is 0 or negative, independent of --mfa-enforcement, so neither a mode nor --mfa-step-up-window-secs=0 removes the requirement. Break-glass accounts get no exemption. On a default install (RBAC enforcement off, --mfa-enforcement=optional) the only approvers are administrators and none is forced to enrol, so every administrator who has not enrolled a factor in Settings is refused until it does. Residual risks: (a) an OIDC “fresh proof” means the provider issued an ID token with an MFA-method amr within the window; the MFA itself may predate the token, because the provider can reuse its own session (the server sends no prompt=login or max_age), and no second factor is presented again at approval time; any single MFA-method amr value the gate accepts counts; real re-authentication (auth_time with max_age) is a planned follow-up; (b) clearing an account’s MFA factor ends that account’s dashboard sessions, in a second database commit and not for API tokens. yuzu-server --mfa-reset and an administrator’s own Disable in Settings (which needs a fresh step-up proof unless --mfa-step-up-window-secs is 0 or less, and signs the caller out too, except when it only cancels an enrolment that was never verified) clear the factor in one commit and delete the account’s sessions in another, so the pair is not atomic. Both audit the clear in two phases: an attempted intent row (mfa.reset.breakglass or mfa.disabled) is written first and fails closed, and an outcome row follows the work. No factor is cleared unless the intent row is durable (on the Settings route this relies on the audit store having opened and the audit writer being wired into the route, which server boot requires; the CLI checks the write result directly); an attempted row with no outcome row marks a clear that was requested and whose outcome is unknown; the residual, until the clear and the session delete share one transaction, is the loss of the outcome row (a process that dies after the clear, or an outcome write that fails after it), which leaves the factor cleared, the sessions possibly live and an attempted row with nothing after it. A process that dies between the intent write and the clear leaves the factor intact and the same lone attempted row, so that row alone does not prove the factor was cleared: check auth.users.mfa_enrolled_at. If the session delete fails the factor stays cleared and the sessions stay live until an operator ends them: Settings records mfa.disabled with result=partial, --mfa-reset records mfa.reset.breakglass with result=partial and exits non-zero (both with sessions_ended=failed), and the Settings page offers no retry control (an administrator calls DELETE /api/v1/sessions?username=; the recovery runbook has a single-transaction SQL fallback, which writes no audit row). If the clear itself fails the result is error and the state is unknown, because the commit acknowledgement may have been lost and the clear may have landed: Settings still ends the sessions, and --mfa-reset ends none and exits non-zero. A sign-in in flight when the delete runs can leave a session the delete did not cover; and a replica or CLI image still on an older build ends none and writes no attempted row. sessions_ended counts the durable session rows deleted, expired rows not yet reaped included. Other replicas drop their cached sessions within about one second in normal operation and within 30 seconds while a replica’s session-generation poll is failing; neither bound holds after a database restore or a failover to a lagging standby (runbook, “Sessions are durable”). The outcome row cannot undo the clear, so a failed outcome write after it leaves only the intent row: yuzu-server --mfa-reset then exits non-zero, and Settings logs an error and completes the request. The comparison of the proof with the current enrolment (an older proof is refused after re-enrolment, proof_predates_enrolment) is the second line of defence: it stops an older proof being reused after re-enrolment and assumes the database primary clock does not step backward. ADR-2002 section 4 treats that clock as a security dependency, and keeping the primary’s time source correct is the customer’s responsibility; the shipped detector is the YuzuSessionReapClockAnomaly alert, which sees a backward step only when it exceeds the time since the last accepted session reap pass (nominally about 15 minutes while the session store is open, not a guarantee, plus the alert’s 5 minute hold) and a forward step only when it exceeds about a year. The approver gate’s comparison of the stored proof with the database clock also makes that clock an availability dependency as well as a security one: a database clock behind the sign-in replica refuses OIDC approvals closed with the clock-skew 503 (docs/ops-runbooks/auth-db-recovery.md, “OIDC approvers refused with a clock-skew 503”); (c) a non-admin cannot enrol itself under --mfa-enforcement=optional or admin-only (this refuses the approver mfa_not_enrolled only with RBAC enforcement on; with enforcement off, the shipped default, a non-admin is refused 403 “admin role required” before the MFA gate, so enrolment achieves nothing until enforcement is turned on), so each non-admin approver depends on an administrator-run enrolment sign-in window or on a promote, enrol, demote sequence (docs/ops-runbooks/auth-db-recovery.md, “Enrolling a non-admin approver”), and self-service enrolment is a planned follow-up. Both are trust-on-first-use: whoever completes the enrolment first becomes the account’s enrolled factor, so the runbook requires an out-of-band password handover beforehand and a match of each mfa.enroll.verified row to the intended person afterwards, recorded in the change ticket; an administrator who enrols itself in Settings is in the same position: that enrolment is exempt from step-up and asks for no password, so a stolen session of an administrator who has never enrolled could enrol an attacker-held authenticator and then satisfy the approver rule; --mfa-enforcement=admin-only or required makes sign-in enrol administrators, which narrows this to sessions that already exist when the mode is switched on; (d) the control is active only while every replica serving /api/approvals/* runs a build that has it, a rollback is a security-policy downgrade, and tickets decided before the upgrade gain no retroactive assurance; mixed-version admission during a rolling upgrade is a documented known limitation; the Yuzu project maintainer accepted it as inherent to a rolling upgrade (2026-10-28), recorded in the ADR-1005 exception ledger (entry of 2026-10-28) as a working-session statement, not a signed decision. The compensating record is the change ticket’s per-replica upgrade timestamps, the marker-query extract with its positive control (docs/user-manual/upgrading.md, “Mixed-version admission”) and the load balancer log excerpt. Running more than one server replica is unsupported today (the safe-to-scale gate), so this describes the rolling-upgrade case and is not a statement that multi-replica operation is supported; (e) the reviewer check compares account names only, so one person who holds two identities (a local and an SSO account, or two SSO identities) counts as two reviewers; this is a maintainer-accepted exception (ADR-1005 addendum of 2026-10-19), not a four-eyes guarantee across identities, and the compensating controls are narrowing the identity sources in use, an identity-to-HR-record check at the access review, and periodic sampling of reviewer and submitter pairs. All three are customer-operated: Yuzu neither enforces nor evidences them. The approval.approve audit row carries no submitted_by, so sampling reviewer and submitter pairs needs the per-ticket GET /api/v1/approvals/{id}, which returns it. Running --mfa-enforcement=required is no longer needed to enforce the approver factor, but it remains the only built-in way to enrol non-admin approvers without promoting them, so note its fleet-wide cost if you choose it for the enrolment window: the identity provider must assert an MFA-method amr, and an OIDC session without one gets 401 and loops through re-sign-in at EVERY step-up endpoint (verify amr before enabling; see MFA on SSO sessions and the recovery runbook).

Second residual, CC8.1 (maker-checker on scheduled runs), closed by #6096: every approval stamp, submission time included, is now database time, and a scheduled ticket is marked used when its occurrence is queued, so one approval runs at most one occurrence regardless of server clocks, once every replica runs the fixed binary. Further small residuals (database-clock steps expiring approved tickets, a stale approved status on lists until the next sweep, no approval or schedule alert rules) are tracked in #6097 and #6098. Operator-facing detail: docs/user-manual/instructions.md, “Who can approve”. The MCP half is a recorded exception to the both-surfaces rule: ADR-1005’s exception-ledger entry of 2026-10-18 (docs/adr/1005-headless-platform-use-case-engines.md, revisit 2027-01-18, a re-confirmation date rather than a deadline). Rows an auditor can sample for CC6.3: approval.approve / approval.reject carry (from #6061) an attempted row before the decision and an outcome row (success, or denied with the store’s reason) after it, plus denied rows whose detail starts with approver_assurance: for a bearer or MCP credential that reached the decision surface (an engine credential tried over REST is refused by the central step-up check and recorded as mfa.step_up.required with reason=engine_principal_denied), or for an approver refused for an MFA reason that the approver gate (rather than the central step-up check) answers (mfa_not_enrolled, mfa_proof_missing, saml_mfa_unsupported, account_unavailable, mfa_proof_stale; with the central check active, a stale proof, a SAML session, an engine principal or a deleted or deactivated account is refused earlier, as mfa.step_up.required with stage=pre_authz and no ticket-specific row; the central rows carry the route label in target_id, not the ticket id, so they show who was refused, when and on which route, but not which ticket; only the approver_assurance: rows and the decision rows name the ticket; the user= value of every mfa.step_up.required row is neutralised, a space, =, , or control byte written as _, so a name cannot add a reason= token), result=error rows with detail=approver_assurance:mfa_store_unavailable (the approver’s MFA state or stored proof could not be read) or approver_assurance:mfa_proof_clock_skew (an OIDC proof dated after the database clock), each written before any attempted row, and mcp.approve_request / mcp.reject_request refusals (during a mixed-version window, also result=success rows for those actions from a replica not yet upgraded). The attempted and success rows of a decision made under the control carry detail=approver_assurance:enrolled_fresh_mfa, which marks a decision made by a replica that had the control (it dates the first upgraded replica, not the last old one, so keep per-replica upgrade timestamps in the change ticket); it records that the check passed, not the factor type or proof age, which are evidenced by the adjacent mfa.login.verified / mfa.step_up.passed / auth.oidc_login rows, or, for a proof stamped by a Settings enrolment confirm, by mfa.enroll.verified with step_up_proof=stamped. Evidence for residual (b) is a pair of rows per clear, ordered by the audit id: an attempted intent row written before the factor is touched, then an outcome row. The mfa.disabled rows carry the acting session’s principal, role and session id; partial or sessions_ended=failed marks an incomplete clear, and error marks a clear whose state is unknown. The mfa.reset.breakglass rows carry the OS identity that ran the command as principal; its outcome is success, partial (the session delete failed, detail sessions_ended=failed) or error. Both are inside the auth-sample export. An attempted row with no outcome row marks a clear that was requested and whose outcome is unknown: the process died, or the outcome write failed, after the factor was cleared, or the process died before the clear and the factor is intact. The reconciliation query that lists them is under “Finding a clear whose outcome is unknown” in docs/ops-runbooks/auth-db-recovery.md, which also has the query for outcome rows that ended error or partial; the row definitions are in docs/user-manual/audit-log.md.

3.3 Workstream C — Application and Infrastructure Security

Target State

• Secure-by-default deployment profile.
• Defense-in-depth for data-in-transit, data-at-rest, and supply chain.
• Measurable vulnerability management lifecycle.

Required Features / Controls

• TLS/mTLS enforcement in production profiles.
• Security headers baseline (CSP, frame protections, strict transport settings where applicable).
• Hardened deployment templates (systemd/container) with least privilege and filesystem protections.
• Dependency and image scanning gates in CI.
• Signed release artifacts and provenance attestation.
• Formal secure coding standard + threat modeling for high-risk subsystems.
• MCP tool dispatch validates its internal authorization-registration tables at startup and refuses to boot on drift, rather than silently serving an under-governed tool (fail-closed on internal misconfiguration; #2383).
• Cookie-session writes require a same-site Origin or Referer (CC6.1 logical access, CC6.6 boundary protection, CC7.2 monitoring): one server-wide check, fail-closed, with an audit row and a counter per refusal and shipped alert rules; cookie-session requests that dispatch work, persist state or force a refresh of server state (the guarded reads) are held to the same rule through an explicit reviewed list: a Sec-Fetch-Site header that is present decides alone, and the Origin/Referer rule applies only when it is absent. Design record: docs/security-reviews/central-same-site-write-gate-2026-10.md; operator description: docs/user-manual/security-hardening.md “CSRF protection”.

Evidence

• CI security scan logs, release signing attestations, config baselines, and change approvals.
• Same-site write check: csrf.denied rows retrievable through the audit API, the yuzu_server_csrf_denied_total counter with the yuzu-web-writes alert rules, and the CI tests that pin the decision, the pipeline behaviour and the call site. Residuals at the time of writing: behind a TLS-terminating proxy without a declared https:// trusted origin, an http:// Origin for the same host and port is still treated as same-site (the remedy is declaring the public origin with its scheme; a server that terminates TLS itself requires https://), the per-IP rate limiter is the only bound on a refusal flood, refusals are not yet coalesced into fewer audit rows, and the Windows and macOS legs of the tests have not been run (update when those legs have run). For the guarded reads, fetch metadata cannot distinguish a browser’s own prefetch, prerender or link preview from a user action, a client that sends neither fetch metadata nor Origin/Referer is refused, a request not on the reviewed list is not checked (a source-text test is the best-effort guard, not proof), cookie-reachable reads outside the list remain there by decision, and a plain-HTTP non-loopback listener (or Safari before 16.4) gets no fetch metadata, so those requests depend on Referer and a no-referrer policy would break them.

3.4 Workstream D — Reliability, Availability, and Operational Readiness

Target State

• Predictable service reliability with enterprise-grade runbooks and incident response.
• Demonstrated recovery objectives (RTO/RPO).
• On-call coverage and escalation protocols.

Required Features / Controls

• SLO definitions for API availability, command dispatch latency, and job success rates.
• Alerting and escalation for SLO burn, error spikes, and capacity thresholds.
• Backup/restore automation plus periodic restore drills.
• Incident response lifecycle: detection, triage, containment, customer communications, postmortem.
• Capacity plans for 1k/5k/10k+ agents and documented scaling decision points.

Evidence

• Monitoring dashboards, incident tickets/postmortems, backup logs, restore drill reports.

3.5 Workstream E — Data Governance and Privacy

Target State

• Clear data classification and retention policy tied to product settings.
• Customer-facing transparency about what is collected, retained, and exported.

Required Features / Controls

• Data inventory by table/store/event type.
• Retention defaults and customer-configurable retention policies with enforcement checks.
• Documented deletion workflows and verification procedures.
• Encryption and key management requirements for sensitive data stores.

Evidence

• Data flow diagrams, retention configs, deletion run records, and quarterly data governance reviews.

Data Inventory — server-side SQLite stores

Audit capacity ceiling (Workstream D + G). The audit trail’s paced drain (see the PostgreSQL-stores table below) is now single-sweeper fleet-wide (advisory lease), so the cap is one drain rate, never N replicas × 25,000. It paces at TWO cadences, not one — do not quote only the first figure to a prospect, it understates real capacity by roughly three orders of magnitude: a quiet-operation threshold of ~6.9 audit events/second (25,000 rows/hourly pass, ~600,000 rows/day, yuzu_server_audit_retention_cap_reached_total stays at 0 below this), and a backlog-recovery ceiling of up to ~5,000 audit events/second once that counter starts moving (the guard re-arms every 5 seconds instead of hourly while a backlog persists, still capped at 25,000 rows/pass). The audit store only grows WITHOUT BOUND above the second, much higher figure — a rising cap_reached_total alone means the guard is draining faster, not falling behind; sustained capping with rows_deleted_total not keeping pace is the actual signal. At the 365-day default the QUIET threshold alone is also a storage commitment on the order of 219M rows / ~44 GB. Both cadences are engineering constants, not configuration, so a prospect whose SUSTAINED audit rate exceeds the backlog-recovery ceiling needs a scoping conversation; one that merely exceeds the quiet threshold does not. The storage figure is an ESTIMATE built on an assumed ~200 bytes/row and varies with principal, action and detail length — quote rates as limits, the size as an order of magnitude. Derivation, both cadences’ full reasoning, and the caveats on every figure here: docs/user-manual/audit-log.md (“Capacity”) — this paragraph is a summary, that section is the one home.

Data Inventory — server-side PostgreSQL stores (ADR-0006/0008)

As of the Postgres substrate flip (ADR-0006), born-on-Postgres stores are the server’s primary data home and carry the same data-classification obligations as the SQLite table above. Each new server store registers here.

Every PostgreSQL store in this table fails closed on an unreachable database (ADR-0007 — the server refuses to boot), and is gated into /readyz and /healthz. Beyond boot, software_inventory_store reads are authoritative (ADR-0016 §7): a transient query-time degradation after a healthy boot (pool-acquire timeout, query error) surfaces as a kInternalError from query_installed_software (and a 503 A4 envelope from the REST sibling GET /api/v1/inventory/software), never a successful empty result — so a fleet vulnerability query can never read a transient backend hiccup as “installed nowhere”. The MCP query_installed_software and REST GET /api/v1/inventory/software channels carry a per-agent management-group drop filter, and as of #3290 this confinement is verified effective and CAN be cited as an affirmative CAIQ / CC6.1 answer for these two channels: both migrated onto AuthRoutes::require_fleet_read (ADR-0017’s admit-then-filter primitive) as their sole authorization gate — a management-group-confined operator now gets a genuinely filtered result (never an unfiltered one, never a 403 before the filter runs), and a service-scoped API token’s result is additionally intersected with its own service-tag scope. Real end-to-end coverage against a live RbacStore/ManagementGroupStore exists in tests/unit/server/test_rest_inventory_software.cpp’s [e2e] cases. The third channel reading the same store — the /software page’s devices expansion (/fragments/inventory/software/devices, inventory_routes.cpp) — remains unmigrated: it still gates on the global Inventory:Read permission, under which the per-agent filter does not narrow results (a management-group-confined operator is denied at the gate before the filter runs; a global operator’s filter is a no-op) — the same inert-list-scoping class documented in ADR-0017, tracked as that ADR’s still-open devices-expansion conversion item. Until that channel migrates, answer the CAIQ confidentiality question for the /software page reads (the catalogue, the version drill and the devices expansion) specifically as “designed, not yet verified”; the Hardware list and CI record on /hardware are the affirmative require_fleet_read case above — the REST/MCP answer above is now affirmative. Per-device decommission erasure is now wired for the eight stores in the ADR-0024 AgentDecommission cascade (inventory, software_inventory, device_inventory, app_perf_daily, software_licensing, app_usage, offline_endpoint, certificate_inventory) via the audited DELETE /api/v1/sle/agents/{id}. What #1666 still tracks is the residue: row-level / per-subject DSAR erasure (the cascade is whole-device only) and the per-agent stores outside the cascade, including response_store, preflight_run_store, deployment_run_store, discovery_store, tag_store, vuln_finding_store (its delete_agent exists but is not wired) and guaranteed_state_store; where a store’s row states its erasure status that row is authoritative, and a store absent from the eight listed here is not erased by the cascade. The offline_endpoint_store age-out prune is #1545. For a device that ages out without being decommissioned, last_seen remains the canonical “is this device still active” filter for asset-management counts. guaranteed_state_store’s GET /api/v1/guaranteed-state/status fleet-wide aggregate is CONFINED and this can be cited affirmatively for CC6.1 on this specific surface — unlike the software_inventory_store gap above, this route’s SOLE authorization gate is AuthRoutes::require_list_read (ADR-0017 admit-then-filter): a global GuaranteedState:Read grant sees the fleet-wide count, a management-group-confined grant sees errored_rules scoped to that operator’s visible agents only (applied in SQL before the aggregate, INV-3), and a caller with no grant anywhere is refused with 403. An earlier version of this wiring (commit 9269b5636) stacked a direct RbacStore::authorize_list_read call BEHIND the pre-existing flat require_permission gate rather than replacing it — that composition was a no-op for every management-group-confined caller (require_permission’s RBAC check never consults ManagementGroupStore, so a confined caller was denied before authorize_list_read was ever reached) and additionally broke JIT-elevated sessions; it was corrected before this affirmative claim became true. require_list_read is RbacStore::authorize_list_read’s first production call site (previously chartered but unbuilt, #3038 — reopened after the premature 9269b5636 closure above, and reclosed once this fix is verified/merged, not before) — the software_inventory_store list-read gap documented above is a SEPARATE, still-open surface and this fact does not resolve it. total_rules on this route is deliberately never confined: it is the size of the global rule-definition catalogue, which carries no agent or management-group dimension to confine. As of #1712, the same require_fleet_read primitive covers three more surfaces, and this confinement CAN be cited affirmatively for CC6.1 on each: the dashboard /fragments/results results table, the workflow executions-drawer detail route (both its per-agent responses section and its status grid/table), and MCP get_agent_details — all three migrated onto require_fleet_read as their sole authorization gate, replacing a flat permission check that previously either showed a confined operator the whole fleet’s data or denied them outright. get_agent_details on an out-of-scope agent returns the identical “not found” response a genuinely nonexistent agent would, so the tool cannot be used to enumerate the fleet outside a caller’s scope. Two adjacent surfaces on the same dashboard page remain unmigrated and must NOT be covered by this claim: the results table’s sibling sidecar routes — /fragments/results/filter-bar, /fragments/create-group-form, and POST /api/dashboard/group-from-results — still gate on the flat, unscoped permission (tracked #3489; #3525 tracked the same finding and was closed as its duplicate), and GET /api/v1/execution-statistics/agents (with its MCP twin get_execution_statistics_by_agent) carried the same unscoped shape (tracked #3526) and is now confined on the same chokepoint (global grants unchanged; the by-definition and fleet-summary aggregates carry no agent identity and keep the plain gate). That confinement is effective only with RBAC enforcement on: with RBAC off (the shipped default) the per-agent rollup is unfiltered for every authenticated non-service, non-engine caller, so answer CAIQ for it as “designed, verified for RBAC-on, unconfined in the default posture”. A management-group-scoped-only operator, refused before, is now admitted as a confined view (admission widened, rows narrowed). The workflow executions LIST fragment (formerly listed with it) and MCP summarize_working_set kind=execution are now on the fleet-read chokepoint like the DETAIL route. An author-run reachability probe (run by a subagent of the authoring session, not independently adjudicated; the JIT-elevated case was checked by code reading only) found they had not been a reachable leak through the old gate, only a capability gap for group-scoped operators, while summarize_working_set kind=fleet/result_set still return an unscoped whole-registry agent count (tracked #4753). Confinement on these two surfaces is effective only with RBAC enforcement on. With RBAC off (the shipped default) both are unconfined for every authenticated non-service, non-engine caller whose tier allows it (an engine principal is refused with 403 with RBAC off), identical to GET /api/v1/executions. Answer CAIQ “designed, verified for RBAC-on, unconfined in the default posture”. Service-scoped-token confinement of execution data is not cited affirmatively until #5557 closes: a service-scoped token’s session username is the account that minted it, so the owner disjunct still shows the minter’s executions outside the service scope on the other execution read surfaces. Answer the CAIQ confidentiality question affirmatively for the three #1712 surfaces specifically; for the dashboard results page and workflow drawer as a whole operator workflow, the sidecar gaps mean “designed for, partially verified effective” until #3489 closes. Update (#1634, closed) — the SSE gap #3699 tracked is now fixed and CAN be cited affirmatively for ordinary callers; service-scoped-token confinement of /sse/executions/{id} and /api/v1/events is not cited affirmatively until #5557 closes (both still carry the minter-keyed owner disjunct). The live SSE channels for the identical execution/agent data the #1712 surfaces above confine on the request/response path — /sse/executions/{id} (dashboard) and /api/v1/events (REST), both backed by ExecutionEventBus — are now on require_fleet_read/fleet_read_fn, the same primitive as every other surface in this section. Both routes 404-collapse an invisible execution to the same shape a genuinely nonexistent one gets (no existence oracle), and share one event projector (execution_event_scope.hpp): agent-transition events are filtered by agent_id before delivery, execution-wide execution-progress counts are dropped for a confined subscriber rather than disclosed, and the terminal execution-completed event is sanitized (real status preserved, counts/identifiers stripped) rather than dropped outright, so the client still closes its stream cleanly. Same round also migrated GET /api/v1/executions/{id} (REST final-state lookup) and MCP get_execution_status/query_responses/aggregate_responses/the legacy /api/responses/* family onto the same gate. These legacy routes are confined and write a durable success audit row on every served read, failing closed on audit-persist failure like their v1 twins (#4644; the earlier gap is recorded in #5556). Residual, not yet closed: MCP list_executions has a weaker mechanism than every other surface in this section — execution rows carry no single agent_id to filter by, so a confined caller is restricted to their own dispatches (ExecutionQuery::dispatched_by) rather than a genuine per-row visible-agent intersection; do not cite this specific tool as fully equivalent to the others until a batched (non-N+1) per-row check replaces that interim confinement. Full account: docs/auth-architecture.md’s “Third migration (#1634)” section. GET/PUT/DELETE /api/agents/:id/properties[/:key] (server.cpp) previously read and wrote per-agent custom-properties data behind bare require_permission("Infrastructure","Read"/"Write") with no per-agent scope filter at all, including the WRITE path — now fixed (#3700): all three routes gate on require_scoped_permission("Infrastructure","Read"/"Write",agent_id), the same primitive the Tag and per-device routes already used, verified by gate-level coverage against a live PostgreSQL-backed RbacStore/ManagementGroupStorePg plus a source-text tripwire pinning the route handlers to the scoped gate (tests/unit/server/test_agent_properties_scope_authz.cpp) and this repo’s /governance pipeline. This can be cited affirmatively for CC6.1 on the custom-properties surface specifically — a distinct data class from the execution/agent-status data #3699 still gates. Caveat carried forward from #3700’s own PR review, not yet closed: POST /api/scope/estimate (workflow_routes.cpp) evaluates caller-supplied scope expressions — including property:key=value atoms — against the whole fleet with no management-group confinement, returning a matched count; any authenticated non-service principal can guess-and-confirm an out-of-scope agent’s property value via the 0→1 count flip, a side channel that survives the request/response confinement this PR just closed. Tracked #3753 — do not treat the CC6.1 affirmative claim above as covering this read-side channel until it closes. Precision note, not a scope narrowing: the fix restores confinement for a management-group-scoped-only operator (previously denied outright on every agent — “inert confinement,” not over-broad access); a caller holding a global Infrastructure:Read/Write grant retains unconditional fleet-wide access on this surface before and after, identical to every other require_scoped_permission call site in this codebase — that is by design, not a residual gap of this fix. The #3564 audit-detail unification (closing the get_agent_details existence-oracle) is a deliberate compliance tradeoff, not merely a security one: the audit trail can no longer distinguish “agent doesn’t exist” from “agent exists, out of caller’s scope” in any durable record (query_audit_log-readable detail field) — the distinguishing fact survives only in a server-side spdlog::debug line, not typically enabled in production. If a SOC-2 auditor asks for forensic evidence separating these two cases from the audit log alone, the honest answer is “not recoverable from durable audit records by design” — the collapse is what prevents the audit trail itself from re-disclosing the existence-oracle this fix closes on the response channel.

Authorization substrate (rbac_store, ADR-0041) — a CAIQ / CC6.x posture note. In addition to the boot fail-closed above, rbac_store authorization reads fail closed (deny-on-degrade): a store-not-open, pool-acquire timeout, or query error denies the request (403/503, never a silent allow) rather than falling through to an engaged allow. This is a positive change over the prior SQLite rbac.db posture, where a corrupt/unreadable RBAC store could fail open at some call sites — an affirmative improvement to cite for the access-control confidentiality questions (CC6.1/CC6.3). The rbac_enabled flag is durable and read-back-verified; an unreadable flag refuses boot, so a fleet that enabled RBAC can never silently boot RBAC-off. One honest caveat for CAIQ: across multiple server replicas, a role/permission/enabled-flag change is propagated within a bounded ~1 s window (a durable rbac_meta.write_generation coherence token, refreshed ≤ once/second), so cross-replica revocation is near-real-time but not strictly instantaneous — an accepted, gate-recorded residual risk (well inside the fleet’s minutes-scale session/token revocation envelope; LISTEN/NOTIFY is the named follow-up to drive the window to zero).

Availability posture under PostgreSQL degradation (#2703 Gate 7 merge-slice, availability-hardening pass) — assess alongside Workstream D, do not read as availability resilience. The deny-on-degrade behaviour above is not instantaneous on every blip, and two independent mechanisms govern it — they must not be conflated. (1) Cache validity is governed solely by a bounded ~5 s window past the last confirmed-good cross-replica refresh: an already-cached authorization decision continues being served from that cache for up to ~5 s of backend degradation regardless of what else is failing, a deliberate bounded-staleness-for-continuity tradeoff layered underneath the ~1 s propagation window above; once that 5 s bound is exceeded, the cache is invalidated wholesale and every subsequent check requires a fresh answer. This holds even when no refresh attempt ever completes — a query genuinely stuck in flight (e.g. blocked on the ACCESS EXCLUSIVE-class lock described below, which can hold for the full ~10 s lock_timeout) previously left the cache trusted and unbounded-stale for the whole stall, since nothing else ever ran to invalidate it; the staleness check now measures elapsed time directly rather than depending on a refresh attempt’s own completion (closed 2026-08-11, same-day, pre-merge, never shipped — G11-CPPEXPERT-B2). (2) A fail-fast breaker independently governs pool access, not cache validity: it does not clear the cache and does not shorten the 5 s window, but once it observes 2 consecutive pool-acquire/query failures, any check that is not already a cache hit (a first-time lookup, or any lookup once the 5 s bound has passed) denies immediately without attempting a pool acquire, rather than blocking for the 250 ms per-attempt acquire budget first — and it paces recovery to one probe per ~1 s while open. How fast the breaker actually trips depends on WHY the backend is degrading — two measured modes, not one: when connections are unavailable (pool exhaustion — no connection to acquire), each attempt fails within the 250 ms acquire budget, so 2 consecutive failures trip the breaker in well under a second (suite-verified: [rbac]’s breaker test asserts elapsed < 150 ms against injected failures). But when a query acquires a connection and then blocks on a PostgreSQL-side lock rather than failing to acquire one, the 250 ms acquire budget does not apply — that block is bounded instead by PgPool’s lock_timeout (10 s default), and 2 such attempts before the breaker trips measured ~18.5 s live against a held ACCESS EXCLUSIVE lock on rbac_meta (tracked: #3016). Correction (verified empirically 2026-08-11, live against postgres:18): an earlier draft of this note claimed ordinary role/grant writes could trigger this lock-contention mode. That is wrong and has been corrected — PostgreSQL’s MVCC means a plain UPDATE/INSERT takes only a row-level lock, which does not block a concurrent plain SELECT (confirmed: a SELECT against a row held open by an uncommitted UPDATE returned in 19ms, reading the pre-UPDATE snapshot, exactly as MVCC predicts). The generation-refresh query is a plain SELECT with no locking clause, so ordinary role/grant/group-membership writes cannot trigger this mode. What DOES trigger it is specifically an ACCESS EXCLUSIVE-class lock (confirmed: an explicit LOCK TABLE ... IN ACCESS EXCLUSIVE MODE blocked a concurrent SELECT for the held duration) — i.e. genuinely DDL-shaped events: a schema migration, or an operator issuing an explicit table lock / equivalent maintenance command. The original #3016 characterization (“a schema migration or a manual maintenance/vacuum-full-class event, not routine load”) stands as written; it is not a routine-traffic-reachable condition. A third, unmeasured (analysis, not empirical) mode — call it the dark-network mode — is worth naming for completeness: a backend that is reachable but silent — a dropped connection on a network path with no RST, e.g. behind a stateful firewall or NAT that drops the session without signaling it — is bounded not by lock_timeout but by the TCP-level tcp_user_timeout (10 s default, this same hardening pass) layered on top of keepalives_idle (30 s default, the keepalive clock only starting once the connection goes idle after being ACKed); working through that arithmetic gives roughly ~40 s for 2 such attempts, notably worse than the measured lock-contention figure — this number has not been empirically reproduced the way the ~18.5 s figure was, and should be treated as an upper-bound estimate, not a measurement. Both measured modes converge on the same outcome — a fail-closed deny, never an allow — only the time to get there differs by roughly 40x depending on the degradation’s mechanism. Net effect under a sustained outage: previously-seen decisions keep answering from cache for up to ~5 s regardless of breaker state; a new/uncached decision during that window denies once the breaker has tripped, at a speed set by which of the modes above is occurring; and once the 5 s bound elapses, the store denies every check, fleet-wide, until the backend recovers. Flapping — repeated short degrade/recover cycles, not one clean outage — is a materially different and arguably worse case for CAIQ purposes than a sustained outage: the breaker’s failure streak resets to 0 on a single success, so each brief recovery reopens it to full concurrency rather than easing back in gradually; a backend cycling between degraded and briefly-healthy (the shape a managed-Postgres failover or an intermittent network partition actually produces) can therefore drive repeated full-concurrency retry bursts against a still-struggling backend rather than the single clean trip-and-stay-open a sustained outage produces (redesign tracked as a follow-up to #3016 — a half-open concurrency cap, not shipped in this pass). No operator action is required for recovery in either mode — the breaker self-heals: the very next probe that succeeds (at most one cooldown, ~1 s, after the backend genuinely recovers) closes it again automatically. Blast radius while the breaker is open is bounded by the shared connection pool, not by which table degraded: RbacStore maintains one breaker per replica process, shared across every authorization call site (direct permission checks, scoped checks, the ADR-0017 admit-then-filter list-read helpers, and the ITServiceOwner ceiling read that service-scoped-token requests make on the fleet-read gate and on the two sibling gates, which is one uncached PostgreSQL query per service-token request that reaches the ceiling check) — a degrade touching one table denies checks against every securable type on that replica while open, not only the one that degraded. The CAIQ-relevant consequence: this is a confidentiality-over-continuity design, not an availability guarantee. Sustained PostgreSQL saturation or loss still ends in every gated operation becoming unavailable — a control-plane availability impact, not evidence of resilience to it — it just does not happen on the first millisecond of degradation. This posture must be assessed together with Workstream D (reliability) controls and PostgreSQL’s own high-availability posture, never cited on its own as an availability answer. The same posture applies to gateway session resolution (HA WS-5 slice 2, ADR-2002 §7f): BatchHeartbeat resolution is fail-soft on a degraded directory read (a locally hinted pair is still acked and its lease renewed; an unreadable id with no local hint is neither acked nor listed), while NotifyStreamStatus CONNECTED on a degraded read is accepted only for a session this replica holds locally and is otherwise refused (connected_unverified); evidence is metrics and logs only, with no per-event audit row, except the announce_connected/session_held_by_other_agent refusal (#5683), which writes a gateway.session_held_by_other_agent audit row.

Investigating a denied authorization check during a PostgreSQL degradation window. The audit trail records the denial itself (an authorization failure event) but does not, at that same record, distinguish “the breaker was open and this was denied without a pool touch” from “the store was healthy and this was a genuine no-grant denial” — both are recorded as an ordinary denied check. To tell them apart during an incident review, cross-reference the denial’s timestamp against yuzu_server_rbac_breaker_open (was the breaker open on this replica at that time?) and yuzu_server_rbac_read_degrade_total{reason="pool_acquire_timeout"} (did a degrade fire in that window?) in the metrics history, rather than the audit event alone. This is an investigative recipe, not an automated correlation — the audit record and the metrics are two separate systems and a future improvement could join them at write time; until then, a reviewer doing incident forensics needs both.

Confinement substrate posture (management_group_store, ADR-0042) — affirmatively citable for CC6.1. Unlike the software_inventory_store list-read caveat above (whose per-agent filter is inert under the current global gate), the management-group hierarchy reads that feed confinement are now degrade-distinguishable and fail closed to DenyAll: a store-not-open / pool-acquire-timeout / query-error on an ancestor/descendant/agent-groups read resolves to deny, not to a silently-empty deny-set. This closes the deny-set fail-open hazard (a degraded confinement read can no longer silently under-restrict an operator’s scope) and is surfaced operationally via yuzu_server_mgmt_group_read_degrade_total{reason} + the YuzuMgmtGroupReadDegraded alert. This behaviour of the confinement substrate itself can be cited affirmatively in a CC6.1 (logical access — least privilege / segregation) answer. Note the distinction from the ADR-0017 admit-then-filter gate on list surfaces (still landing per the caveat above): what is affirmatively true here is that the confinement data plane fails safe.

Result-set store posture (result_set_store, ADR-0036) — affirmatively citable for CC6.1/CC7.2. As of #4306, the per-owner quota check (count_for_owner_checked) and the membership/list/lineage reads (members_checked/list_by_owner_checked/lineage_checked) that back result-set dispatch targeting and materialisation are now degrade-distinguishable and fail closed: a store-not-open / pool-acquire-timeout / query-error resolves to a std::expected DbError — surfaced as 503/500 at the REST and MCP surfaces — never a silently-empty or silently-truncated container standing in for a genuine answer. This closes the same class of hazard the management_group_store row above closes for confinement reads: a degraded quota read previously returned 0, indistinguishable from a genuinely-empty owner, letting an over-quota dispatch fire before the authoritative in-transaction recheck (which runs after dispatch) ever got a chance to refuse it; a degraded membership/lineage page previously truncated silently, materialising an incomplete member set that future dispatches would target as if it were complete. This behaviour can be cited affirmatively for CC6.1 (least-privilege quota enforcement is no longer bypassable by a transient backend blip) and CC7.2 (a degraded read is surfaced to the caller as an error, never silently masked as a complete/successful answer) on the async result-set producers and the GET /api/v1/result-sets family specifically.

Addendum — result-set device_ids had no existence/scope/authorization check on any of three surfaces, closed (CC6.1/CC7.2, #4983, 2026-09-30). POST /api/v1/result-sets, MCP create_result_set, and the dashboard’s own CSV-paste import (POST /fragments/result-sets/create) accepted an arbitrary caller-supplied device_ids array with only a type check and an array-size cap — no RBAC gate of any kind ran on this field, and no entry was checked for existing or being within the caller’s own scope. A nonexistent id, or a real id outside the caller’s management-group/service-scope confinement, was silently accepted as a member. All three surfaces now gate a non-empty device_ids through the admit-then-filter Infrastructure:Read chokepoint (fleet_read_fn, ADR-0017) and validate every entry against the presence-merged fleet (HA WS-5) plus the caller’s own visible scope, rejecting the whole request (oracle-safe — a nonexistent id and an out-of-scope id are indistinguishable in the response) with an audited denial on every surface. This is a genuine breaking change under RBAC-enabled enforcement: of the 7 seeded built-in roles, only Administrator and ITServiceOwner hold Infrastructure:Read — disclosed in docs/user-manual/server-admin.md’s vNEXT entry, independently verified against RbacStore::seed_defaults()’s actual grant lists.

Daily-sync PII carve-out (ADR-0024 Decision 11). The ADR-0016 daily-sync framework was specified machine-scope / no-end-user-PII, and the installed_software and device_ci rows above still hold to that (no usernames, no per-user attribution — those statements remain true). The software_licensing source deliberately deviates — and only that source: at the owner’s explicit direction it probes per-user licence surfaces, so its records may carry user_scope=user + a pseudonymous user_ref (see the software_licensing_store row above). This is a contained, maintainer-signed-off deviation confined to two fields on this one source. Default hash mode keeps user_ref pseudonymous (still personal data under GDPR Recital 26); --license-scan-user-ref=omit suppresses the identifier; --inventory-disable turns the source off entirely. It does not relax the machine-scope posture of any other daily-sync source (installed-software, device-CI, app-performance). Full per-surface disclosure — exactly what is probed on Windows / Linux / macOS, and the honest limits of the hash pseudonym — is in docs/user-manual/software-licensing.md, the works-council-reviewable transparency evidence.

UCE host stores (engines/, own PostgreSQL — separate deployable, ADR-1005)

Use-case-engine (UCE) modules run in a separately-deployed host with its own PostgreSQL database, never the server’s connection pool (ADR-1005 plan Decision 11). Data a UCE re-serves or derives sits outside the server’s audit perimeter (ADR-1005 Decision 5), so the UCE host carries its own audit/compliance controls for it. Topology (2026-07-12, accepted trade-off): the UCE data layer is a separate database on the server’s own PostgreSQL instance — not a separate instance — with a dedicated role/grants, cross-database access forbidden and mechanically revoked, and TLS-only remote access from the UCE VM (full design + isolation mechanics: docs/uce-deployment-topology-design.md); so this row’s “separate database” MUST NOT be read as instance-level isolation for CAIQ/CC6.1 purposes. This row registers the derived store here for inventory completeness. Entries are forward-declared — the store ships at the vuln module’s store-ship milestone (requirements: docs/uce-host-requirements.md §7 + F-12, exec-plan item 2c) — following the recommendations.db (proposed) precedent above.

Confinement maturity caveat (same posture as the server-store note at the top of this section): the findings-view management-group confinement this store depends on (uce-host-requirements.md §6) resolves through the ADR-0017 admit-then-filter chokepoint, which is chartered but unbuilt today — so findings-view operator confinement is designed, not yet verified effective, and MUST NOT be cited as an affirmative CAIQ / CC6.1 answer until M3(d) verifies it (uce-host-requirements.md F-5/F-15). The same “designed, not verified” caveat applies to the operator login / SSO surface (uce-host-requirements.md NF-9, Verify = “stack ADR (T2b) / security-guardian” — not yet built): “UCE inherits Yuzu SSO” MUST NOT be cited as an affirmative CAIQ/CC6.x answer until T2b ships and security-guardian signs off. There is no collection-level off-switch row for this store because the UCE vuln module is itself a separately-deployed, opt-in artifact — a customer without works-council sign-off simply does not stand it up; the only per-store knob is retention.

Retention-guard coverage is partial, deliberately. On the server, the audit trail (#2360), the Guardian-event store (guaranteed_state_store, ADR-0038/#2496/#2579/#2663), and the response store (ADR-0039, this PR — the #2508 treatment for that store) are clock-guarded and capped; on the agent, the Echo edge warehouse is (#2361 - see the retention note under the agent-side section below). The remaining stores queued for the same #2508 treatment (app_perf_*, PreflightRunStore, DeploymentRunStore) still issue a bare DELETE ... WHERE ttl_expires_at < now driven by the server’s wall clock, so a forward clock step can empty one of them in one statement. They are lower-stakes than the evidence trail (operational telemetry, not the SOC 2 control record). An auditor reading this table should not infer that “clock-guarded” applies to every row in it. Nor that “clock-guarded” means fully guarded in every state: until #2579 the audit trail’s own guard had no missing-anchor trigger, so a server upgraded to schema v3 while its clock was ALREADY skewed forward could delete expired rows with no decline and no counter. That is now closed - such a pass declines once and anchors the reading. The honest answer to “can the audit trail be silently truncated?” is therefore not on a current build; yes on a build predating #2579, under a forward-skewed clock at upgrade - and there is no reliable retrospective test to confirm whether a given database was affected, nor recovery without a backup predating the pass.

Agent-side edge warehouse (echo.db, per device — federated, ADR-0004)

Most device telemetry stays on the endpoint in the Echo edge warehouse and is queried on demand (operator SQL, the /dex device-perf panel) rather than centralised. The performance tiers added in this release:

These tiers are device-local; raw rows never leave the endpoint except via an operator-initiated, permission-gated query (the /dex device-perf panel runs a live $Perf_Hourly query, Execute-gated and audited dex.device.perf.query). The perf tiers use RetentionType::kTimeBased; $Process_Live uses RetentionType::kRowCount (100 000 rows) — see the retention-control caveat below.

Retention numbers are inline defaults; time-based stores expose a retention_days constructor argument so a customer can tighten them without a code change (retention_days = 0 disables the reaper — intended for forensic freezes; requires a compensating manual-export process to avoid unbounded growth). Exception: $Process_Live is row-capped, not time-based, and the cap is not yet operator-configurable — on a busy endpoint 100 000 rows can be days of history; making the process raw cap (or its conversion to time-based retention) operator-tunable is a tracked follow-up so the per-category retention commitment holds for process data too. The $DNS_Live / $ARP_Live tiers (ADR-0015) are likewise row-capped (5 000) on the Live tier with a time-based 24 h Hourly tier; the DNS-cache PII erasure path today is disable the source (dns_enabled=false) + ring-wrap / Hourly reaper (no dedicated per-subject DELETE) — and since DNS rows are device-level with no pid, they are not subject-attributable, so a per-subject DSAR maps to the device, not an individual. A dedicated DSAR/erase path is the same tracked roadmap gap noted below.

Every retention number above is a floor, not a ceiling (#2361). The reaper runs on the 900 s echo.rollup tick, and is now clock-guarded and paced:

• Time-based tiers are clock-guarded. Before deleting, each table is probed for whether the cutoff would expire every datable row it holds. If it would, the pass declines that table once and records the decline, rather than emptying a forensic window in one statement because the endpoint’s clock jumped. A reading persisted in echo_config (retention_guard_last_pass) makes the guard survive agent restarts; a stored reading that is ahead of the current clock AT ALL, or a jump of more than 30 days between passes, is itself treated as implausible; a pass that finds NO stored reading (the first after an agent upgrade or restore) also declines, once, and is the one trigger that does not spend the latch (the 24 h slack is a separate rule, and applies to row timestamps, not to the stored reading). The guard paces deletion, it does not block it: after the one declined pass the latch releases the table to the capped delete below, so a genuinely wrong clock still drains its backlog at 5 000 rows/table/tick. What the guard buys is a recorded decline and the time to notice, not indefinite preservation.
• Both tier kinds are paced. A single pass deletes at most 5 000 rows per table, time-based and row-capped alike. A large backlog (a long-powered-off laptop, or an upgrade that lowers a retention setting) drains over successive rollup ticks instead of one multi-second write transaction. Rows therefore survive past their nominal window while the backlog drains - deliberately, and bounded by the tick rate.
• The evidence surface is the echo status action, since the agent has no /metrics endpoint. It emits retention_guard_declines_total|<n> and retention_guard_failures_total|<n> on every call (including zeros, so an old agent is distinguishable from a healthy one) plus a retention_guard|<table>|<n> / retention_guard_failed|<table>|<n> line for each affected table. A non-zero failures total means retention has stopped for that table - a probe or delete is erroring - and must be read together with the declines total, not instead of it. These counters are in-memory and reset on agent restart, and are not aggregated fleet-wide today; reading them is a per-device query.
• Failure mode with a retention consequence: if a retention transaction cannot be rolled back and the endpoint’s database is left mid-transaction, the agent closes the echo.db write connection rather than reporting durable writes it will lose. Echo collection and retention both stop until the agent is restarted; historical rows stay readable through the separate read-only connection (echo sql), and echo status reports error|... followed by storage_state|offline. While an endpoint is in that state its retention commitment is not being met - nothing is deleted until it restarts. There is no automatic recovery today (tracked follow-up).

Agent-side kv_store.db namespaces

kv_store.db is the agent’s general-purpose key-value store (rule definitions, sync state, plugin data); the namespaces below carry security-relevant audit or integrity data rather than device telemetry and are inventoried here on that basis.

The fleet visualization cache (FleetTopologyStore) is the highest-resolution endpoint telemetry surfaced in the dashboard. It holds at most two snapshots in memory at any time (single-flight refill, no SQLite persistence) and each snapshot is invalidated 60 seconds after the agent dispatch completes; restarting the server purges all cached topology. Process-level fields (name, user, category) are agent-controlled strings rendered after HTML escape and length clamp; the category field is computed server-side from a typed enum (process_category.hpp) so agents cannot inject arbitrary palette keys. Privacy-sensitive customers can suppress process collection on specific agents via echo.configure process_enabled=false (the corresponding cubes in the visualization render with no interior dots) or disable the whole feature with --viz-disable / YUZU_VIZ_DISABLE.

The Guardian events table is sized for ~10k events/s during a fleet-wide incident (design doc §9.1), i.e. ~864M rows/day. The 30-day default is the retention/recovery trade-off: long enough to correlate an incident across the standard forensic window, short enough to keep steady-state disk under ~25GB per million endpoints at typical drift rates. Tenants with longer forensic SLAs should raise guardian_event_retention_days and provision storage — the product does not auto-trim disk.

Agent-side, transient (no durable store)

Read results that are never written to a database on either side — computed fresh per invocation and streamed to the caller. Listed here so a data-inventory pass finds them instead of assuming an omission.

Behavioral telemetry (DEX) — PII posture and works-council / co-determination

The DEX read model (guardian_observations + the /dex dashboard) is the first surface where Yuzu telemetry is identifiably behavioral: a device’s signal history reveals which applications a person runs and when they fail. In jurisdictions with employee co-determination — Germany (§87(1)(6) BetrVG), Austria, the Netherlands (WOR), France (CSE), the Nordics — the works council’s right is triggered by a system’s capability to monitor behavior or performance, not by the operator’s intent. The controls below are therefore deliberate design decisions, documented here as the evidence base for the DPA/security addendum (workstream G) and customer privacy review:

• Minimisation at the edge (collection time, not display time). The agent’s catalogue extractors never read user content from events that carry it: DNS queried hostnames (browsing behavior), print document names and owners, profile/logon/VPN/RDP usernames, RDP client addresses, file paths under user profiles (image paths, ESENT database paths, inaccessible-file paths, boot-degradation paths), Defender detection paths and detection users, AAD error-message texts (can embed UPNs), and .NET stack frames are dropped on the device — what is never extracted can never be exfiltrated, subpoenaed, or mis-scoped. Each drop is pinned by a [privacy]-tagged unit test. Process/application names ARE collected — they are the irreducible core of a reliability signal — and are the reason the per-device view is classified PII even though no username field exists in the store.
• Per-application performance sampling (procperf) is a separate legal basis, and ships ON by default. The reliability justification above covers crash/hang/failure events. Continuous per-application CPU + working-set sampling (the $ProcPerf_* edge-warehouse tiers, 30 s cadence) is performance/usage monitoring of which applications a person runs and how heavily — not a reliability signal, and not covered by that basis. It ships on by default (procperf_enabled=true; an operator can disable it per host), image-names-only, and is the candidate collector for the per-category collection toggle (first roadmap gap below). Device-level performance ($Perf_*, no per-app identity) is a distinct, lower-sensitivity category and stays on by default. Enabling procperf for an EU workforce should be treated as a works-council co-determination trigger.
• Software install/uninstall (software): machine-scope asset-management class, no PII, on by default. Recording install/remove/upgrade events (app name, version, publisher — no command lines, no launch/usage data) is asset-management and vulnerability-relevance data, the same lower-sensitivity class as the Services and User-session sources — distinct from procperf’s continuous usage sampling. The source is machine scope only (Windows HKLM Uninstall, 64-bit + WOW6432Node): an event is the host’s installed software, never attributed to a Windows profile, so there is no user/profile-name column and no personal data. It ships on by default (software_enabled=true) and an operator can disable it per host (existing rows stay queryable on disable). The _Daily/_Monthly rollups aggregate per name. Because the source carries no per-user identity, it raises no works-council per-user concern; the response store (PostgreSQL schema response_store) still retains software query results (machine-scope app names) under the standard response retention.
• Per-connection network quality (netqual) + connectivity transitions (netconn): usage-class, on by default, with a novel retroactive-reach consideration (ADR-0020). $NetQual_Live records per-connection RTT/jitter/loss joined to the owning app (image name only; the destination is reduced to a coarse remote_bucket class — the raw address is never stored) — the same usage-class posture as $ProcPerf_*, and on Windows it needs an elevated agent (non-elevated records nothing, netqual_capture_method=none). $NetConn_Live records OS-logged network/Wi-Fi connect/disconnect and internet-capability changes as closed enum tokens + numeric reason codes only — no SSID/BSSID/profile/GUID/MAC/address. Both are device-level (no per-user column). The distinct consideration vs the forward-looking sources above: enabling netconn (and the $NetQual_Boot baseline) triggers a one-shot retrospective read that ingests OS-retained history from before Echo — or the agent — existed on the box (up to netconn_lookback_seconds, default 7 days). On a person-assigned device the timing of network/Wi-Fi transitions is a presence/working-hours proxy — behavioral personal data under GDPR even with identifiers stripped — so collecting a window that predates the monitoring notice is a distinct lawfulness/transparency (GDPR Art. 13-14) and co-determination question. Mitigations: the retroactive reach is operator-configurable and can be set to netconn_lookback_seconds=0 (forward-only, no pre-notice read) where retrospective collection is not lawful; enum-tokens-only storage. Enabling netconn for an EU/co-determination workforce should be raised with the works-council/DPO before enablement, and the retroactive window set per that agreement (ADR-0020 privacy note).
• Aggregate-by-default, individual-by-exception. The /dex headline is a fleet rollup. The per-device drill-down (the individual-identifying view) is separately permission-gated (GuaranteedState:Read) and every open is audit-logged (dex.device.view for the device history, and dex.observation.view for the per-event detail panel — which records the event’s obs_type so usage-class opens stay separately countable — both in the audit store (audit_store schema, PostgreSQL), 365-day retention) — access transparency for the individual-level read path. The individual read path has two channels with identical gating and audit: the /device dashboard DEX lens AND the machine-readable REST endpoints GET /api/v1/dex/devices/{id} (emits dex.device.view) and POST /api/v1/dex/devices/{id}/live (emits device.live.uptime / device.live.processes, result=requested, audited before dispatch). Both REST endpoints are fail-closed: a non-persistable audit row returns 503 + Sec-Audit-Failed: true and serves no PII / dispatches no probe. Both channels are in the data inventory for this read path, so a Workstream-E review of “what can trigger an individual behavioral read” must list REST, not only the dashboard.
• Guardian per-device compliance is a third behavioral-read channel (guardian.device.view). GET /api/v1/guaranteed-state/device-compliance?baseline={name}&agent_id={id} (the ServiceNow/CMDB CI-sync read) returns a named device’s per-Guard compliance verdicts — individually-identifying behavioral data — gated on per-device-scoped GuaranteedState:Read and audit-logged on every open as guardian.device.view (audit store, audit_store schema, PostgreSQL, 365-day retention), the same verb the /device dashboard Guardian lens emits (one SIEM filter covers both surfaces). Fail-closed: a non-persistable audit row returns 503 + Sec-Audit-Failed: true and serves no compliance PII (CC7.2), with 503 returned before 404 (no name-existence oracle without durable evidence). It belongs in the Workstream-E “what can trigger an individual behavioral read” inventory alongside the dex.device.view channels above.
• Device configuration-item (CI) inventory is a fourth behavioral-adjacent read channel (inventory.device.ci, and inventory.devices for the fleet-list variant). The Hardware CI list columns + per-device CI record (/hardware, /hardware/ci?id=, GET /api/v1/hardware, GET /api/v1/hardware/{id} and the MCP tools list_hardware_ci / get_hardware_ci) (serial, system UUID, primary/all MAC addresses, BIOS/CPU/RAM, OS version — device-persistent identifiers, ADR-0016) are gated on Inventory:Read and audited at the same behavioural-PII tier (emit_behavioral_audit) as dex.device.view/guardian.device.view. Unlike those two, the fleet-list variant (inventory.devices) audits a BULK read (the whole roster it renders in one event, not per-device) — see the Data Inventory row above for the full classification. It belongs in the same Workstream-E “individual behavioral read” inventory as the dex.device.view/guardian.device.view channels.
• Software-licensing per-agent drill is a fifth individual-identifying read channel (sle.agent.view). GET /api/v1/sle/agents/{id} (the SLE single-agent licence drill, ADR-0024) returns a named device’s detected licence rows — including per-user user_ref pseudonyms wherever per-user surfaces were probed — individually-identifying personal data (GDPR Recital 26). The SLE fleet-aggregate surfaces (/sle/summary, /sle/licenses) are not built in-server at all — they are the SAM use-case-engine module’s interpretation surface (ADR-0024 / ADR-1005). The one in-server per-agent drill takes the ancestor-aware per-device scoped SoftwareLicensing:Read gate from day one (403 outside scope — the device_routes precedent; it is Decision 11’s privacy-verification surface, so it gets real confinement immediately) and is audit-logged on every open as sle.agent.view at the behavioural-PII tier (emit_behavioral_audit, audit store, audit_store schema, PostgreSQL, 365-day retention). Fail-closed: a non-persistable audit row returns 503 + Sec-Audit-Failed: true and serves no licence PII (CC7.2). It belongs in the same Workstream-E “individual behavioral read” inventory as the dex.device.view / guardian.device.view / inventory.device.ci channels above.
• The machine-health audit exemption (named policy decision, F2a 2026-06-12; extended to the network surface N1 2026-06-15; extended to app-performance-over-time aggregates 2026-06-28; narrowed 2026-08-14 — see below). Aggregate fleet-performance and cohort-benchmarking reads (the /dex Performance tab’s fleet/cohort views, GET /api/v1/dex/perf/{fleet,cohorts,cohort-diff}, the matching MCP tools get_dex_perf_fleet / get_dex_perf_cohorts / get_dex_perf_cohort_diff), the application-performance-over-time aggregates (GET /api/v1/dex/perf/{apps,app,group,tag}, the MCP tools list_dex_perf_apps / get_dex_app_perf / get_dex_group_app_perf / get_dex_tag_app_perf, the /fragments/dex/perf/{apps,app} dashboard fragments, and the Apps list GET /api/v1/dex/apps / list_dex_apps), the fleet network-quality now-stats (GET /api/v1/network/fleet, the MCP tool get_network_fleet, and the /fragments/network/overview dashboard fragment), and the DEX family-catalogue rollup (GET /api/v1/dex/catalogue, the MCP tool get_dex_catalogue — WS-A4 PR-1, the same aggregate class as the already-exempted catalogue/group dashboard fragment: a fleet-wide health-score/coverage rollup by signal family, no agent_id, no per-device row) are deliberately not per-read audited: they carry no behavioral history, no event detail, no detail_json, no agent_id — only device-state / app-aggregate telemetry (CPU/commit/disk levels; per-app CPU/working-set by version; device-aggregate RTT/retransmit/throughput link health) and operator tag values, which are individually-identifying when a cohort holds a single device; the exempt reads also publish per-application and per-version crash and hang counts, distinct-device counts and last-seen times, as aggregates with no agent_id. The app-perf aggregates additionally apply a cohort floor on read (kDexCohortFloor) to both the fleet (/perf/app) and group (/perf/group) surfaces, and the cohort benchmarks (/perf/cohorts, /perf/cohort-diff) apply the same constant. Maintainer ruling 2026-10-14 (absolute): that floor is one device (previously 10). Every (version, day) point, cohort and figure with at least one contributing device is published; only an empty point or cohort is reduced to a count. The privacy consequence, stated plainly: a point or cohort covering a single device — including a named management-group, device-model or device-tag cohort of one — now publishes that device’s exact CPU/memory aggregate on these un-audited reads. The opt-in per-cohort Prometheus export (yuzu_fleet_perf_cohort_*) likewise exports a one-device cohort’s exact figures, labelled with the tag value, to whatever scrapes /metrics; that channel is bounded by the /metrics authentication setting (loopback is always unauthenticated; remote scrapes need any authenticated session, with no GuaranteedState:Read check, unless --metrics-no-auth is set) and the admin-gated export key, not by GuaranteedState:Read. What bounds it: the figures are fleet-wide aggregates by application, version or cohort value only, no agent_id is emitted (a cohort value is operator-chosen or agent-synced and may itself identify a device), every API, MCP and dashboard read stays behind the access-reviewed GuaranteedState:Read, and the audited per-device drill dex.device.app_perf.view (above) is not the only route to per-device figures. The same one-device floor governs the per-version crash and hang join on /perf/app (versions[]); the Apps list read (GET /api/v1/dex/apps, MCP list_dex_apps) is likewise a per-application and per-version aggregate, no agent_id, behind GuaranteedState:Read. This is an accepted residual under the maintainer’s ruling, recorded in the governance ledger, not a gap awaiting a fix. Narrowed 2026-08-14 (fleet-wide confinement fix): the /devices variant of both families — GET /api/v1/dex/perf/devices (MCP list_dex_perf_devices, fragment /fragments/dex/perf/devices) and GET /api/v1/network/devices (MCP list_network_devices, fragment /fragments/network/devices) — is no longer in this exemption: each row names an agent_id, which IS individually-identifying, and a pre-existing gap let a service-scoped API token read it fleet-wide under a role-only permission check that never confined the token’s own service scope. Both surfaces are now access-audited (dex.perf.device.view / network.device.view, three emitters each — REST fails closed, the dashboard fragment and the MCP tool are set-and-proceed) and deny a service-scoped token outright; see the audit-log user manual. The audited boundary is unchanged otherwise: the individual device behavioral view (dex.device.view), the machine-health device query (dex.device.perf.query), and the usage-class per-application panel (dex.device.procperf.query — whose result polls require the audited dispatch’s command_id, so no usage-class read escapes the count). Compensating control: un-audited REST reads on the remaining machine-health surfaces are covered at the web-server access-log layer (request path, principal, status, timestamp); the MCP path additionally emits the generic mcp.<tool> audit event per invocation. Accepted residual risk: a principal holding GuaranteedState:Read can enumerate fleet topology and cohort (e.g. location) membership without a per-read SIEM trail via the remaining aggregate surfaces — accepted for the machine-health class because GuaranteedState:Read is an access-reviewed role and the compensating controls above apply; this is not new (it predates N1 for DEX-perf and the /network fragments). This paragraph is the citable policy line for CC7.2 evidence reviews.
• Per-app names transit the server response store. When an operator runs the per-application panel, the device’s reply (per-application image names — usage-class) is persisted in the response store (PostgreSQL schema response_store, ADR-0039) under the standard response retention (response_retention_days, default 90 d) — i.e. longer than the 31-day on-device tier. The data-inventory row for response_store carries this annotation, and the future F3 DSAR path must include response_store as an erasure source alongside guardian_observations.detail_json.
• Device live-snapshot reads transit the server response store (extends the per-app note). The device-page Get live info cards dispatch read-only queries whose replies persist in the response store (response_store) under the same retention. Several carry usage-class behavioral PII: the process tree (device.live.process_tree — process names + parent→child graph + SHA-256 + per-process remote connection endpoints), active connections (device.live.connections), logged-in users (device.live.users), and the DNS resolver cache (device.live.dns_cache). The machine-health cards (uptime/services/adapters/ARP/listening/capture-sources) carry no individually-identifying data. The F3 DSAR/erasure path must treat all four usage-class device.live.* categories as response_store erasure sources; each dispatch is per-read audited under its own verb (works-council separately-countable).
• Stored responses of Forensics-tier plugins are a separately gated, separately counted read channel (response.forensics.read, #4990). The rows of app_usage, browser_inventory, execution_artifacts, privacy_permissions and remote_access_audit are served from the response store only to a caller holding Forensics:Read in addition to Response:Read; to any other caller they are absent from the query, export, aggregate and MCP response routes, with no marker (an empty result does not prove no data exists; the one surface that does say so is the Hardware Actions-lens result poll, which shows a notice that the reply needs Forensics:Read instead of reporting a timeout), and a read that cannot tell whether the caller may see them gets a retryable error rather than a partial answer (yuzu_server_forensics_tier_withheld_total, alert YuzuForensicsTierUnresolved; this covers sessions, API tokens, MCP tokens and engine principals, and an unavailable global Forensics:Read check never collapses into a definitive denial; a service-scoped token is default-denied instead, and a whole-store outage that fails the surface’s earlier admission gate first is answered by that gate and not counted here; there is no management-group scoped read tier on the stored-response surfaces, only a global grant admits Forensics rows there, while the per-device application-usage read keeps its own scoped gate). A row-returning read that serves at least one such row writes one response.forensics.read row (forensics_rows=<n> plugins=<names> surface=<s>; REST fails closed, MCP and the dashboard set-and-proceed) so those reads stay separately countable for works-council purposes, like the device.live.* verbs. The count is of read requests, not viewings or rows (an open executions drawer on a running execution writes a row per refresh; an export’s count is taken before the byte cap trims the file). Not counted: aggregate, facet-option and count reads write no row, and the dashboard filter bar (GET /fragments/results/filter-bar) serves facet option values, which can list column values of Forensics-tier rows, to a Forensics:Read holder unaudited, and the dashboard create-group-from-results action derives group membership from the matching agents of those rows and writes group.create_from_results but no response.forensics.read row (a documented gap in audit coverage); an interactive cookie session that lacks the grant leaves no denial row, so its attempts are not visible. Forensics:Read is held by default by Administrator and the read-only ForensicsAnalyst role. Bundle collation (REST GET /api/v1/bundles/{id}, MCP get_bundle_result) writes the same row with surface=bundle when it serves a Forensics-tier step’s output, next to its existing bundle.collate row. A caller authenticating with an API token, an MCP token or an engine principal that lacks a global Forensics:Read also leaves one auth.permission_required denied row per read attempt; an interactive browser sign-in does not. The failure text of a Forensics-tier command is reduced to a bounded token before it reaches the execution record, the event outbox and stream, the failure notification, the analytics event and the webhook and offload payload. The plugin that decides the tier is the one the server recorded when it dispatched the command (command_execution.plugin, one row per dispatch), never the command id an agent echoes; a response with no server record is stored ~unverified, which is part of the Forensics set (yuzu_server_response_provenance_total{outcome}). The record proves the server issued that id for that plugin, not who sent the frame: an endpoint that was sent a command can replay its id on a frame of its own, and frame content is not validated. Deployment contract (hard cutover; a scope decision of the project owner, 2026-10-24, not an acceptance of any residual risk): this release supports initial deployment into a fresh database only, with no data imported from earlier builds, every server writer and serving replica on the new build and earlier binaries excluded; recovery is rolling forward, or restoring this build’s own backups into a fresh deployment, and a database or backup written by an earlier build is unsupported; the executable does not enforce this, so provisioning and exclusion are deployment responsibilities, and data written by earlier builds is outside the supported population. Stated gap: a separate follow-up (#6065) tracks the dispatch-side authorization of policy checks, and until it lands the check instruction of a Forensics-tier policy is still dispatched to endpoints and its response row stored (readable only through the tier), with only the verdict and check_result withheld. What ForensicsAnalyst reaches: Response:Read is fleet-wide for every plugin’s stored responses (including the usage-class device.live.* results) and Inventory:Read reaches the device configuration-item inventory (serial, UUID, MAC) fleet-wide; Viewer already holds both, so assign the role as a high-sensitivity read. Risk-register entries: the deployment contract above is a procedural control, not an enforced one (nothing in the executable verifies the provenance of the database or excludes an earlier binary); the provenance replay and unverified-record limits above; monitoring of the dispatch record, where a sustained write failure, a record lookup that fails twice and a reap running at its cap for a day are alerted (YuzuDispatchRecordWriteFailing, YuzuResponseProvenanceLookupDegraded, YuzuExecCorrelationReapSaturated), while the unrecorded outcome has no alert by design (it is non-zero on a healthy fleet) and no per-principal or per-address limit on dispatch inflow exists yet (a separate follow-up tracks it); the uncounted aggregate, facet and filter-bar reads and uncounted filtered attempts above; the dispatch-side gap above; and response_store outside the decommission cascade (#1666). A user holding only ForensicsAnalyst cannot dispatch (the dispatch routes refuse for want of Execution:Execute; on the MCP execute_instruction tool at the supervised tier the approval step runs before the tool’s own permission check, an ordering that already applied to any caller lacking that permission). The tier is per plugin, not per kind of data: other plugins return comparable information under their own securables. No evidence artifact beyond the audit rows and the metric exists for this control yet.
• Operator tag values are a data category (classification: operator/API- or agent-sourced, variable sensitivity; an operator/API value overrides an agent-synced one, and a value is bounded to 448 bytes). Tags drive scoping AND, since F2a, the opt-in per-cohort Prometheus export, where the chosen key’s values become metric labels scraped by external monitoring stacks. Risk-register entry: tag values of variable sensitivity may flow to third-party monitoring if cohort export is enabled (mitigations: opt-in + admin-gated + audited key changes + the top-50 cardinality cap + documented key-selection guidance in metrics.md/the Settings panel; the cohort floor is one device, so a cohort of one device is exported with that device’s exact figures, and the cap limits how many cohorts export, not how small they are).
• Lockstep retention. Projection rows inherit the parent event’s TTL and are reaped in the same cleanup pass (single operator knob, guardian_event_retention_days); 30-day default.
• Deploy-time opt-out. --dex-disable / YUZU_AGENT_DEX_DISABLE prevents the observer from ever arming — no DEX signal telemetry is collected on that endpoint, and the heartbeat tags are omitted so fleet rollups reflect genuine state.
• Named roadmap gaps (required before EU-works-council deployments; tracked, not yet built): per-category collection toggles (fleet-wide and per-management-group), a kill switch for the individual-identifying drill-down, a pseudonymization mode (device IDs not resolvable to a person except by a narrow role), operator-set per-store retention exposed in the dashboard rather than via constructor argument, a dedicated DEX:Read securable (today the per-device behavioral view is gated on GuaranteedState:Read, which also covers Guardian config reads — separating them lets a least-privilege access review grant DEX behavioral access as its own decision; the audit log per individual open is the compensating control until then), and a targeted per-subject deletion (DSAR) path (bulk TTL alone does not satisfy a subject-access erasure request in GDPR-adjacent jurisdictions; detail_json on the source events would support a future backfill/erase script).

3.6 Workstream F — Secure SDLC and Change Management

Target State

• Every production change is traceable, reviewed, tested, and auditable.

Required Features / Controls

• Branch protection and mandatory code review.
• Required CI checks (build/test/security scans) before merge.
• Change ticket linkage for release-impacting modifications.
• Release checklist with rollback strategy and approvals.
• Segregation between development, staging, and production environments.

Evidence

• PR review records, CI logs, deployment approvals, and release notes/change tickets.

Addendum — the gateway Common Test CI check reported success while executing nothing, 2026-05-13 to #4800 (CC8.1/CC7.2). Recorded here because this section cites “Required CI checks … before merge” and “CI logs” as change-management evidence, and one of those checks did not operate for that period. When the gateway’s Common Test suites moved into gateway/apps/yuzu_gw/test/ct/ (335670056, 2026-05-13), the Meson gateway ct test kept invoking rebar3 ct without that directory, so it discovered zero suites, printed All 0 tests passed. and passed on every CI leg that ran it. CI logs from that window show gateway ct … OK with no Common Test case executed, so they are not evidence that the gateway’s integration, end-to-end, metrics or performance suites passed. Two real defects shipped behind it on dev (#4707, the gateway /metrics endpoint returning HTTP 500, and #4708, a stale test). #4707 reached tagged releases: it was in 0.14.0-rc1 through rc3 and was fixed by the hotfix #5177/#5199. #4708 is a test-only defect. The gateway’s EUnit check was unaffected and did run.

#4800 closes it: the check now runs the suites on the Linux, Windows and macOS legs (52 Common Test cases were measured on Linux and on Windows on 2026-09-23; the macOS count was not measured), and the wrapper fails any run that exits 0 without executing a test. /test’s EUnit gate and the release workflow’s EUnit step were brought under the same rule. A hermetic self-test (tests/test_gateway_test_summary.py) pins the directory and the rule. The same change closes a second, older gap (#4841): the macOS CI leg never had Erlang, so Meson silently skipped the gateway there and the leg passed without building or testing it. The macOS leg now installs Erlang/OTP 28, and every CI leg that runs meson test (ci.yml, nightly, sanitizer-tests, fork-dynamic-review.yml) checks, right after configure, that the gateway tests were registered (scripts/ci/assert-gateway-tests.py), so a runner missing the gateway toolchain fails instead of passing without the gateway.

3.7 Workstream G — Customer Assurance Package (Enterprise Sales Enablement)

Deliverables

• Security whitepaper and architecture overview.
• Standard CAIQ-style questionnaire responses.
• Pen-test executive summary and remediation statement.
• DPA/security addendum templates.
• Shared responsibility matrix (vendor vs customer responsibilities).
• Forward pointer: the MCP surface gains a session concept (in-memory only, principal-bound ≥128-bit ids, TTL/caps, revocation cuts live streams) via ADR-1005 execution-plan Decision 15 / track 2f — fold its security pre-commitments into the questionnaire/whitepaper once 2f ships.
• Forward pointer: track 2g (ADR-1005 Decision 16, docs/agentic-first-principle.md A5) delivers a near-fully self-describing MCP tool/resource surface — typed schemas, truthful safety annotations, a handshake orientation blob, and OpenAPI/scope-DSL specs discoverable via resources/list rather than tool-by-tool, with one narrow tracked residual (streamed-final fallback envelope, #2990 — retry_after_ms closed 2026-08 by #3344). Cite this in the security whitepaper / CAIQ responses as evidence of a machine-verifiable, not merely documented, agentic contract — a differentiator against peers whose AI integrations (if any) are undocumented or prose-only; disclose the residuals rather than overclaiming completeness to a technical reviewer.
• Forward pointer: the plugin README standard (docs/plugin-readme-standard.md) makes each agent plugin self-describing as data — its per-OS mechanism, the privilege it runs at with a measured date, its securable/operation/risk tier, output columns and where the rows land — served at GET /api/v1/discover/plugin-docs and the yuzu://plugin-docs resource. Cite it as the per-plugin answer to “what does the agent collect, at what privilege” (the Sensitivity is plugin-dependent rows above point here for the plugins that have adopted it); state the coverage honestly — two pilots today, the remaining plugins in the retrospective sweep, held by a README-existence ratchet in the docs test suite.
• Known-limitations disclosure (#3481, gov Gate 6 enterprise-readiness, 2026-08-24): two tracked, filed, non-blocking ProductPackStore residuals worth surfacing in a technical security/reliability review rather than presenting only as public GH issues — #3523 (two concurrent installs of an identical product-pack bundle can cross-couple a Policy to an unrelated pack’s Fragment; no attacker required, an automation/GitOps race is sufficient) and #3524 (a large duplicate-item-id bundle drives an unbounded, synchronous compensation pass over sibling-store locks — a ProductPack:Write-privileged-caller resource-exhaustion question a CAIQ-style review would reasonably ask). Both are data-integrity/availability class, not credential/RCE; neither derived BLOCKING under this repo’s severity schema.
• Known-limitations disclosure (#4966): the last-Administrator guard is a recovery rule, not proof of sign-in and not an HA claim; SSO-only administrators are not counted until #5182, direct SQL is outside it, a rolling upgrade or rollback drops it, and the SCIM Group role recompute has documented limits with no shipped alert rules (tracked in #5673). State these alongside the control in the questionnaire/whitepaper rather than presenting the guard as absolute.
• Known-limitations disclosure (#5692): state these alongside the OIDC SSO control in a questionnaire.
  • Signing keys are fetched afresh for every sign-in and not cached, so a key the IdP has retired or revoked stops verifying at the next sign-in (#1901 UP-19); the cost is one JWKS request per sign-in and no sign-in while the JWKS endpoint is down; an IdP that rate-limits jwks_uri (429/5xx) fails that sign-in with no retry, and under --auth-mode=sso-only an outage locks out every operator without an armed break-glass account. A token naming a kid the key set lacks is refused; a token with no kid is checked against each usable signing key in turn (at most the first 16, in the order published). An RSA signing key whose modulus is under 2048 bits, or whose public exponent is below 3, even or over 32 bits, is skipped when the key set is parsed, so such a key cannot verify a token and an IdP that signs with one cannot sign anyone in; under --auth-mode=sso-only that locks out every operator without an armed break-glass account, and the skip is recorded in the server log only (no metric, no audit row; the failed sign-in itself is the generic auth.oidc_login_failed row). These checks are defence in depth against an IdP publishing a weak or degenerate key; they do not defend a tampered or hostile JWKS, whose publisher can serve a key of their own that passes them, and no setting lowers them. JWKS fetches are not single-flight (a burst makes N parallel fetches; #1900, #5983).
  • A discovery failure at /auth/oidc/start is logged only: no audit row and no counter (#5704). A callback’s discovery or JWKS failure shares the generic failure row and counter.
  • Discovery and JWKS requests have a total bound of 2 x the per-operation timeout (10 s by default), including the TLS handshake. The token-exchange POST has per-operation timeouts only (Windows: WinHTTP defaults) and no total bound. A SIGTERM during a stalled token POST ends in a 15 s wait and a forced exit.
  • A Settings save does not wait for sign-ins: they take the OIDC lock only to pick up the current provider and copy their settings. A sign-in whose exchange finishes after a save replaced the provider is refused (audit auth.oidc_login_failed, reason provider_replaced) before any group, role or session work, and the callback checks again right after the session is minted, deleting that session if a save replaced the provider in between (audit reason=provider_replaced;post_mint=true), so no usable session is created under the replaced admin group or issuer once the save has returned; a save that lands after the second check is ordered after that sign-in. A session that is already live is not revoked by a save (revoke it with DELETE /api/v1/sessions?username=oidc:<iss>#<sub> or Settings > User Management > Revoke sessions; a restart does not end sessions). Any save rebuilds the provider, so every sign-in in flight, and every flow started before the save, must start again; the new provider takes effect in the process that handled the save, and another replica picks up the stored settings at its next restart. A replaced provider that still had a request is destroyed at the next Settings save or at server stop; beyond 16 such providers (token POSTs have no total bound, #5983; the database work after the exchange is bounded by the statement and pool timeouts) a save’s reply waits for the oldest. A sign-in holds one HTTP worker for up to about 10 s on the shared pool while its JWKS request runs.
  • The egress policy decodes every RFC 6052 NAT64 layout for prefixes it learns from RFC 7050 (ipv4only.arpa, re-queried after 10 minutes; learned prefixes are only added, never forgotten, at most 64, and an answer past that refuses the fetch) or from --oidc-nat64-prefix (trusted to describe a translator), and classifies such an address by the IPv4 address embedded in it. Teredo, IPv6 benchmarking and the other non-global parts of 2001::/23 are refused unless the private-network switch is set (the registry’s globally reachable sub-ranges excepted). On Windows a name lookup the resolver does not finish even after cancellation is held in a bounded ledger (16) and freed on completion, and further lookups fail closed while it is full. What remains is translators the server cannot see (a prefix neither discoverable nor configured, a proxy, a VPN, CLAT/464XLAT outside the host); an address such a path maps to a private or link-local destination can classify as public. TLS verification still uses the host name, so over https such a path is limited to a blind TCP connect, and plain http to a public-looking address is refused by the cleartext rule.
  • No HTTP proxy on the discovery and JWKS path. An https OIDC sign-in on a Windows server is unverified. There is no operator override of the discovered endpoints, so an IdP that does not serve its discovery document cannot sign in.
  • In the callback handler, the OIDC login denied and group-provisioning log lines print the principal as received, the provisioning-failure log line prints the raw database error text, and the provisioning-failure audit detail carries that text in reason=; the audit detail sanitizer neutralizes control characters, ; and = but not NEL, U+2028 or U+2029; and the SAML sign-in log lines print the principal, display name and e-mail as received (tracked in #5704).
• Forward pointer: Reflex (agent-local Spark-bound automated response, docs/reflex-design.md, ADR-0021, docs/roadmap.md Phase 20) is design-only as of 2026-09-17 — zero code. Once built it is a CC6/CC8-relevant control (digest-bound two-person deploy approval on any dangerous Reaction) and a CC7.2 evidence source (the reflex_outcomes journal, subject to its own stated evidentiary retention floor). Cite it in the whitepaper/questionnaire only once shipped; this bullet exists so the design-stage capability is not silently absent from Workstream G’s forward-looking inventory.
• Forward pointer: enrollment tokens and the pending-agent queue are now durable across restarts and shared fleet-wide via a single Postgres-authoritative store, with atomic race-safe token consumption (HA WS-6 6.2, ADR-2002) — for whoever eventually writes the customer-facing whitepaper/CAIQ, this closes a previously implicit per-replica-state gap in the availability/consistency story for agent enrollment.

First-Customer Readiness Milestones

1. Technical due-diligence packet ready.
2. Security review Q&A runbook and owners assigned.
3. Pilot onboarding playbook (networking, certs, SSO, agent rollout).
4. Executive escalation path and customer success governance cadence.

4) SOC 2 Type II Control Implementation Backlog

4.1 Priority 0 (0–30 days)

• Finalize SOC 2 scope, system boundaries, and control owners.
• Ratify core policies and approval workflows.
• Establish evidence repository structure and naming conventions.
• Enforce mandatory review + CI gates on all production-bound code.
• Define incident severity model and notification SLAs.

4.2 Priority 1 (31–90 days)

• Implement MFA/step-up auth for privileged approvals.
• Complete security headers and hardened deployment baseline.
• Integrate vulnerability scanning with remediation SLA tracking.
• Run first tabletop incident response exercise.
• Execute first documented backup restore drill.

4.3 Priority 2 (91–180 days)

• Run operational metrics program against formal SLOs.
• Complete external penetration test and close critical findings.
• Validate high-scale customer deployment architecture.
• Launch customer trust center artifacts and standard security packet.

4.4 Priority 3 (Audit window)

• Freeze control design changes (unless risk-critical).
• Monitor control performance and evidence completeness weekly.
• Perform internal pre-audit and remediation sprint.
• Complete audit period and respond to auditor requests quickly.

5) First Enterprise Customer Plan (Go-to-Production)

5.1 Pre-Sales to Contract

• Complete security questionnaire and architecture deep dive.
• Confirm mandatory integrations (IdP, SIEM, ticketing, endpoint rollout tooling).
• Agree shared security responsibility and data-handling terms.
• Define commercial and operational SLAs.

5.2 Pilot Phase

• Deploy to non-production tenant/environment.
• Validate SSO, RBAC, logging, and approval flows end-to-end.
• Run controlled command/compliance/policy workflows at target scale subset.
• Joint success criteria with customer IT/SecOps leads.

5.3 Production Rollout

• Phased rollout with rollback checkpoints.
• Daily health reviews during initial launch window.
• Weekly governance meeting (engineering + security + customer success).
• 30/60/90-day value and risk review.

6) Metrics and Readiness Scorecard

6.1 Control Health KPIs

• % controls implemented vs planned.
• % controls with automated evidence.
• % evidence artifacts generated on schedule.

• open high/critical audit readiness gaps.

6.2 Security and Reliability KPIs

• Mean time to remediate critical vulnerabilities.
• MFA adoption coverage for privileged users.
• Incident MTTR and recurrence rate.
• SLO attainment (%).

6.3 Enterprise Customer KPIs

• Security review turnaround time.
• Time to pilot completion.
• Time to production acceptance.

• post-launch escalations in first 90 days.

7) RACI (Condensed)

• Security Lead: Control design, risk register, audit coordination.
• Engineering Lead: Feature/control implementation, SDLC controls, reliability.
• DevOps/SRE: Infrastructure hardening, observability, DR drills, on-call.
• Product: Prioritization and customer requirement alignment.
• Customer Success / Sales Engineering: Enterprise onboarding execution and stakeholder management.
• Legal/Finance: Contractual security terms and compliance vendor management.

8) Immediate Next 10 Actions

1. Nominate control owners and publish SOC 2 scope memo.
2. Open an “Enterprise Readiness” epic with workstream sub-epics.
3. Baseline current control coverage against SOC 2 criteria.
4. Define production-hardening profile and default secure configuration.
5. Implement privileged-action MFA requirement.
6. Stand up evidence automation jobs (access reviews, CI outputs, backups, vulnerability reports).
7. Author incident response and customer notification playbooks.
8. Schedule first tabletop + restore drill.
9. Prepare standard security questionnaire responses and architecture packet.
10. Select target design-partner customer and execute a controlled pilot plan.

9) Appendix — Suggested Artifacts to Maintain

• SOC 2 control matrix and evidence index.
• Network/data-flow diagrams and trust boundaries.
• Secure configuration baseline (server/agent/gateway).
• Incident response runbook + communications templates.
• Backup/restore runbook and drill history.
• Access review records and privileged access logs.
• Change management and release approval records.
• Vulnerability management reports and remediation logs.