V7 Operator Data Protection — Realm Operators as Data Processors

Status: V7 privacy/compliance design. Source: fills the planning gap identified in V1_V7_PLAN_SET_AUDIT_2026-06-12.md §6.2 (no operator data-protection regime for BYO-compute realms). Grounded in V7/V7_ARCHITECTURE.md (arch§"The Trust Boundary — Platform vs. Realm", arch§"Nephthys — Persistence and the Replication Layer", arch§"Data Architecture, Residency, and Compliance", arch§"Hosting, Orchestration, and the Realm Fleet") and V7/V7_features.md (features§"Nàná — Persistent Characters", features§"Hosting, Orchestration, and Who Pays"). The identity-leak eval gate (V7/ADVERSARIAL_EVAL_GATES.md) is the technical enforcement companion to this document. Owner: platform privacy counsel (DPO) with the Nephthys lead (architecture) and the Sekhmet lead (vetting). Date: 2026-06-12. Legal review required before any BYOC realm goes live; the structures below are the engineering-and-policy plan that counsel reviews, with assumptions labeled.

1. The Problem#

Nàná characters are rich personal data: legal-style names and aliases, appearance, employment, property, relationships, criminal/medical RP records (arch§"Nàná — Character and Economy Data Model"). On platform-orchestrated realms this data stays inside platform-controlled processes. But features§"Hosting" commits to bring-your-own-compute (BYOC): high-volume realms may run the sandboxed Moremi process on operator hardware. The moment character data enters a process on hardware an operator controls, that operator is processing personal data — memory dumps, hypervisor access, and disk forensics are outside the WASM sandbox's threat coverage. The sandbox protects players from realm code; this document protects players from realm infrastructure.

2. Data Minimization Architecture — What Reaches a Realm Process#

Design rule: the realm plane receives the minimum data the simulation needs, keyed by pseudonymous realm-scoped IDs; PII stays on the platform plane.

2.1 Platform-side only (never reaches any realm process, BYOC or not)#

• Platform account identity: email, phone, credentials, payment instruments, KYC artifacts, age-assurance results and bands (arch§"Sekhmet"), device attestation records, cross-realm ban/reputation, Ori private aggregates.
• Voice/chat safety analysis streams (platform-monitored per arch§"Pheme" — the realm gets the mixed audio routing instructions, not safety telemetry).
• Real-money economy data: purchases, entitlements, payout records (Aje).

This is already the trust boundary (arch§"The Trust Boundary"); the identity-leak gate enforces that realm-visible identity contains only realm-scoped opaque handles. This document extends the same discipline to the character aggregate.

2.2 Realm-visible, pseudonymized#

A realm process receives, per joined player:

• the realm-scoped pseudonymous handle (realm_player_id, unlinkable across realms without platform keys — the per-realm opaque handle of features§"The Trust Boundary");
• the character's in-fiction record: character name (player-authored fiction, treated as content but handled as potentially-identifying — see §2.3), appearance ref, licenses, job, inventory, balances, property, RP criminal/medical record, realm-scoped relationship edges keyed by other realm_player_ids (arch§"Nàná");
• session-operational data: connection quality stats, position/intent streams.

Explicitly NOT realm-visible: real name, email, age band beyond the boolean gates the realm needs ("minors-permitted realm: joinable yes/no" is computed platform-side; the realm never sees an age), platform user ID, other-realm characters, payment status beyond entitlement grants.

2.3 The honest caveat — pseudonymized ≠ anonymous#

Character data is player-authored and players self-disclose; a relationship graph plus chat is re-identifiable in practice. Therefore the architecture treats realm-visible character data as personal data under GDPR (pseudonymization per Art. 4(5) reduces risk; it does not exit the regulation), and the whole §3–§7 regime applies. Planning assumption adopted 2026-06-12: we do not claim anonymization anywhere in operator-facing or player-facing copy.

2.4 BYOC-specific hardening#

• Nephthys never runs on operator hardware. BYOC nodes run sim only; persistent truth stays platform-side (arch§"Nephthys", features§"Hosting" — "only the sandboxed realm logic, never platform services"). An operator's disk holds at most a warm cache of the working set.
• Working-set cache is encrypted at rest with a platform-held, per-realm-session key delivered to the attested node at lease time and rotated per session; node decommission = key destruction = cache cryptographically erased. Planning assumption adopted 2026-06-12 (engineering task for the Agones BYOC node image, arch§"Hosting").
• Interest-managed data delivery: a BYOC node receives only the aggregates for entities it currently has authority over (arch§"Danu" single-writer + AoI), not the full realm population's records.
• No raw voice retention on BYOC nodes: Pheme mixing instructions only; media flows through the platform SFU (arch§"Pheme — Voice Architecture").

