---
type: WG
asset_id: WG-EL-IntelliBanks-ConfidencialidadAcceso-v01
version: v01
status: Ejecutado por Opus (equipo rojo) 2026-07-12 → salida en OUT-EL-IntelliBanks-WargameConfidencialidad-Huecos-v01 · pendiente ratificación Victor (L3)
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
superficie: LAB
fecha_creacion: 2026-07-11
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom/Wargames
experimento: EXP-2026-13
proposito: >
  Wargame adversarial de seguridad del sistema de Confidencialidad + Control de Acceso
  de IntelliBanks (ARQ-EL-IntelliBanks-ConfidencialidadAcceso-v01). Fable diseñó; Opus
  ataca. Objetivo: romper el diseño en papel antes de que Alex lo construya — no-autorizado
  que entra, exfiltración, suplantación, bypass de consulta-in-place, fuga cross-tenant y
  caos a escala — y marcar por cada vector si el diseño YA lo cubre o si es un hueco.
mision_origen: >
  SP-EL-IntelliBanks-ConfidencialidadAcceso-Fable-v01 (EXP-2026-13, NEXT: wargame Opus obligatorio) ·
  ARQ-EL-IntelliBanks-ConfidencialidadAcceso-v01 (diseño a atacar)
ejecutor_declarado: >
  Opus 4.8 (equipo rojo · juez adversarial · L2, propone huecos, no construye) ·
  Alex (confirma factibilidad técnica de cada hueco, L1) · Victor (ratifica huecos y aborts, L3)
canonicos_referenciados: >
  ARQ-EL-IntelliBanks-ConfidencialidadAcceso-v01 · ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01 (EXP-09) ·
  RFI-XX-IntelliBanks-BlindajeGobernanzaSync-v01 · TP-EL-IntelliBanks-MultiEmpresa-ZeroTrust-FableBrief-v01 (§4 wargame space) ·
  MePB-EL-WarRoom-WargamingPlaybook-v01 · SOP-EL-WarRoom-WargamingEquipo-v01
tags: [wargame, intellibanks, confidencialidad, control-acceso, seguridad, zero-trust, red-team, opus, LAB, EXP-2026-13]
---

# WARGAME — Confidencialidad + Control de Acceso IntelliBanks
## ⚠️ ORDEN DE WARGAME: este documento SIMULA ataques al diseño move-by-move. NO construye ni ejecuta el sistema. Superficie: LAB. Ejecutor rojo: Opus.

> **Regla de oro de este wargame (herencia del playbook §7 + del SP):** el modelo que diseñó (Fable) **no puede** ser el único que valida. Este WG- lo ejecuta **Opus** como equipo rojo. Fable estructuró los vectores; Opus debe *intentar romperlos de verdad* — buscar el move que el diseñador no vio, no confirmar que el diseño es bueno. Un move donde el rojo "no encuentra nada" con poco esfuerzo es un move mal jugado.

---

## 1. Misión y Resultado Final

**Misión:** someter el diseño de Confidencialidad + Control de Acceso (`ARQ-...-ConfidencialidadAcceso-v01`) a un ataque adversarial estructurado, ANTES de construir, para que Alex reciba una lista priorizada de huecos con su contramove — no un diseño auto-aprobado.

**Resultado final simulado:** Opus recorre los 6 vectores rojos de §3; por cada uno declara *victoria azul* (el diseño ya lo detiene, y se cita la capa exacta) o *hueco* (el rojo pasa, o pasa parcialmente, o el diseño depende de un supuesto no confirmado). La salida es una **tabla de huecos priorizada** (§5) que vuelve al `ARQ-` como correcciones antes de Fase 1b, más un veredicto de arranque: *construir · construir con condiciones · re-diseñar una capa*.

**Diagnóstico de por qué esta misión está donde está:** el diseño es fuerte en el eje que sabe defender (Zero-Trust server-side: un no-autorizado no recibe bytes). Su honestidad declarada — foto a pantalla y cliente recompilado no se previenen, se atribuyen — es correcta pero es también **la superficie donde un rojo serio debe presionar**: ¿la atribución realmente funciona? ¿el watermark forense es tan robusto como el diseño asume? ¿la frontera entre "prevención dura" y "solo fricción" está trazada donde el diseño dice, o hay fugas *no atribuibles* que el diseñador clasificó de más como "solo analógico"? Ese es el corazón del wargame.

