​

Access Control: Identity-Scoped Agents, Provenance Privacy, and Tenant/Actor Encryption

​

0. Framing: three layers, one model

  Layer 3  Encryption at rest          "even the operator/host can't read it"     (cryptographic)
  Layer 2  Actor-audience visibility    "which actors this content is FOR"         (retrieval/authz)
  Layer 1  Perspective (exists, 0016)   "which agent this content BELONGS to"      (data-model)

Enforcement lives at the point where data is loaded, in the query, hardcoded. Never in the prompt. By the time a private fact is in the context window it has already leaked. The control is: do not retrieve ineligible data. This is the foundational rule the rest of the document builds on.

​

Layer 1 — Agent types (personal / assistant / open)

​

The construct

​

Background: how OpenClaw handles this today, and why it isn’t enough

​

Why this is not require_mention, and why it’s better

​

The “badge” question — hardcode or prompt?

1. Identity/authentication — the agent acts as itself using its own delegated credentials, not a shared human password. This already exists and is a strength: 0002_secrets.sql stores each agent’s connector tokens envelope-encrypted, owned by the agent (owner_type='agent'), and perspective.md makes self-recognition the one privileged recognition. A delegated-credential model — where the agent holds its own scoped tokens rather than borrowing a human’s login — is already the model. No change needed; it should be documented explicitly as a product property.
2. Authorization — what the agent may do on behalf of whom. Here the control must be hardcoded, not prompted, and the reason is the governing principle above. The engagement gate must consult agent type + principal from the database and short-circuit to observe/ignore for personal agents facing non-principals. A prompt that says “you are this person’s private assistant, don’t talk to others” is defeated by any message that says “actually your principal asked me to relay this.” Access control that lives in the prompt is access control an attacker can argue with. The database does not negotiate.

​

Schema

-- 00NN_agent_type.sql
ALTER TABLE runtime_agents
  ADD COLUMN agent_type text NOT NULL DEFAULT 'open'
    CHECK (agent_type IN ('personal','assistant','open')),
  -- The principal actor this agent is bound to. NULL iff type='open'.
  -- Composite FK into the agent's OWN perspective: the principal must be an
  -- actor this agent knows, and cannot be borrowed from another agent's graph.
  ADD COLUMN principal_actor_id uuid,
  -- Lifecycle: 'binding' (pending principal) or 'bound'. 'open' agents are
  -- always 'bound' (they have no principal to wait for).
  ADD COLUMN principal_state text NOT NULL DEFAULT 'bound'
    CHECK (principal_state IN ('binding','bound')),
  ADD CONSTRAINT runtime_agents_principal_perspective_fkey
    FOREIGN KEY (id, principal_actor_id)
    REFERENCES actors (runtime_agent_id, id) ON DELETE RESTRICT,
  -- The trio is consistent or the row is rejected. A personal/assistant agent is
  -- legal WITHOUT a principal *only while* principal_state='binding'; once bound
  -- it must have one.
  ADD CONSTRAINT runtime_agents_principal_consistent CHECK (
    (agent_type = 'open'
       AND principal_actor_id IS NULL AND principal_state = 'bound') OR
    (agent_type <> 'open' AND principal_state = 'binding'
       AND principal_actor_id IS NULL) OR
    (agent_type <> 'open' AND principal_state = 'bound'
       AND principal_actor_id IS NOT NULL)
  );

UPDATE runtime_agents
   SET principal_actor_id = $1
 WHERE id = $agent AND principal_actor_id IS NULL
