Resumen de seguridad
La plataforma PointSav aplica la seguridad a través de la arquitectura. Aislamiento basado en capacidades, flujo de comandos unidireccional, un libro WORM que hace estructuralmente imposible la modificación de registros, y un único límite de IA que registra cada llamada en el libro de auditoría por inquilino — estas propiedades se mantienen porque la arquitectura hace imposible su violación, no porque una política lo prohíba.
El servicio Portero centraliza todas las claves API externas y registra cada llamada de inferencia de IA. Ninguna solicitud de IA llega a un modelo externo sin pasar por este límite, y ninguna llamada al límite queda sin registrar. El registro no es opcional: es una propiedad estructural del Portero, no una configuración que un administrador pueda desactivar.
El estándar Diode impone una disciplina de flujo de comandos unidireccional en toda la flota. El tráfico fluye de autoridad a sujeto y nunca al revés. Un nodo que recibe un comando no puede iniciar un comando al nodo que lo envió. Los ataques de movimiento lateral requieren la lógica de enrutamiento que el Diode elimina.
Un responsable de seguridad puede verificar que la IA no ha tocado el registro autoritativo sin confiar en las afirmaciones del proveedor. La arquitectura de tres anillos proporciona la respuesta arquitectónicamente: los Anillos 1 y 2 no tienen ninguna importación, dependencia ni llamada en tiempo de ejecución que alcance el Anillo 3.
Aislamiento de inquilinos
La plataforma aplica el aislamiento de inquilinos en tres capas:
Aislamiento a nivel de kernel en el Anillo 1. Los servicios de límite del Anillo 1 de cada inquilino se ejecutan como procesos separados con raíces de almacenamiento separadas. No existe ninguna ruta de código de los datos del Anillo 1 de un inquilino a los de otro. Totebox OS aplica esto a nivel de kernel: la seguridad basada en capacidades significa que ningún componente puede acceder a los recursos de otro sin tener un token de capacidad criptográfico concedido explícitamente en el aprovisionamiento.
Aislamiento de espacio de nombres en el Anillo 2. Los servicios del Anillo 2 son multiinquilino mediante moduleId. El grafo de conocimiento y el índice de búsqueda de cada inquilino están aislados detrás de su espacio de nombres moduleId en cada ruta de lectura y escritura. Una consulta para el inquilino A no puede devolver registros del inquilino B.
Aislamiento de IA de límite único en el Anillo 3. Servicio de inferencia de IA es el único servicio del Anillo 3. Cada solicitud de IA pasa por el Portero, que enruta entre tres niveles de cómputo y escribe una fila de auditoría en el libro local del cliente antes de que se realice cualquier llamada externa.
El límite del Portero
El Portero es el único punto por el que fluye toda la inferencia de IA. Aplica cinco propiedades:
Ninguna clave vive fuera del Portero. Las claves API para proveedores de IA externos se mantienen exclusivamente en el Portero. Ningún otro proceso de la plataforma tiene acceso a estas claves. Una brecha en cualquier servicio que no sea el Portero no puede exponer claves API externas.
Cada llamada se registra antes de realizarse. El Portero escribe una fila de auditoría en el libro local del cliente antes de enviar la llamada externa. Una llamada que falla en la capa de red sigue teniendo una entrada en el libro. La puerta de enlace del proveedor escribe una segunda fila de auditoría simultáneamente.
Redacción de credenciales en una sola ruta de escritura. El Portero elimina las credenciales antes de escribir en el corpus de entrenamiento de aprendizaje. No inspecciona ni sanea la carga útil de la solicitud saliente en sí misma antes de despachar una llamada externa — esa propiedad más amplia de saneamiento de salida es un objetivo de diseño, no un mecanismo ya implementado.
La respuesta de entrada queda contenida. La respuesta de un modelo externo vuelve al Portero y no se expone directamente a los servicios del Anillo 2 o del Anillo 1.
El enrutamiento de nivel queda auditado. El cliente puede ver en su libro local qué nivel de cómputo gestionó cada solicitud: local (Nivel A), ráfaga GPU (Nivel B) o API externa (Nivel C).
El libro WORM
Cada servicio del Anillo 1 escribe en un libro de Solo Escritura y Múltiple Lectura. El libro no tiene operación de eliminación ni de sobreescritura — estas funciones no existen en el motor de almacenamiento. La modificación es estructuralmente imposible, no prohibida por política.
El libro está basado en tiles y encadenado por hash: cada tile contiene el hash del tile anterior. Cualquier modificación en cualquier tile rompe la cadena de hash y es detectable sin acceder a los sistemas propios de la plataforma. El servicio [[fs-anchor-emitter]] genera puntos de control firmados del libro y los ancla externamente en el registro de transparencia público Sigstore Rekor con una cadencia mensual.
Esta estructura satisface la Regla SEC 17a-4(f) y la preservación de registros electrónicos cualificados de eIDAS por garantía estructural, no por atestación de política que puede modificarse. No existe hoy ninguna certificación SOC 2 ni ISAE 3402; un informe SOC 3 está planificado.
El estándar Diode
El estándar Diode es la topología de seguridad de red fundamental de la flota PointSav. Los comandos fluyen de autoridad (os-orchestration, os-console) a sujeto (archivos Totebox, servicios) y nunca al revés. os-orchestration existe como crate nombrado pero hoy es un marcador de posición — la lógica de agregación del lado de autoridad descrita aquí es un objetivo de diseño, no código en ejecución todavía.
Un archivo Totebox que recibe un comando de os-console no puede iniciar un comando de vuelta a os-console. La lógica de enrutamiento que permitiría esto no existe en la pila de comunicación. Esto elimina la superficie de ataque de movimiento lateral.
Control de acceso basado en capacidades
La plataforma utiliza seguridad basada en capacidades en lugar de listas de control de acceso o control de acceso basado en roles. Un componente de software puede comunicarse con otro solo si tiene un token de capacidad criptográfico concedido explícitamente en el aprovisionamiento. No existe autoridad ambiente.
Un componente comprometido no puede escalar sus propios privilegios. Solo puede hacer lo que permite su conjunto de capacidades, y ese conjunto se fijó en el aprovisionamiento. Autorización basada en máquina extiende este modelo a la autenticación del operador: el emparejamiento criptográfico entre el dispositivo de hardware del operador y el nodo de orquestación es el permiso.
Véase también
- Arquitectura de tres anillos — el modelo de tres anillos y por qué la IA es estructuralmente opcional
- Estándar del diodo — la disciplina de flujo de comandos unidireccional en detalle
- Protocolo Doorman — el servicio de límite de IA Portero y su lógica de enrutamiento
- Seguridad basada en capacidades — el modelo de aislamiento basado en capacidades en la capa del SO
- Diseño del libro de registros WORM — la estructura del libro WORM y sus propiedades de cumplimiento
- Decisiones de arquitectura — las doce decisiones vinculantes, incluidas ADR-07, ADR-10 y ADR-19
- Resumen de adquisición — términos de adquisición y estructura comercial para compradores regulados
Cite this record: /wiki/security-overview — revision fe4f6091, last updated 6 September 2026.