**Decisiones ya tomadas (no re-abrir, atacar sobre ellas):** 3 clases C0/C1/C2 · consulta-in-place como canal de C1/C2 · deny-by-default con `doc_grants` (C2 doble firma) · identidad por token de EXP-09 · render + watermark server-side · reuso total del enforcement de EXP-09.

**Fuera de alcance:** re-diseñar EXP-09 (su propio wargame es aparte); atacar la infraestructura física del servidor; pentesting real contra genniux.net (esto es simulación en papel, LAB, no un ataque a producción).

---

## 2. Supuestos y variables indefinidas (→ Ledger)

Regla del playbook: variable sin resolver al handoff = NEXT con owner **antes** del move que depende de ella. Estos son los supuestos del `ARQ-` que el rojo debe tratar como **munición** (un diseño que depende de un supuesto no confirmado es un hueco hasta que se confirme):

| # | Variable / Supuesto (del ARQ §7) | Estado | Owner | Por qué le importa al rojo |
|---|---|---|---|---|
| V1 | **S-1:** `skills` admite `class`+`sealed` y la clase se resuelve en `gate.php` sin query extra | Abierto | Alex | Si la resolución de clase cuesta un JOIN caro, bajo carga (vector F) podría cachearse mal y servir clase equivocada. |
| V2 | **S-3:** Electron soporta partición de sesión NO persistente en memoria + cancelar `will-download` por partición | Abierto | Alex | Es el pilar del viewer efímero (MOVE 4). Si la versión real de Electron no lo soporta limpio, el "cero aterrizaje" se cae. |
| V3 | **S-4:** el previewer actual de `.docx/.pdf` ¿escribe temporales a disco? | Abierto | Alex | Si escribe temporales y ese camino no se prohíbe para C1/C2, hay fuga a `/tmp` — MOVE 4 gira sobre esto. |
| V4 | **S-5:** el servidor puede correr conversión de documentos (LibreOffice headless o microservicio) | Abierto | Alex | Si la conversión no existe aún, el canal §3.3 es vaporware y C1/C2 caería al previewer del cliente (que sí aterriza). |
| V5 | **S-1 EXP-09:** el CDN de genniux.net deja pasar/parte caché por token en POST | Heredado, abierto | Alex | El riesgo #1 del ARQ EXP-09. Si el CDN cachea un `view_stream`, es fuga cross-usuario directa (MOVE 3). |
| V6 | Robustez real del **watermark forense** (§3.4): ¿la marca invisible sobrevive screenshot + recompresión? ¿es única e irreversible por-vista? | No especificado en el ARQ | Victor + Alex | Toda la garantía de atribución del actor autorizado-malicioso (MOVE 2) descansa aquí. El ARQ lo asume; el rojo no debe asumirlo. |
| V7 | Modelo de roles v01 (`admin_global/company_admin/member/guest`) y quién puede otorgar/ratificar grants | Propuesto (S-2) | Victor | Escalada de privilegio (MOVE 5) vive aquí: ¿un `company_admin` puede auto-otorgarse C2 sin segunda firma? |
| V8 | TTL de ticket (5 min) y heartbeat (60s) como ventana de revocación | Propuesto (S-6) | Victor | Define el peor caso de "acceso tras revocación" (MOVE 6). 5 min de ventana ¿es aceptable para un kill-switch? |

**Regla para Opus:** cada vez que un contramove del diseño dependa de una V abierta, **no cuenta como victoria azul** — se marca 🟡 *hueco-condicional: victoria depende de confirmar Vn*. La victoria azul plena solo aplica cuando la defensa no descansa en un supuesto abierto.

---

## 3. Secuencia move-by-move (los 6 vectores del equipo rojo)

Formato por move: **Vector del rojo | Observación esperada (el diseño aguanta VS se rompe) | Punto de falla más probable | Contramove del diseño (capa citada) | Fork/veredicto del juez**. Un vector sin rama de falla creíble está mal jugado.

