--- type: RFI asset_id: RFI-XX-Intellibanks-MultiBank-Seguridad-v01 version: v01 status: Borrador (revisión técnica) owner: Victor Heredia sherpa_owner: Jay asignado_a: equipo de desarrollo Intellibanks fecha_creacion: 2026-06-15 fecha_ultima_actualizacion: 2026-06-15 intellbank: IB-XX-Maestro subbank: IPI-XX-IP-Infraestructura/IPI-XX-SX-SherpaX-Architecture proposito: Especificar la evolución de Intellibanks a plataforma multi-banco con control de acceso por rol, gobernanza servida sin persistir en disco, y archivos canónicos protegidos. referencias_canonicas: - DC-XX-SX-ConceptoIntelliBank-v01 - CP-XX-IntelliBanks-Registry-v01 - DC-XX-PreMigracion-IntelliBanks-Readiness-v01 - RFI-XX-WORX-GobernanzaNoModificable-v01 - DC-XX-RFI-TipoActivo-Definicion-v01 tags: [RFI, intellibanks, multi-banco, seguridad, multi-tenant, XDoc, XX, infraestructura] --- # RFI · Intellibanks v2 — Multi-Bank + Seguridad de la Información - **Asset ID:** RFI-XX-Intellibanks-MultiBank-Seguridad-v01 - **Fecha:** 2026-06-15 - **Owner:** Victor Heredia - **Sherpa:** Jay - **Asignado a:** equipo de desarrollo Intellibanks - **Estado:** Borrador (revisión técnica) --- ## En una frase Convertir Intellibanks de un **espejo nube↔1 carpeta para un usuario** a una **plataforma multi-banco con control de acceso por rol**, donde cada usuario solo sincroniza los bancos que le corresponden, los archivos canónicos no se pueden modificar, y el paquete de gobernanza (el "sistema operativo" WORX) está disponible al SherpaX **sin descargarse de forma persistente** en la máquina. ## Contexto (estado actual, resumido) Hoy la app sincroniza **una** carpeta local (`~/Documents/Intellibanks`) contra **un** espacio en la nube, casi en tiempo real, vía un daemon bidireccional. Limitaciones para nuestro objetivo: - **Un solo banco / sin control de acceso por rol:** todos los que sincronizan ven todo. - **Sin protección de archivos canónicos:** cualquier usuario puede editar y propagar cambios. - **Sin separación por empresa/scope:** no hay forma de dar a un promotor externo solo "su" banco. - **El pull es espejo total** (descarga todo el espacio), lo que es contrario a "que la gente no descargue lo que no debe". > **Base canónica (Gate G0 · vault-first):** ver [[DC-XX-SX-ConceptoIntelliBank-v01]] (concepto), [[CP-XX-IntelliBanks-Registry-v01]] (naming/bancos) y [[DC-XX-PreMigracion-IntelliBanks-Readiness-v01]] (readiness de migración). --- ## Las 4 capacidades a implementar ### C1 · Multi-Banco con acceso por rol (multi-tenant) Intellibanks debe poder alojar **varios bancos** (por empresa o por scope) y conceder acceso **por rol**. - Un *banco* = una frontera de acceso (p.ej. `IB-XX-Maestro`, `IB-EL-EmpowerLabs`, `IB-REB-Rebelocity`, `IB-Clientes/`). - Cada usuario pertenece a uno o más roles; cada rol concede acceso a bancos específicos (y opcionalmente subcarpetas). - **El servidor decide qué puede ver y bajar cada usuario.** No basta con ocultar en el cliente. **Ejemplo guía:** un *promotor externo de Rebelocity* accede a un banco con procesos y documentos predefinidos (p.ej. un LoopX de ventas), pero **no** ve `IB-XX-Maestro` ni el `IB-EL-EmpowerLabs` completo. ### C2 · Selección de banco + arranque de room por banco - El usuario **selecciona/cambia el banco activo** en la app; eso define **qué carpeta local se sincroniza con qué banco de la nube**. - Cambiar de banco re-apunta el scope de sync (cada banco → su carpeta local, p.ej. `~/Documents/Intellibanks/IB-REB-Rebelocity`). - El SherpaX del usuario puede arrancar el room con el contexto del banco correspondiente: `/arrancaroom-reb`, `/arrancaroom-el`, etc. Cada comando **recarga el paquete de contexto/gobernanza de ese banco**. ### C3 · Paquete de gobernanza ("OS" WORX) sin descarga persistente El SherpaX (operando vía Cowork) necesita acceso al **paquete que declara la gobernanza y la implementación del sistema operativo WORX** (hoy lo cargan `/worx-empowerlabs:arrancaworx` y `/worx-core:arrancaroom`). - Ese paquete debe estar disponible al arrancar un room, **pero sin quedar descargado de forma permanente** en la máquina del usuario. - **Decisión confirmada por Victor (2026-06-15):** el paquete se **sirve/ejecuta desde la nube sin persistir en disco** (ejecución en línea, sin copia local accesible). No es descarga efímera con borrado posterior. - Objetivo de seguridad: que el usuario no pueda copiar/exfiltrar el paquete de gobernanza. ### C4 · Archivos canónicos protegidos (no modificables) — XDoc Ciertos archivos **canónicos** (gobernanza, definiciones de proceso, Clase C) **no deben poder ser modificados por el usuario**. > **Nota WORX (Gate G0):** esta capacidad **ya está especificada** en [[RFI-XX-WORX-GobernanzaNoModificable-v01]]. Este RFI **la consume e integra al modelo multi-banco** — no la redefine. Los RF-10/11/12 de abajo expresan la **interfaz esperada**; el detalle de implementación de la capa no-modificable vive en ese RFI. - Marcar el archivo como protegido con un **identificador a nivel de archivo** (p.ej. frontmatter `xdoc: canonical` / `protected: true`, o un flag de servidor). - El motor de sync debe **respetar la protección**: una edición local a un archivo protegido **no se propaga** a la nube y se **revierte** a la versión canónica (o se bloquea la edición en origen). - Solo roles autorizados (Owner/Ratificador) pueden cambiar un canónico, vía un proceso explícito de versionado. --- ## Requisitos de seguridad transversales 1. **Mínimo privilegio:** cada usuario recibe únicamente los bancos/carpetas que su rol permite. La aplicación **nunca** descarga lo que el rol no autoriza. 2. **Enforcement en el servidor:** el control de acceso y la protección de canónicos se validan en el backend; el cliente no es la fuente de verdad. 3. **Sin descarga total:** sustituir el "espejo completo" por **sincronización por banco/scope** según permisos. 4. **Auditoría:** registrar quién accede, baja o intenta modificar qué (al menos para bancos y canónicos). 5. **Revocación:** quitar el acceso a un banco debe dejar de sincronizarlo y (idealmente) limpiar la copia local de ese banco. ## Modelo propuesto (a validar): "conector con permisos por banco" En lugar de un espejo local total, tratar cada banco como un **conector autenticado con ACL**, similar a cómo conectamos el Drive de Google: el usuario autentica, el servidor expone **solo** los bancos de su rol, y la sincronización opera dentro de ese scope. Esto resuelve de raíz la fuga de archivos (no se puede bajar lo que el conector no expone) y habilita el multi-banco de forma natural. ``` Usuario (rol) ──auth──> Backend Intellibanks ──ACL──> Bancos permitidos │ selecciona banco activo → sincroniza SOLO esa carpeta arranca room (/arrancaroom-reb|el) → carga gobernanza del banco (en línea) archivos canónicos → solo-lectura para el usuario ``` --- ## Casos de uso de referencia - **Promotor externo Rebelocity:** rol `promotor-reb` → solo `IB-REB-Rebelocity` (procesos de venta, LoopX). No ve Maestro ni EL. Arranca `/arrancaroom-reb`. - **Colaborador EmpowerLabs:** rol `colaborador-el` → `IB-EL-EmpowerLabs` (+ lectura de canónicos de Maestro). Arranca `/arrancaroom-el`. - **Owner/Ratificador (Victor):** acceso completo + capacidad de modificar canónicos vía versionado. ## Requisitos funcionales (numerados, verificables) **Multi-banco / acceso** - RF-01: El sistema soporta N bancos independientes con su propio contenido. - RF-02: Cada rol define a qué bancos (y subcarpetas) accede; el backend lo hace cumplir. - RF-03: Un usuario sin acceso a un banco no puede listarlo ni descargarlo. **Selección y sync por banco** - RF-04: El usuario puede seleccionar/cambiar el banco activo en la app. - RF-05: Cada banco se sincroniza a una carpeta local distinta, solo dentro de su scope. - RF-06: Cambiar de banco re-apunta el sync sin mezclar contenidos de otros bancos. **Arranque de room por banco** - RF-07: Comandos por banco (`/arrancaroom-reb`, `/arrancaroom-el`, …) cargan el paquete de contexto/gobernanza de ese banco. **Gobernanza sin descarga persistente** - RF-08: El paquete de gobernanza/OS está disponible al SherpaX **servido en línea, sin persistir** en la máquina. - RF-09: El usuario no puede copiar/exfiltrar el paquete de gobernanza por la vía normal de archivos. **Protección de canónicos (XDoc) — interfaz; detalle en [[RFI-XX-WORX-GobernanzaNoModificable-v01]]** - RF-10: Un archivo puede marcarse como canónico/protegido mediante identificador a nivel de archivo. - RF-11: Ediciones locales a un archivo protegido no se propagan y se revierten a la versión canónica. - RF-12: Solo roles autorizados pueden versionar/actualizar un canónico, mediante proceso explícito. **Seguridad y auditoría** - RF-13: Todo acceso/descarga/intento de edición de bancos y canónicos queda registrado. - RF-14: Revocar acceso detiene el sync y limpia la copia local del banco afectado. ## Requisitos no funcionales - Sincronización casi en tiempo real (mantener el comportamiento actual dentro de cada banco). - La cola secuencial y la de-duplicación deben operar **por banco** (no mezclar IDs entre bancos). - Compatibilidad de-duplicación: **deduplicar también por hash de contenido** dentro del banco (hoy duplica por nombres distintos con mismo contenido). ## Supuestos - Los comandos WORX (`arrancaworx`, `arrancaroom`) siguen siendo la vía de carga de contexto; la app solo debe **proveer el paquete correcto por banco** de forma segura. ## Preguntas abiertas para el equipo 1. ¿El control de acceso vivirá en el backend actual (`genniux.net/skills-api`) o requiere una capa de identidad/roles nueva? 2. Para C3 (ya definido: servido en línea sin persistir): ¿qué tan estricta debe ser la "no exfiltración" — a prueba de usuario técnico (memoria/red) o basta con que no quede archivo en disco? 3. Para C4: coordinar con [[RFI-XX-WORX-GobernanzaNoModificable-v01]] — ¿enforce en servidor (rechaza el push), en cliente (bloquea edición), o ambos? ¿El identificador va en frontmatter, en metadata de servidor, o ambos? 4. ¿El modelo "conector con ACL" reemplaza al espejo local actual, o conviven? 5. ¿Multi-banco simultáneo (varias carpetas sincronizando a la vez) o un banco activo a la vez? ## Criterios de aceptación (MVP de seguridad) - Un promotor de Rebelocity, al conectar, **solo** ve y sincroniza `IB-REB-Rebelocity`; intentar acceder a Maestro/EL falla en el servidor. - Un archivo canónico editado localmente **no** sobreescribe la versión de la nube y se revierte. - El paquete de gobernanza se carga al arrancar el room **sin** dejar copia persistente accesible al usuario. - Cambiar de banco re-sincroniza la carpeta correcta sin filtrar contenido de otros bancos. --- ## Relationships / Referencias canónicas - Especifica la evolución de: [[DC-XX-SX-ConceptoIntelliBank-v01]] - Naming y gobernanza de bancos: [[CP-XX-IntelliBanks-Registry-v01]] - Readiness de migración: [[DC-XX-PreMigracion-IntelliBanks-Readiness-v01]] - C4 (protección de canónicos) implementada por: [[RFI-XX-WORX-GobernanzaNoModificable-v01]] - Tipo de activo: [[DC-XX-RFI-TipoActivo-Definicion-v01]] ## Changelog | Versión | Fecha | Cambio | |---|---|---| | v01 | 2026-06-15 | Creación. Conformado a WORX (frontmatter RFI + cabecera + relaciones). C3 confirmada (servido en línea sin persistir). C4 referenciado al RFI de gobernanza no-modificable en vez de duplicarlo. | ## NEXTs - [ ] Ratificación de Victor (L3+). - [ ] Asignar implementador y fecha límite. - [ ] Coordinar C4 con el owner de [[RFI-XX-WORX-GobernanzaNoModificable-v01]].