3. GDPR Roles Analysis#

Planning assumption adopted 2026-06-12 — counsel to confirm per market; this is the working model the contracts and engineering build against.

• Platform = controller for: platform identity, safety, economy, age-assurance, cross-realm reputation, and the Nephthys character store. The platform determines purposes/means of the core processing.
• Operator = processor for: realm-visible character/session data processed on BYOC infrastructure on the platform's documented instructions (run the sim, enforce realm rules). This is the default and the only supported posture for the character data the platform delivers.
• Operator = independent controller for processing the operator initiates outside platform instructions: their own Discord/forums, their own whitelist application forms collecting emails off-platform, their own analytics on exported data, any scraping/retention beyond the documented cache. The DPA (§4) requires operators to declare such processing; platform-side, the rule is to starve it — whitelist applications, realm analytics, and moderation evidence are all offered as platform surfaces (features§"Whitelisting and Realm Moderation", features§"Streaming, Spectating, and the Creator Loop" creator analytics) so an operator never needs to stand up independent processing.
• Trigger consequences when an operator becomes an independent controller: they assume their own lawful-basis, transparency (Art. 13/14), DSAR, and breach duties for that processing; the platform's DPA obliges them to say so in their realm's privacy notice (a templated notice is provided), and undeclared independent processing of platform-delivered data is a DPA breach → §6 enforcement (vetting-tier downgrade up to BYOC revocation).
• Joint controllership is avoided by design: the platform does not co-determine purposes of an operator's off-platform community spaces, and operators do not co-determine platform processing. Counsel to validate that the realm-rules sovereignty (features§"Eunomia") does not create joint control over character data; the mitigating design fact is that operators configure game rules, not processing purposes.

4. The Operator DPA (Data Processing Agreement)#