### MOVE 1 — Rojo: NO-AUTORIZADO que intenta entrar (sin cuenta / revocado)
| Campo | Detalle |
|---|---|
| **Vector** | Actor sin token válido (o con token revocado) instala el app, o apunta un cliente casero a los endpoints, e intenta: montar el vault, listar documentos, abrir un doc por ID directo, sincronizar. |
| **Observación si el diseño aguanta** | Todo endpoint muere en 401 (`require_identity`, gate.php EXP-09 paso 1); el app sin token queda en login, no monta vault ni arranca daemon; 0 bytes de cualquier clase; intentos atribuidos en log. |
| **Observación si se rompe** | Algún endpoint "legacy" (heredado de antes del token) responde sin exigir identidad; o el listado de metadatos (nombre+clase con candado) filtra la existencia de docs C1/C2 a quien no tiene grant. |
| **Punto de falla más probable** | Un endpoint viejo (`get_skill_content`, `render`, `restaurar`, `search`) que EXP-09 no haya migrado aún a `gate.php`, sirviendo por `usuario` legacy sin token. El ARQ asume que TODOS pasan por gate; el rojo debe buscar el que no. |
| **Contramove (capa)** | ARQ §4 (gating por-request) + ARQ §8 (todo endpoint incluye gate.php). Criterio de aceptación g-1/g-6. **Depende de:** que la migración de EXP-09 sea completa — 🟡 hueco-condicional si algún endpoint legacy sigue vivo. |
| **Fork/veredicto** | Si el rojo encuentra UN endpoint sin gate → **hueco crítico**: exige inventario exhaustivo de endpoints con prueba de que cada uno incluye gate.php antes de Fase 1b. Fork: ¿deny-by-default a nivel router (whitelist de endpoints migrados) en vez de confiar en que cada uno llame gate? |

### MOVE 2 — Rojo: EXFILTRADOR autorizado (ve C2 legítimamente, quiere sacarlo)
| Campo | Detalle |
|---|---|
| **Vector** | Usuario CON grant C2 vigente. No necesita hackear: ya puede ver. Intenta sacar el contenido — screenshot, foto con celular, transcripción manual, grabación de pantalla, recompilar el viewer para volcar el buffer. |
| **Observación si el diseño aguanta** | El diseño NO promete impedirlo — promete que todo lo que ese usuario ve está **watermarkeado por-vista y logueado**, de modo que la fuga es **atribuible** a usuario+dispositivo+timestamp. Victoria azul = "cero fuga *no atribuible*", no "cero fuga". |
| **Observación si se rompe** | (a) El watermark forense es removible o no es único por-vista (V6) → la fuga se vuelve NO atribuible. (b) Existe un endpoint que sirve el render SIN watermark (para "admin", para print-to-PDF, para conversión) → el rojo pide esa versión limpia. (c) El log `view_open` no captura suficiente para atribuir de verdad (sin IP, sin device fingerprint, sin qué versión del doc). |
| **Punto de falla más probable** | El watermark (V6): el ARQ lo declara "invisible por micro-variaciones de espaciado" pero no especifica algoritmo, unicidad, ni resistencia a recompresión/recorte. Un rojo serio ataca AQUÍ — si el watermark no sobrevive un screenshot recortado, la garantía central de este actor colapsa. |
| **Contramove (capa)** | ARQ §3.4 (watermark forense server-side, sin endpoint de versión limpia) + §5 (log por vista) + §1 marco de honestidad. Criterio g-8 (atribución forense). **Depende de V6** — 🟡 hasta que el watermark tenga spec real y prueba de robustez. |
| **Fork/veredicto** | Si V6 no está especificado → **hueco alto**: el ARQ asume una capacidad de watermarking que no ha diseñado. Fork: ¿se contrata/construye un watermark forense probado, o se re-clasifica el riesgo R-1/R-2 de "atribuible" a "no prevenible" (y entonces C2 necesita otro control, ej. visor sin exportación en hardware controlado)? Decisión de Victor. |