RETURNING id;   -- zero rows => already bound => reject (no bound -> bound' ever)

​

1.1 Verifying a human across channels (identity linking meets agent type)

• personal — verification is a precondition to engage at all. Before the link is established, a new-channel claimant is a stranger, and a personal agent observes strangers (Tier-(-1) below). Only after the code echo folds the new identity into the principal’s actor does the agent engage that channel as the principal.
• assistant — verification decides which tier the counterpart gets. An unverified new-channel claimant is engaged as an ordinary (non-privileged) actor; a verified principal gets the privileged/confidential tier. The agent bounds what it will do based on which of those the challenge proves.
• open — typically doesn’t care; ordinary multiplayer engagement, no privileged principal to protect. Verification is only relevant if some capability is gated on a specific actor.

Prior art — the Signal Protocol’s session and authentication model. Two pieces of Signal’s design (signal.org/docs) map cleanly onto this problem and are worth borrowing at the design level — not the wire protocol, since Signal is a server-as-adversary end-to-end system and Mesh deliberately is not (the runtime must read plaintext to reason; see §3.2). Sesame (spec) manages encryption sessions in an asynchronous, multi-device setting: one identity fans out to many devices, each with its own live session, and the algorithm specifies exactly how a new device appearing mid-conversation is admitted. That identity → devices → sessions tree is structurally the same shape as Mesh’s actor → connector-identities → live-sessions, and its new-device admission path is precisely the “principal appears on a new channel” case above — a ready-made template for how the ConnectorIdentity edge and the Layer-3 DEK re-wrap should behave when a channel joins mid-stream. X3DH (spec) contributes the stronger authentication principle: authentication is the result of a key agreement, never a claim a party asserts. The code-echo challenge today proves human liveness on both ends but ultimately matches a string; a hardened variant has the two live sessions complete a short authenticated key agreement, producing a cryptographic binding — a signed, replay-resistant attestation rather than a shared secret typed across a gap. That pushes the governing principle one layer down: a matched string is access control an attacker can replay; a completed key agreement is not. Tracked as a hardening follow-up, not a v1 blocker for the string-based echo. (Signal’s VXEdDSA VRF, spec, is noted as future-only prior art for unlinkable-but-verifiable actor identifiers across channels, should the actor graph ever need selective disclosure — out of scope here.)

​

Engagement-gate change (Tier 0, deterministic, no inference)

Tier -1 (type gate, cheapest, most certain):
  agent.type == 'personal' AND author != agent.principal   -> observe (never engage)
  agent.type == 'personal' AND agent unbound               -> observe
  (assistant and open fall through to the existing ladder unchanged)

​

Layer 2 — Provenance-based conversation & memory privacy

​

2.1 The two things being protected

• Conversation contents. In the Mesh dashboard, message bodies of a private conversation should be readable only by an operator acting for an actor who was a participant. Everyone (with operator access) may see that the conversation exists and its shape/metadata — never the text. (This is a Layer-2 authz rule on the operator API; the bytes may additionally be Layer-3 encrypted.)
• Memory. A memory’s eligibility for a turn is gated by where it was learned and for whom, independent of semantic relevance.

​

2.2 Provenance is already modeled — extend the visibility axis

visibility band (hard eligibility):
  public        — independently verified as shareable with anyone
  workspace     — shareable within the same authenticated workspace namespace,
                  including private subsets, excluding external destinations
  confidential  — shareable only when every destination reader belongs to the
                  source's complete permitted audience
  unknown       — audience evidence is insufficient; withhold runtime reuse

Audience excludes the agent itself. audience_actors is the set of human/external actors a memory is for, never the agent’s own self-actor. addressing.md counts the agent as a participant of a direct conversation, so if the agent were in the audience set the subset test would be computed over {human, agent} on both sides and the worked example below (audience one human) would be internally inconsistent. audience(T) and audience(M) are both computed over non-self actors. A 1:1 DM’s audience is the single human counterpart.

​

2.3 The eligibility rule (bidirectional — this is the whole game)

A memory learned in a DM must not be eligible in a public channel (leak outward), AND a memory planted in a hostile channel must not be eligible in the CEO’s DM (injection inward).

A memory M is eligible for the current turn T iff:
  1. M.runtime_agent_id = T.agent          (Layer 1, exists)
  2. M is live + current revision           (exists)
  3. band gate (exactly one branch applies):
       band ∈ {public, workspace}  -> eligible (no audience rows; see note)
       band = 'confidential'       -> audience(T) ⊆ M.audience_actors

where audience(T) = the set of actors participating in T's conversation.

The gate is band-first, one test per band. For a confidential memory audience(M) is M.audience_actors, so audience(T) ⊆ audience(M) and “every actor in audience(T) ∈ M.audience_actors” would be the identical test written twice — a drift hazard if one is implemented and the other isn’t. And a literal audience(T) ⊆ ∅ would reject every turn for public/workspace memories (which have no audience rows). The subset test therefore applies only to the confidential band; public/workspace skip it.

​

2.3a Injection-inward is a SEPARATE control from the audience gate

1. Trust is not a function of openness. public means “safe to re-emit widely,” not “safe to act on as instruction.” Public-origin content is eligible as retrieved context but is never elevated to instruction/steering. This is the prompt-injection boundary and it is enforced at assembly: channel-origin memories enter the context in a clearly-fenced, lower-trust region, never the system/authority region. (Ties to the existing turn-pipeline trust tiers.)
2. A private turn may down-scope public eligibility. For high-sensitivity turns (e.g. a personal/assistant agent’s principal-only DM), the retrieval profile may exclude channel-origin memories authored by actors who are not participants of the current turn — so a stranger’s channel post cannot ride into the principal’s private context at all. This is a per-turn policy knob, defaulted on for principal DMs.

The regression net must assert BOTH directions. Plant a memory in a hostile channel, assert it is not eligible as instruction in a principal DM and not retrieved when the down-scope knob is on — in addition to the leak-outward assertion.

-- Per-memory audience for confidential entries. Absent rows = not audience-scoped
-- (public/workspace bands). Present rows = the closed set of actors who may
-- receive this memory.
CREATE TABLE memory_entry_audience (
  memory_entry_id  uuid NOT NULL,
  actor_id         uuid NOT NULL,
  runtime_agent_id uuid NOT NULL,
  PRIMARY KEY (memory_entry_id, actor_id),
  -- Composite FK #1: the (memory, owner) pair must match the parent memory's
  -- OWN agent, so a row cannot scope memory-of-agent-A to agent-B's perspective.
  -- (memory_entries must expose a UNIQUE (id, agent_id).)
  FOREIGN KEY (memory_entry_id, runtime_agent_id)
    REFERENCES memory_entries (id, agent_id) ON DELETE CASCADE,
  -- Composite FK #2: audience actors live in the same perspective as the memory.
  FOREIGN KEY (runtime_agent_id, actor_id)
    REFERENCES actors (runtime_agent_id, id) ON DELETE RESTRICT
);

Revision-versioning. Because memory_entries revisions are immutable and a revision can change band/audience, the audience must be keyed to the revision, not just memory_entry_id — otherwise restoring an old revision retrieves it under a newer revision’s audience. v1 resolution: audience rows key on the memory-entry revision id (or an immutable per-revision snapshot), and retrieval joins the current revision.

​

2.4 Source is derived, never asserted (already true — keep it)

​

2.5 Conversation-content visibility on the operator API

• Metadata vs. body split on the read API. GET …/conversations/{id} returns shape, participants, timestamps, engagement verdicts — the technical/operational view — to any authorized operator of that agent. Message bodies of a confidential-shape conversation require the requesting operator to be linked to a participant actor (Layer 2) and the key to decrypt (Layer 3, if enabled).
• This is roadmap R16 / Track D6 (role column owner/agent_operator, per-agent scoping middleware). This model adds the actor-linkage dimension: operator ⇄ actor identity mapping, so “may this human read this DM” is answerable.

​

2.6 What a personal agent persists

​

Layer 3 — Encryption at rest (tenant CMEK and actor-held E2E)

​

3.1 What already exists to build on

​

3.2 The core tension, named before proposing anything

• Org-held key (CMEK): the tenant org controls a KMS key; Mesh encrypts all tenant data under data keys wrapped by it. Threat model: “the hosting provider’s DB dump / a stolen backup / a curious Mesh operator must not yield plaintext.” Mesh-at-runtime can decrypt (it calls the org’s KMS to unwrap), so the agent, dashboard, and memory all work normally. This is standard, sellable, and compatible with everything in Layers 1–2. This is the one to build first.
• Actor-held key (true E2E): only the actor holds the key; Mesh genuinely cannot decrypt. Threat model: “even Mesh-at-runtime must not read my DMs.” The problem: if Mesh can’t decrypt, the agent can’t read the message either. An LLM cannot reason over ciphertext. So “the agent responds to your DM” and “Mesh can never see the plaintext” are in direct tension. Pure E2E kills the dashboard, server-side memory retrieval, and the agent’s ability to function.

​

3.3 The resolution: per-conversation data keys, released to the runtime only at turn time

• Each private conversation has a data encryption key (DEK), random, per conversation. Bodies + confidential memories for that conversation are encrypted under the DEK (AES-256-GCM, the existing primitive).
• The DEK is wrapped (envelope) once per key-holder:
  • wrapped under the org KMS key (CMEK path) — always, if tenant CMEK is on;
  • wrapped under each participant actor’s key (actor path) — if actor-held is on.
• At turn time, the runtime unwraps the DEK transiently in memory using whichever key it can access, decrypts what it needs for that turn, and never persists the plaintext or the unwrapped DEK. The plaintext lives only for the duration of the turn, in process memory, the same way the master key already does.

You store the ciphertext once (one DEK per conversation). You store the wrapped key N times — once per actor, once per org. You do NOT store the message N times.

The Layer-2 audience set and the Layer-3 wrapped-DEK set are NOT globally identical. memory_entry_audience (Layer 2, per-memory, frozen at write) and the wrapped-DEK set (Layer 3, per-conversation, mutable as membership changes) diverge the instant membership changes — a per-conversation DEK wrapped to a late-joiner would let them decrypt bodies and memories written before they joined, which Layer 2 denies. Crypto would grant what authz forbids. §3.3a resolves this with per-audience-epoch DEKs. The two sets are aligned by construction only within an epoch, not globally.

​

3.3a DEK epochs — the fix for late-joiners and revocation

• The conversation has a current DEK. On any membership change (join, leave, actor removal) the DEK is rotated: a new epoch begins with a fresh DEK, and content from the new epoch onward is encrypted under it.
• A DEK is wrapped only to the actors who were members during its epoch. A late-joiner is wrapped the current epoch’s DEK, never prior epochs’ — so they cannot decrypt history from before they joined. A departed member’s wrapped copies of prior epochs are destroyed, and they are never wrapped the new epoch — so “remove the wrapped DEK = revoke” becomes true going forward.
• Honest limit: rotation revokes access to future ciphertext, not data already unwrapped/exfiltrated before revocation. This is standard crypto reality (you cannot un-see plaintext someone already read); the datasheet says so rather than implying deletion is retroactive secrecy.

Prior art — the Double Ratchet’s two properties, without the Double Ratchet. The per-audience-epoch DEK is deliberately the coarse-grained analogue of the forward-secrecy and post-compromise-security guarantees Signal’s Double Ratchet (spec) provides per message. Signal derives a fresh key for every message so that a key compromise exposes neither earlier traffic (forward secrecy) nor later traffic once the ratchet steps past it (post-compromise “self-healing”). Mesh does not need per-message ratcheting — the runtime holds a conversation’s plaintext for the whole turn anyway, so per-message keys would buy nothing against our actual threat model — but it does want the lesson: rotate on the events that matter (here, membership epochs rather than every message), keep the payload count per key bounded, and make revocation a key-lifecycle operation rather than a delete flag. The epoch boundary is our ratchet step; the HKDF per-record subkeys below are the intra-epoch equivalent of deriving distinct keys so no single key covers unbounded traffic. Framed this way, §3.3a is the ratchet’s intent mapped onto a server-side, plaintext-reading system, not a naive attempt to run the messaging ratchet where it doesn’t fit.

​

3.4 The actor key: verification + custody

1. Actor triggers key enrollment; Mesh sends a magic link over the already-trusted connector (e.g. a Slack DM to that actor’s verified connector identity). This proves control of the connector identity — the same identity the perspective graph already trusts.
2. On click, the actor’s browser generates the key client-side. Recommended: a BIP39 24-word mnemonic (24 words = 256 bits, built-in checksum, mature tooling). The mnemonic derives the actor key; Mesh stores only the public half / a wrapping pubkey, never the mnemonic or private key.

   Supply-chain caveat: if the keygen JavaScript is served by Mesh, the actor-held-vs-org distinction is only as strong as our web supply chain — a malicious/XSS’d bundle could exfiltrate the mnemonic at generation time, defeating the “even Mesh can’t read it” claim. Actor-held is therefore not marketed as protection against a compromised Mesh; it protects against org-admin over-reach and DB/backup theft. Harden with strict CSP, SRI-pinned bundles, crypto.getRandomValues entropy (not Math.random), and — for the paranoid tenant — a reproducible-build / standalone keygen so the browser need not trust a freshly-served script. Entropy source and bundle integrity are a BLOCKER for the actor-held path, not a detail.

3. The actor is instructed to store the mnemonic safely (it is the only recovery path — see 3.6 for the consequence).
4. Mesh wraps existing conversation DEKs to the new actor pubkey (asymmetric wrap, so the actor need not be online for a DEK created while they’re away — a sender can wrap to their published pubkey).

Post-quantum prior art — decide the wrap primitive with harvest-now-decrypt-later in mind. The actor-held wrap protects long-lived secrets: a DEK wrapped to an actor’s X25519 pubkey today is readable by anyone who records the ciphertext now and breaks the discrete log later — the classic harvest-now-decrypt-later exposure that matters precisely for at-rest data meant to stay confidential for years. Signal has already walked this path: PQXDH (spec) is X3DH re-derived to add post-quantum forward secrecy by mixing an ML-KEM shared secret into the agreement, and ML-KEM Braid (spec) extends continuous key agreement with PQ forward secrecy and post-compromise security. The design implication for Mesh is not to adopt either protocol — it is to make the actor-wrap PQ-hybrid from day one if the actor-held path ships: wrap the DEK under a hybrid X25519 + ML-KEM KEM (classical AND post-quantum, so it’s no weaker than today even if ML-KEM is later faulted) rather than retrofitting after a standards shift forces a re-wrap of every stored ciphertext. This is cheap to choose now and expensive to change once actor keys are enrolled. Not a v1 CMEK blocker — a prerequisite for the actor-held fast-follow.

Enrollment protocol + key-derivation must be specified before implementation. Before the actor-held path ships, the design owes: magic-link single-use + short TTL + replay rejection + connector-identity provenance binding; a versioned, domain-separated KDF from the BIP39 seed to the wrapping keypair (BIP39 defines seed derivation only, not the X25519/HPKE keypair — use the seed as HPKE DeriveKeyPair ikm with HKDF label domain separation, RFC 9180) with published test vectors; and rotation/recovery semantics (what access looks like while a key is being replaced). These are prerequisites for the actor-held path, not v1 blockers for the CMEK path.

Actor-only mode has no server-side runtime path. In actor-only mode Mesh holds only the actor’s public key and cannot unwrap the DEK at turn time — so the agent cannot read the message and server-side retrieval/dashboard cannot function. Actor-only is therefore not a server-side agent mode: it is only coherent with client-mediated decryption (the actor’s device unwraps and supplies plaintext for the turn) or a confidential-compute enclave the org cannot inspect. v1 does not build either. So actor-only is documented as a future, client-mediated posture, and the default CMEK path is the only one where the hosted agent works normally.

​

3.5 Threat model, stated honestly (the buyer will ask)

Rogue-operator scope. The “rogue Mesh operator” row is ✅ only for an operator whose reach is limited to the database/backups. An operator who also controls the runtime is the “compromised runtime process” row (❌ for both). These are two different adversaries, listed separately so CMEK protection is not overstated. Metadata is not encrypted. The conversation graph — who talks to whom, when, conversation shapes, participant sets — remains plaintext under both modes and is itself sensitive. That is a stated, accepted limitation, not a hidden one. The actor-only column is mode-dependent. The ✅ for “org admin over-reach” is only true in actor-only mode. Under the recommended default (§3.6: CMEK on, actor-held as an additional wrap), a CMEK wrap of every DEK always exists, so an org admin with KMS access can read employee DMs — the row is ❌ in the default posture and ✅ only when the org fallback wrap is absent. The honest datasheet: if you want employees’ DMs to be unreadable by their own org, you must run actor-only — and accept no legal hold / no recovery. You cannot have both org recoverability and org-blindness; that is a real either/or, not a slider. CMEK scope matches v1 encryption scope. “Mesh encrypts all tenant data under the org key” is scoped in v1 to confidential-shape bodies + confidential-band memories (§3.7). Channel/public content, the metadata graph, search indexes, and logs are not encrypted in v1. The threat table and any buyer claim apply to the confidential subset only.

​

3.6 Cryptographic erasure & the recovery cliff

• Erasure as a feature: destroy all wrapped copies of a conversation’s DEKs (every epoch, every recipient, including the CMEK wrap) and the ciphertext is permanently unreadable. This is a clean answer to GDPR/CCPA “delete my data.”

Per-actor erasure is a no-op under the CMEK-on default. “Delete one actor’s wrapped-DEK copy removes their access” is only true if that copy was ever their access path. Under the default (CMEK on), turn processing and the dashboard go through the org/CMEK wrap, not the actor’s key — so deleting the actor’s wrapped copy revokes nothing and the plaintext stays org-recoverable. Honest framing: per-actor cryptographic erasure is meaningful only in actor-only mode. In the default mode, “delete this actor’s data” is an application-level delete of the rows plus destroying the conversation’s DEKs outright (which affects all participants) — not a per-actor crypto revocation. Erasure ends at the ciphertext boundary. Destroying DEKs makes stored ciphertext unreadable. It cannot claw back plaintext already delivered to actor devices, sent in model-provider payloads, or landed in logs, exports, caches, or unencrypted backups. The GDPR/CCPA story must pair crypto-erasure with a plaintext-copy retention/deletion policy for each of those sinks; crypto-erasure is a component of deletion, not the whole of it.

• The cliff: if actor-held and the actor loses the mnemonic with no org-CMEK fallback wrap, that data is gone forever. This must be a loud, opt-in choice. Default posture: CMEK on, actor-held as an additional wrap, so the org retains a recovery path unless the tenant explicitly chooses actor-only (and signs the waiver). This mirrors E4’s existing “the key is deliberately not in the database / losing it means every ciphertext is opaque” reasoning — we already understand this failure mode for the master key; actor keys make it per-actor.

​

3.7 What NOT to do in v1 (scope discipline)

• Do not encrypt everything. Encrypt bodies of confidential-shape conversations and confidential-band memories. Channel/public content stays plaintext (it’s public anyway, and searchable). This keeps FTS/pgvector retrieval working for the public corpus and confines the crypto-complexity to the data that needs it.
• Do not build actor-held E2E before CMEK. CMEK is sellable, simpler, and doesn’t fight the product. Actor-held is a fast-follow for the paranoid tenant.
• Searchability caveat to flag now: encrypted bodies cannot be server-side full-text or vector searched. Confidential memory retrieval within an authorized turn works (decrypt-then-rank in-process for that turn’s eligible set), but cross-conversation FTS over confidential content is off the table under E2E. This is a real product limitation, not a bug, and it must be decided deliberately.

​

Migration & rollout plan

1. agent_type + principal_actor_id + principal_state schema + the binding-aware consistency constraint (migration).
2. Principal-binding flow (expected-principal-use, compare-and-set); personal agents engage no one until bound.
3. Tier-(-1) engagement-gate short-circuit + decision recording (extends the existing engagement_disposition/tier/signal columns — a type-gated observe is explainable like every other verdict).
4. Acceptance gate: (a) a personal agent observes a non-principal’s @mention; (b) distinct actor identities are preserved (no principal confusion across connectors); (c) binding is deterministic and idempotent (compare-and-set, second attempt is a no-op); (d) no cross-agent prompt/memory bleed; (e) deleting one agent does not mutate another. All must pass before rollout.

​

Open decisions

1. Naming: open vs shared vs general for the third agent type? (Recommendation: open.)
2. assistant privilege semantics: beyond “sees its own confidential memory about the principal,” does the principal get any authority over the agent that a non-principal doesn’t (e.g. can only the principal edit persona / rotate keys)? (Recommendation: yes.)
3. Default encryption posture for hosted tenants: CMEK-on-by-default, or opt-in per tenant? (Recommendation: on-by-default for hosted, given the “trusting us with their data” framing.)
4. Actor-only (no org fallback) — do we even offer it? It’s the strongest privacy story and the sharpest support/data-loss knife. (Recommendation: offer it, behind a signed waiver, not as default.)
5. Confidential-content search: accept that confidential content is not cross-conversation searchable under E2E? (Recommendation: yes; flag it in the datasheet.)
6. workspace band: define its re-emission semantics for v1, or ship only {public, confidential} and add workspace later? (Recommendation: drop it from v1 — an underspecified band in a shipped enum is a latent bug.)
7. RBAC / SSO / SCIM: is enterprise-grade role management + directory sync a GA gate, or a fast-follow? (Recommendation: GA gate for the hosted enterprise tier — two roles won’t survive a real procurement review.)
8. Offboarding runbook: on employee exit, do we deactivate their personal agent, revoke their epoch wraps, and retain org-recoverable data for legal hold? (Recommendation: yes to all three; needs sign-off on retention.)
9. Operator access audit: commit to an immutable audit event on every operator body-read now (couples with §2.5), or defer? (Recommendation: now — it’s cheap to add at the same time as the metadata/body split and expensive to retrofit.)
10. Actor-wrap crypto agility: if the actor-held path ships, is the DEK wrap PQ-hybrid (X25519 + ML-KEM) from the first enrolled key, or classical-only with a later migration? (Recommendation: PQ-hybrid from day one — at-rest secrets are the canonical harvest-now-decrypt-later target, hybrid is no weaker than classical today, and retrofitting means re-wrapping every stored ciphertext. See §3.4.)