Every BYOC operator must execute the platform DPA (click-through with signed record in the operator's compliance file) before the first BYOC node lease. Non-BYOC operators of platform-orchestrated realms accept a lighter data-handling addendum in the operator terms (they control no infrastructure, but they do see realm-visible data through admin tools). DPA contents (Art. 28 GDPR checklist mapped to V7 mechanics):

1. Subject matter/duration: sim processing for the named realm; duration = node-lease lifetime + cache-key lifetime.
2. Documented instructions: run the signed Moremi build delivered by the platform, unmodified, on the conformant node image; no other processing of platform-delivered data. Out-of-instruction processing requires the §3 independent-controller declaration.
3. Confidentiality: operator staff with node access are enumerated in the Operator Console (max 10 per realm; planning assumption adopted 2026-06-12) and bound to confidentiality terms.
4. Security measures (Art. 32): the conformant node image (attested boot, encrypted cache per §2.4, no inbound ports except the platform gateway tunnel — arch§"Hosting" DDoS posture), OS patch currency ≤30 days, disk-encryption attestation, and the prohibition on memory-dump tooling on production nodes.
5. Sub-processors: the operator's hosting provider (their datacenter/cloud) is a declared sub-processor; changes require 14-day prior notice through the Operator Console. Bare-metal-in-a-bedroom is permitted only at vetting Tier 2 with the physical-security self-attestation.
6. Data-subject rights assistance: all DSARs route to the platform (the controller); the operator's duty is the §7 deletion/rectification propagation SLA and never answering DSARs independently for platform-delivered data.
7. Breach notification: §8 — operator → platform without undue delay, target ≤24h from awareness.
8. Deletion/return at end of processing: node decommission destroys cache keys (§2.4); the operator attests deletion of any out-of-band copies within 7 days of realm termination or BYOC exit.
9. Audit rights: remote attestation telemetry continuously; the platform may run a remote conformance audit (image hash, port scan, patch level) at any time and an on-notice deeper audit for cause; Tier 2 operators accept an annual questionnaire audit.
10. International transfers: BYOC nodes must be located in a region compatible with the realm's residency tag (libs/shared/data-residency/, arch§"Data Architecture, Residency, and Compliance"); node region is declared and verified by network probe; SCCs incorporated for cross-border cases per counsel.

5. Operator Vetting Tiers#

Tied to the realm capability system: the registry refuses configurations above the operator's tier. Thresholds are planning assumptions adopted 2026-06-12.

Rationale: anonymous operators get capability-restricted realms because every §3–§8 duty needs an accountable legal person behind it; minors-permitted + operator-controlled-hardware is the highest-risk combination and therefore requires the strongest identity (T2) — and even then, all child-safety systems remain platform-central and never realm-delegated (features§"Child Safety and Age Assurance"). A tier downgrade (sanction or KYC lapse) forces the realm into the nearest compliant configuration with 14 days' notice, migrating BYOC realms onto the platform fleet automatically (possible precisely because Nephthys holds the truth — arch§"Nephthys").

6. Enforcement#

DPA/vetting violations follow a ladder parallel to V7/docs/off-platform-monetization-policy.md §5: written finding → BYOC suspension (realm auto-migrates to platform fleet, operator pays the platform-hosting rate) → tier downgrade → operator termination. Child-safety or data-exfiltration findings skip directly to suspension + investigation. Owner: Kuanyin enforcement with DPO sign-off; Themis appeals.

7. Deletion Propagation to Realm Stores#

Mechanism, SLA, attestation — for player account deletion, character deletion (within Iris consent limits, features§"Nàná — Persistent Characters"), and rectification:

1. Source of truth deletes first: Nephthys executes the deletion on the platform-side aggregate (event-sourced tombstone + projection erasure + snapshot rewrite on next checkpoint; crypto-erase for encrypted-at-rest cold segments). DSAR intake reuses V5 compliance-dsar (arch§"Data Architecture, Residency, and Compliance").
2. Tombstone fan-out: a signed deletion event for the realm_player_id fans out on the platform event bus to every realm that ever held that character's aggregate (Nephthys knows the delivery history).
3. Live realms drop the working-set entries immediately (≤1 hour) and confirm by signed ack.
4. BYOC caches: per §2.4, session-key rotation makes any non-live cache unreadable; the next lease simply never receives the deleted aggregate. For out-of-band copies an operator declared (independent-controller processing), the tombstone triggers their own deletion duty.
5. SLA: platform-side complete ≤72 hours; realm-plane (live + cache) complete ≤7 days; the statutory DSAR clock (30 days) is met with margin. Planning assumption adopted 2026-06-12.
6. Attestation: the Operator Console records, per deletion event, the signed acks; a quarterly deletion-propagation report is generated per BYOC operator; missing acks auto-escalate at 7 days to §6 enforcement. The deletion path is exercised in CI as part of the DSAR test suite, and a deletion-propagation adversarial fixture (a realm that fakes its ack) must be detectable via cache-audit probes — add to the V7/ADVERSARIAL_EVAL_GATES.md inventory when the Nephthys test rig lands (owner: Nephthys lead).

In-fiction nuance: a realm owner cannot silently erase a character (the steward-not-owner posture, features§"Nàná"); conversely a player's deletion right wins over the realm's narrative continuity — realms get a "character retired" narrative tombstone, never the data.

8. Breach Notification Duties Through Operators#

• Operator duty (DPA §7): on awareness of any incident affecting a BYOC node (compromise, theft, memory-dump evidence, unauthorized staff access), notify the platform security desk without undue delay, target ≤24h, via the Operator Console incident form (which timestamps awareness claims).
• Platform duty: the platform (controller) assesses risk and makes the Art. 33 supervisory-authority notification within 72h where required, and Art. 34 player notification where high-risk; the operator never notifies authorities or players directly for platform-controlled data.
• Containment is platform-executable: node-lease revocation + cache-key destruction + auto-migration to the platform fleet can be executed unilaterally within minutes of a credible report (the same machinery as §5 tier downgrade), so containment never waits on the operator.
• Drill: one tabletop BYOC-breach exercise per year including a real test realm, measured against the 24h/72h clocks; results feed the incident-response drill gate (features§"Launch Readiness"). Planning assumption adopted 2026-06-12.

9. Open Items for Counsel (tracked, not assumed)#

1. Confirm controller/processor allocation (§3) per launch market; UK/EU/US state splits.
2. SCC module selection for BYOC cross-border edge cases (§4.10).
3. Whether RP "criminal/medical records" trigger special-category arguments in any market despite being fiction (design already treats them at the highest handling tier, so a "yes" changes paperwork, not architecture).
4. Age-assurance data flows never touch operators by design — counsel to confirm no market imposes operator-level duties anyway.