### MOVE 3 — Rojo: SUPLANTACIÓN (token/ticket robado, request forjado, CDN)
| Campo | Detalle |
|---|---|
| **Vector** | (a) Roba el `view_ticket` de otro usuario (de la red, de logs) y lo reproduce desde su máquina. (b) Roba el token de dispositivo (`.user_session.json` de una máquina compartida) y lo usa desde otra. (c) Fuerza que el CDN cachee un `view_stream` y lo lee sin autorización. (d) Falsifica `usuario` legacy sin token. |
| **Observación si el diseño aguanta** | (a) Ticket atado al token+dispositivo que lo pidió → 403 desde otra máquina (g-5). (b) Token robado = acceso robado, PERO revocable en caliente (§5) y atado a device_label; el diseño lo trata como "editar `.user_session.json` solo puede quitarte acceso" (ARQ EXP-09 §h). (c) `view_stream` es POST + `no-store, private` → CDN nunca cachea (g-7). (d) `usuario` sin token → 401. |
| **Observación si se rompe** | (b) es el flanco real: un token de dispositivo robado de una laptop desbloqueada SÍ da acceso pleno hasta que se revoque — y el usuario víctima puede no saber que se lo robaron. El diseño no tiene binding a hardware ni segundo factor. (a) ¿el "ticket atado al dispositivo" cómo se implementa sin fingerprint confiable? (c) ¿algún proxy intermedio ignora `no-store`? |
| **Punto de falla más probable** | Robo de token de dispositivo (b): es el eslabón humano. El ARQ lo declara "aceptado por diseño Zero-Trust" pero para documentos C2 (sellados, nominales) esa postura puede ser insuficiente — un token robado ve TODO lo que el dueño podía ver, sin segunda barrera. |
| **Contramove (capa)** | ARQ §2 (token EXP-09) + §3.1 (ticket efímero) + §5 (revocación). g-5, g-7. |
| **Fork/veredicto** | Si el rojo sostiene que el robo de token es demasiado fácil para C2 → **hueco medio-alto**: fork hacia (1) re-autenticación (paso-arriba) para abrir C2 aunque el token ya esté vivo, (2) binding del token a características de hardware, o (3) expiración corta de token con re-login. Decisión de Victor (fricción vs seguridad). El ticket robado (a) exige que Opus verifique que el "binding a dispositivo" tiene mecanismo real, no aspiracional. |

### MOVE 4 — Rojo: BYPASS de consulta-in-place (que el contenido aterrice en disco/RAM extraíble)
| Campo | Detalle |
|---|---|
| **Vector** | Usuario autorizado (o su malware) intenta que el contenido C1/C2 toque el disco: fuerza un temporal del previewer, un cache de Electron persistente, un swap de memoria, un `will-download` que no se canceló, un crash que deje dump, o pide el binario original por un endpoint de conversión. |
| **Observación si el diseño aguanta** | Partición de sesión en memoria no persistente (§3.2); `will-download` cancelado; binario original nunca cruza la red para C1/C2 (solo render §3.3); crash = RAM liberada sin artefacto (nunca hubo escritura). Criterio g-3 (0 artefactos incluso tras crash forzado). |
| **Observación si se rompe** | (a) V2/V3: si la versión real de Electron NO soporta partición en-memoria limpia, hay cache en disco. (b) V4/S-4: si el previewer de office escribe temporales y ese camino no se cortó, fuga a `/tmp`. (c) La conversión server-side (§3.3) cachea el render "en zona privada del servidor" — ¿esa zona respeta clearance, o un segundo usuario sin grant puede pedir el render cacheado por su hash? (d) El OS puede swappear RAM a disco (fuera del control del app). |
| **Punto de falla más probable** | (c) el **cache de render server-side por versión del doc**: si la clave de cache es solo el hash del doc (no doc+clearance), es un canal lateral — pedir el render por hash conocido salta el chequeo de grant. Y (b) los temporales del previewer si S-4 resulta "sí escribe". |
| **Contramove (capa)** | ARQ §3.2, §3.3. g-3. **Depende de V2, V3, V4** — casi todo este move es 🟡 hueco-condicional hasta que Alex confirme los internals de Electron y del previewer. |
| **Fork/veredicto** | **Hueco estructural probable:** este move depende de 3 supuestos abiertos a la vez. Veredicto casi seguro: *construir con condiciones* — MOVE 4 no se declara victoria azul hasta que Alex confirme V2/V3/V4 con código a la vista y se pruebe el cache de render con clave (doc+clearance), no solo (doc). Fork: si Electron no da partición limpia → visor server-side puro (render como stream de imágenes, cero HTML/JS ejecutable en cliente). |

### MOVE 5 — Rojo: ESCALADA de clase / privilegio (subir su propio clearance, bajar la clase del doc)
| Campo | Detalle |
|---|---|
| **Vector** | (a) `company_admin` se auto-otorga grant C2 sin la segunda firma. (b) Alguien desclasifica un doc C2→C0 para sacarlo por el canal de sync. (c) Un override de empresa en Capa 0 "re-permite" algo que global prohíbe. (d) El cliente declara la clase de un doc nuevo como C0 para que sincronice, siendo confidencial. |
| **Observación si el diseño aguanta** | (a) grant C2 exige `ratified_by` ≠ `granted_by`, vigencia solo tras segunda firma (§2). (b) desclasificar exige ratificación del ratificador del activo + queda logueado (§1 monotonía). (c) overrides de empresa "solo restringen, nunca amplían" (heredado EXP-09 §c). (d) la clase es veredicto del servidor, el cliente jamás la declara ni degrada (§1). |
| **Observación si se rompe** | (a) ¿el sistema impide técnicamente que `granted_by == ratified_by`, o solo lo pide por convención? Si un `admin_global` (Victor/Alex/Jay) puede ambas firmas, la separación se diluye en la práctica del equipo chico. (b) ¿quién vigila al ratificador? (c) ¿el motor de Capa 0 valida que un override solo restrinja, o confía en que quien lo escribe respete la regla? (d) regla de ruta: un doc creado FUERA de un `path_prefix` clasificado nace C0 — el rojo crea el confidencial en una carpeta no cubierta por reglas. |
| **Punto de falla más probable** | (d) **cobertura de las reglas de clase por ruta**: la confidencialidad por ruta solo protege lo que cae bajo un `path_prefix` declarado. Un documento sensible guardado en una carpeta sin regla nace C0 y sincroniza a texto plano. La clasificación es tan buena como la cobertura de `class_rules` — y esa cobertura es responsabilidad humana (el mismo talón de Aquiles del naming en EXP-09). |
| **Contramove (capa)** | ARQ §1 (monotonía, cliente no declara clase), §2 (doble firma C2). |
| **Fork/veredicto** | (d) → **hueco de gobernanza, no de código**: fork hacia (1) default-deny por sensibilidad (¿carpetas de cliente nacen C1 salvo excepción?), o (2) un clasificador que marque candidatos confidenciales para revisión. (a) → verificar que la doble firma es enforcement técnico (`CHECK granted_by <> ratified_by`), no convención. Decisión de Victor sobre el trade-off usabilidad (equipo de 6) vs rigor. |

### MOVE 6 — Rojo: CAOS A ESCALA (≥20 concurrentes, revocación en caliente, condición de carrera)
| Campo | Detalle |
|---|---|
| **Vector** | 20+ usuarios; uno es revocado mientras tiene un viewer C2 abierto; otro cambia de empresa durante un sync; picos de carga que estresan la resolución de clase (V1) y el cache de gobernanza. El rojo busca la **ventana**: el intervalo entre "revoqué" y "dejó de ver". |
| **Observación si el diseño aguanta** | Revocado: toda petición NUEVA muere al instante (401/404); el viewer abierto muere al siguiente heartbeat (≤60s) o expiración de ticket (≤5 min) — g-2. Cambio de empresa: guardas de EXP-09 (CompanyGuard + servidor). Bajo carga: cache de gobernanza por empresa (`true_map_<cid>`), clase resuelta consistente. |
| **Observación si se rompe** | La **ventana de 5 minutos** (V8): un usuario revocado por una razón urgente (se filtró que es hostil) puede seguir viendo un C2 ya abierto hasta 5 min. Para un kill-switch de seguridad, ¿es aceptable? Además: bajo carga, si la resolución de clase (V1) se cachea agresivamente, ¿puede servirse una clase vieja (doc recién subido a C2 aún visto como C0)? |
| **Punto de falla más probable** | La ventana ticket/heartbeat (V8) como peor caso del kill-switch, y una posible carrera entre "subir clase de un doc" y el cache que aún lo tiene como C0 (ventana de sync antes de la orden de retiro). |
| **Contramove (capa)** | ARQ §4 (heartbeat), §5 (kill-switch ≤5 min), §3.1 (ticket 1-uso). g-2, g-10. |
| **Fork/veredicto** | Si Victor juzga que 5 min es demasiado para el kill-switch de un C2 → **hueco de parámetro**: fork hacia (1) heartbeat más corto para C2 abierto (ej. 15s), (2) canal de invalidación push (servidor cierra el viewer activamente, no espera al heartbeat), o (3) aceptar la ventana y documentarla como riesgo residual ratificado. La carrera clase-vs-cache exige: subir clase invalida cache ANTES de confirmar al cliente. |

---

## 4. Condiciones de aborto

| Trigger | Por qué aborta el wargame (o la construcción) |
|---|---|
| Opus encuentra que **un no-autorizado recibe bytes de contenido** (MOVE 1 o 3 rotos de verdad) | Es la garantía central del sistema. Si se cae, no se corrige un move: se **re-diseña la capa de identidad/gating** antes de cualquier construcción. Stop total. |
| Los supuestos V2/V3/V4 resultan FALSOS (Electron no da partición en-memoria y el previewer sí escribe temporales) | El canal de consulta-in-place es la razón de ser de C1/C2. Si no es implementable como se diseñó, el ARQ §3 se re-hace (fork visor server-side puro) antes de Fase 2 — no se construye sobre un pilar inexistente. |
| El watermark forense (V6) resulta no especificable/no robusto Y Victor no acepta re-clasificar R-1/R-2 | Entonces C2 no tiene control de exfiltración real y la clase C2 debe rediseñarse (hardware controlado, o eliminarse) antes de prometerla a un cliente. |

**Lo que NO aborta (es parte del diseño, no falla):** que un usuario autorizado pueda fotografiar la pantalla (declarado R-1, se atribuye) · que un token robado dé acceso hasta revocación (postura Zero-Trust, salvo que MOVE 3 lo eleve a hueco para C2) · que existan riesgos residuales R-1..R-5 con mitigación de roadmap · huecos-condicionales 🟡 que se cierran confirmando un supuesto con Alex.

---

## 5. Criterios de éxito

**De la misión — salida del wargame (máximo → mínimo):**
- 🥇 Los 6 vectores jugados a fondo; tabla de huecos priorizada (crítico/alto/medio) con contramove y owner por cada uno; veredicto de arranque claro (*construir · construir con condiciones · re-diseñar capa X*); ≥2 unknown-unknowns que el diseñador no marcó.
- 🥈 Los 6 vectores jugados; huecos identificados pero sin priorización fina o sin contramove completo en 1-2.
- 🥉 **Mínimo aceptable:** MOVES 1–4 (los de garantía dura: no-autorizado, exfiltración, suplantación, bypass in-place) jugados con veredicto; MOVES 5–6 al menos enunciados. Sin esto, no hay luz verde de seguridad.
- 🚫 **Resultado prohibido:** "el diseño se ve sólido" sin un solo hueco ni supuesto elevado — sería auto-aprobación disfrazada, exactamente lo que este wargame existe para evitar. Si Opus no encuentra nada, no jugó.

**Del wargame mismo:** cada move con rama de falla creíble ✅ · cada victoria azul cita la capa exacta del ARQ ✅ · toda defensa que dependa de un supuesto abierto marcada 🟡 (no contada como victoria plena) ✅ · la frontera prevención-dura VS fricción-atribuible re-examinada, no heredada ✅ · ejecutable por Opus sin este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Equipo rojo · juez adversarial (jugar los 6 moves, producir tabla de huecos) | **Opus 4.8** en room aparte | L2 (propone huecos y contramoves; NO construye, NO edita el ARQ) | — |
| Confirmar factibilidad técnica de cada hueco y de los supuestos V1–V5 | Alex | L1 (aporta internals; decide construcción después) | — |
| Ratificar huecos, aborts y decisiones de negocio (V6 watermark, V7 roles, V8 TTL) | **Victor** | L3 | Firma el veredicto de arranque |
| Sherpa · registrar salida en vault + CAS al LabPraxis + recalibrar el ARQ | Jay | L1 | — |

**Condición de arranque:** ratificación de este WG- por Victor ("ratificado") → se abre room **Opus** con este documento + el `ARQ-...-ConfidencialidadAcceso-v01` + el `ARQ-...-MultiEmpresa-ZeroTrust-v01` (EXP-09) como contexto. Opus juega, no construye. **Superficie LAB estricta:** este wargame nunca toca producción ni genniux.net; es simulación en papel.

**Instrucción lista para pegar en el room de Opus:**

```
Eres el EQUIPO ROJO y el juez adversarial de un wargame de seguridad, bajo la metodología WORX de EmpowerLabs. NO construyes ni ejecutas nada — atacas un diseño EN PAPEL para encontrar dónde se rompe antes de que se construya. Superficie: LAB.

Diseño a atacar: ARQ-EL-IntelliBanks-ConfidencialidadAcceso-v01 (adjunto), que se monta sobre ARQ-EL-IntelliBanks-MultiEmpresa-ZeroTrust-v01 (EXP-09, adjunto).

REGLA DE ORO: el modelo que diseñó esto fue Fable; tú NO puedes auto-aprobarlo. Tu trabajo es encontrar el move que el diseñador no vio. Si "no encuentras nada", no jugaste — vuelve a atacar más fuerte. Presiona especialmente donde el diseño se declara "solo fricción" o "riesgo residual": verifica que la frontera entre prevención dura y atribución esté donde el ARQ dice, y no más adelante.

Juega los 6 vectores de la Sección 3 del WG- adjunto (no-autorizado que entra · exfiltrador autorizado · suplantación/token/ticket/CDN · bypass de consulta-in-place · escalada de clase/privilegio · caos a escala con revocación en caliente). Por CADA vector:
1) Ejecuta el ataque paso a paso, buscando la variante que el ARQ no cubre.
2) Declara VICTORIA AZUL (cita la capa exacta del ARQ que lo detiene) o HUECO (el rojo pasa, total o parcial).
3) Si la defensa depende de un supuesto abierto (V1–V8 del Ledger §2), NO es victoria plena: márcalo 🟡 hueco-condicional.

Presta atención especial a: (a) endpoints legacy de EXP-09 que quizá no pasen por gate.php; (b) robustez REAL del watermark forense (V6) — no la asumas; (c) el cache de render server-side: ¿su clave es (doc) o (doc+clearance)?; (d) cobertura de las reglas de clase por ruta (un doc confidencial en carpeta sin regla nace C0); (e) la ventana de 5 min del kill-switch.

ENTREGABLE: una tabla de huecos PRIORIZADA (crítico/alto/medio) con contramove y owner por cada uno, ≥2 unknown-unknowns que el diseñador no marcó, y un veredicto de arranque: CONSTRUIR / CONSTRUIR CON CONDICIONES / RE-DISEÑAR CAPA X. Formato naming BMF, listo para volver al ARQ como correcciones. Guárdalo para el vault en PB-EL-IALab/WG-EL-WarRoom/Wargames/.
```

**Salida esperada del ejecutor:** un `OUT-EL-IntelliBanks-WargameConfidencialidad-Huecos-v01` (o se anexa la tabla de huecos a este WG- como recalibración v01-r1, per playbook §6.3) → vuelve al `ARQ-` como correcciones antes de Fase 1b → CAS al LabPraxis.

---

## 7. CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01-r1 | 2026-07-12 | **Ejecutado por Opus** (equipo rojo) en room Opus. Salida: `OUT-EL-IntelliBanks-WargameConfidencialidad-Huecos-v01` — 12 huecos (3 críticos, 4 altos, 5 medios) + 3 unknown-unknowns. Hallazgo central: watermark protege píxeles, no el canal (texto limpio en el DOM + cache base sin marca) → C2 no cumple "exfiltración atribuible". Veredicto: CONSTRUIR CON CONDICIONES; canal de render C2 a re-diseñar. |
| v01 | 2026-07-11 | Creación (draft + hardening, 2 pasadas) con Fable 5. Estructura el wargame de seguridad de EXP-2026-13 sobre el ARQ de confidencialidad: 6 vectores rojos (no-autorizado, exfiltrador autorizado, suplantación/token/ticket/CDN, bypass consulta-in-place, escalada de clase/privilegio, caos a escala), cada uno con rama de falla, punto de falla más probable, contramove citando la capa del ARQ y veredicto del juez. Ledger de 8 supuestos (V1–V8) como munición del rojo, con la regla "defensa que depende de supuesto abierto = victoria condicional 🟡". Foco declarado del ataque: la frontera prevención-dura vs fricción-atribuible, el watermark forense (V6), los endpoints legacy sin gate, el cache de render por clave (doc) vs (doc+clearance), la cobertura de reglas de clase por ruta y la ventana de 5 min del kill-switch. Handoff a Opus (equipo rojo, L2, no construye) con instrucción lista para pegar. Superficie LAB estricta. Pendiente ratificación de Victor antes del handoff. |