Seguridad IA por Arquitectura | RAG Air-Gapped en Rust | Lexiane
Seguridad IA en la arquitectura: memoria segura Rust, SHA-256, OWASP LLM Top 10. RAG on-premise sin superficie de ataque explotable.
La seguridad de un sistema IA en producción no se reduce a una lista de medidas aplicadas tras el despliegue. Es la consecuencia de un conjunto de decisiones de arquitectura tomadas en origen — sobre el lenguaje, sobre los límites del sistema, sobre la gestión de memoria, sobre las superficies de exposición. Estas decisiones determinan qué puede alcanzar un atacante, qué puede filtrar el sistema, y qué puede verificar un auditor.
Lexiane ha sido concebido con esta lógica: cada propiedad de seguridad está garantizada mecánicamente por el compilador, verificada por un test automatizado en integración continua, o resulta físicamente imposible por la arquitectura. No hay propiedades de seguridad que dependan únicamente de convenciones de desarrollo o de la vigilancia individual de los equipos.
El panorama de amenazas específicas a los sistemas RAG
Los sistemas RAG introducen vectores de ataque que no existen en los sistemas software tradicionales. OWASP publicó en 2023, actualizado en 2025, un referencial de las diez categorías de riesgos prioritarios para aplicaciones LLM — el OWASP LLM Top 10. Entre los más críticos para un sistema de procesamiento documental:
LLM01 — Inyección de prompt. Un atacante inserta en una petición instrucciones destinadas a eludir las políticas del sistema, a exfiltrar datos, o a producir contenidos no conformes. En un sistema RAG expuesto a usuarios no totalmente de confianza — agentes externos, usuarios internos con derechos limitados —, este vector es el más frecuentemente explotado.
LLM06 — Divulgación de información sensible. El modelo de lenguaje puede producir respuestas que incorporen datos presentes en el contexto recuperado, incluyendo datos personales o información confidencial que el usuario solicitante no debería ver. En un corpus multiusuario, la ausencia de control de acceso a nivel de recuperación crea este riesgo de forma sistemática.
LLM02 — Gestión no segura de las salidas. Las salidas del LLM se utilizan sin validación suficiente — en interfaces web (XSS), en llamadas al sistema, o se retransmiten a otros sistemas sin filtrado. Las salidas de un LLM son datos no fiables y deben tratarse como tales.
LLM09 — Exceso de confianza en las salidas del modelo. Un sistema que acepta y transmite las respuestas del LLM sin verificar su anclaje en las fuentes documentales abre la puerta a la desinformación operacional — respuestas falsas presentadas con la misma apariencia de fiabilidad que las correctas.
A estas amenazas específicas de los LLM se suman las amenazas clásicas amplificadas por la complejidad de las pilas IA: vulnerabilidades de memoria introducidas por las dependencias C/C++ subyacentes a los frameworks Python, cadena de suministro de software, superficie de ataque extendida por los procesos secundarios y las llamadas de red.
Lexiane aborda cada una de estas categorías — mediante mecanismos distintos, verificables y documentados.
Seguridad de memoria: lo que Rust excluye estructuralmente
La clase de vulnerabilidades que Python y C++ no pueden eliminar
Las vulnerabilidades relacionadas con la gestión de memoria — buffer overflow, use-after-free, double free, puntero nulo desreferenciado, race condition de memoria — constituyen históricamente la mayoría de las vulnerabilidades de seguridad críticas en los sistemas software. Google ha documentado en el proyecto Android que la adopción de Rust como lenguaje de sistema ha reducido en un 68 % las vulnerabilidades relacionadas con la memoria en cinco años. Microsoft ha estimado que el 70 % de los CVE críticos en sus productos tienen su origen en errores de gestión de memoria.
Los frameworks RAG Python dependen de bibliotecas C y C++ para sus operaciones intensivas — PyTorch, NumPy, los parsers nativos, las bibliotecas de compresión. Estas dependencias heredan todas las clases de vulnerabilidades de los lenguajes no memory-safe. Una vulnerabilidad en una dependencia transitiva — invisible en el código Python de superficie — puede comprometer el sistema completo.
Lo que garantiza el compilador Rust
Rust elimina por construcción, a nivel del compilador, las categorías enteras de bugs de memoria mencionadas anteriormente:
- Ausencia de punteros nulos desreferenciados — los valores opcionales se expresan mediante
Option<T>, cuyo tratamiento exhaustivo es exigido por el compilador. - Ausencia de use-after-free — el sistema de propiedad de Rust garantiza que un recurso liberado no puede volver a ser accedido. Esta propiedad se verifica estáticamente, sin análisis dinámico.
- Ausencia de data races — el sistema de tipos de Rust garantiza la exclusión mutua entre accesos concurrentes mutables. Una data race es un error de compilación, no una condición de carrera descubierta en producción.
- Ausencia de overflow aritmético no controlado — en modo debug, los overflows se detectan y generan un panic. En modo release, el comportamiento está definido y es configurable — nunca un comportamiento indefinido explotable.
#![forbid(unsafe_code)] en el perímetro certificado
Rust permite escribir código “unsafe” — bloques donde las garantías del compilador quedan suspendidas, necesarios para interactuar con interfaces C o con el sistema. Esta funcionalidad es una trampa: en una base de código sin disciplina, puede reintroducir las vulnerabilidades que Rust pretende eliminar.
El núcleo certificado de Lexiane (vectrant-core) porta la directiva #![forbid(unsafe_code)]. Esta directiva no es una convención — la aplica el compilador. Ningún desarrollador puede introducir un bloque unsafe en el perímetro certificado, ni siquiera inadvertidamente, ni siquiera bajo presión de plazo. El compilador rechaza el código antes de que exista el binario.
En diciembre de 2023, la CISA (Cybersecurity and Infrastructure Security Agency) publicó “The Case for Memory Safe Roadmaps”, recomendando explícitamente la adopción de lenguajes memory-safe — incluido Rust — para los sistemas críticos. El Departamento de Defensa estadounidense y la Casa Blanca han emitido recomendaciones convergentes. Lexiane satisface estas recomendaciones por arquitectura.
Reducción de la superficie de ataque
Un binario, no un ecosistema
Cada dependencia externa es un vector de ataque potencial. Un sistema Python en producción expone una superficie de ataque extensa: el intérprete Python, los paquetes instalados vía pip, las bibliotecas del sistema compartidas cargadas dinámicamente, los procesos secundarios (servidor Ollama, API Redis, worker Celery). Un atacante que comprometa una dependencia — por una vulnerabilidad zero-day o un ataque a la cadena de suministro — puede comprometer el sistema completo.
Lexiane se compila en un binario estático autónomo. No carga bibliotecas compartidas en tiempo de ejecución. No resuelve dependencias al arranque. No descarga código externo durante su ejecución. La superficie de ataque está delimitada por el propio binario — un perímetro fijo, auditable, reproducible.
Seguridad de la cadena de suministro
Los ataques a la cadena de suministro de software — comprometer un paquete open-source para inyectar código malicioso en las aplicaciones que dependen de él — están en constante aumento. El índice PyPI ha sufrido numerosos incidentes de este tipo en los últimos años.
Lexiane aborda este riesgo mediante dos mecanismos complementarios:
Cero dependencias de proveedor en el núcleo certificado. El módulo vectrant-core — el núcleo del sistema — no contiene ninguna dependencia hacia un editor tercero. Esta restricción se verifica mediante un test automatizado que falla en la compilación si se introduce una dependencia externa. La regresión es imposible sin ser detectada inmediatamente.
Compilación con Ferrocene. Ferrocene es la versión cualificada del compilador Rust desarrollada por Ferrous Systems — cualificada ISO 26262 ASIL D e IEC 61508 SIL 4. Compilar Lexiane con Ferrocene permite establecer una cadena de confianza completa para la certificación: del código fuente, al compilador, hasta el binario desplegado. Un atacante que quisiera introducir código malicioso tendría que comprometer el compilador mismo — cuya cualificación impone una trazabilidad rigurosa.
Ausencia de procesos secundarios
Los frameworks RAG Rust alternativos — Swiftide, Rig — requieren un servidor de inferencia externo para la generación de texto: un proceso Ollama, un endpoint OpenAI, o un servidor vLLM. Este servidor secundario es un componente de red independiente: su superficie de ataque se suma a la del framework RAG, y las comunicaciones entre ambos componentes crean un canal potencialmente interceptable.
Lexiane integra la inferencia LLM (Mistral.rs) y los embeddings (Candle) en el mismo binario. En configuración local, no hay proceso secundario, no hay comunicación de red interna, no hay canal entre procesos que asegurar.
Seguridad específica de los sistemas IA
Defensa contra la inyección de prompt
El puerto InputGuardrail de Lexiane implementa una capa de validación de las peticiones entrantes antes de que alcancen el pipeline de recuperación o el modelo de lenguaje. Los patrones de inyección de prompt — instrucciones ocultas en la petición, intentos de eludir las políticas del sistema, escalada de privilegios por manipulación del prompt — se detectan y bloquean en esta etapa.
Este mecanismo opera en origen del pipeline: una petición bloqueada por el InputGuardrail no genera ningún embedding, no desencadena ninguna recuperación, y no solicita ningún LLM. No hay coste computacional asociado a las peticiones maliciosas bloqueadas, y no hay riesgo de que su contenido influya en el comportamiento del modelo.
Control de las salidas del modelo
El puerto OutputGuardrail valida la respuesta producida antes de transmitirla al usuario. Se abordan tres categorías de riesgos:
Filtración de datos sensibles. El LLM puede incorporar en su respuesta datos presentes en el contexto recuperado — incluyendo datos personales que el usuario no debería ver, o información confidencial procedente de documentos accesibles a través del mecanismo de recuperación. El OutputGuardrail detecta estas filtraciones y las bloquea antes de la transmisión.
Contenido tóxico o no conforme. Las respuestas que violan las políticas de contenido definidas por la organización — contenido discriminatorio, instrucciones peligrosas, contenido fuera de perímetro — son interceptadas antes de llegar al usuario.
Respuestas no ancladas. El FaithfulnessChecker verifica que la respuesta producida esté efectivamente respaldada por las fuentes recuperadas. Una respuesta que extrapola más allá del contexto proporcionado — es decir, una alucinación — se detecta y puede desencadenar una abstención o una señalización.
Control de acceso a nivel documental
El puerto AccessControl implementa un filtrado de los resultados de recuperación basado en los derechos del usuario solicitante. Este filtrado opera antes de la generación: los documentos a los que el usuario no tiene acceso no se transmiten al LLM como contexto.
Esta posición en el pipeline es crítica. Un control de acceso que se aplica únicamente en la interfaz — ocultando ciertas respuestas en la UI — deja que datos sensibles atraviesen el modelo de lenguaje. Un LLM que ha recibido un documento confidencial en su contexto puede revelar su contenido de forma indirecta, aunque la respuesta final parezca no hacer referencia a él. Lexiane corta este vector en el origen.
Se soportan dos modelos de control de acceso:
- RBAC (Control de Acceso Basado en Roles) — los derechos de acceso se definen por el rol del usuario en la organización.
- ABAC (Control de Acceso Basado en Atributos) — los derechos de acceso se definen por atributos contextuales: clasificación del documento, departamento propietario, nivel de sensibilidad, fecha de publicación.
La puerta de relevancia como defensa contra la desinformación operacional
La RelevanceGateStage evalúa la puntuación de confianza global del contexto recuperado antes de la generación. Por debajo del umbral configurado, el sistema se abstiene de generar una respuesta y lo señala explícitamente.
Este comportamiento de abstención es una medida de seguridad operacional: en un entorno de decisión — médico, jurídico, industrial, de inteligencia —, una respuesta mal fundamentada presentada con la misma apariencia que una respuesta fiable es más peligrosa que la ausencia de respuesta. Lexiane prefiere la transparencia sobre la insuficiencia a la producción de una respuesta no respaldada.
Protección de datos
El filtro PII como barrera de primera línea
El filtro PII opera en origen del pipeline de procesamiento documental completo — antes de cualquier embedding, antes de cualquier indexación, antes de cualquier llamada al LLM. Los datos personales detectados en los documentos ingeridos se tratan según políticas configurables: enmascaramiento tipado, supresión, hash criptográfico.
El audit trail registra, para cada documento, las categorías de datos personales detectadas y las políticas aplicadas. Este registro constituye la prueba técnica del tratamiento conforme — explotable en el marco de un control RGPD.
La residencia de datos como garantía física
En configuración air-gapped, los datos no salen del perímetro porque la arquitectura lo hace físicamente imposible — no porque un contrato lo prohíba. El binario no dispone de ninguna interfaz de red activa hacia el exterior. No hay flujos que vigilar, no hay compromisos contractuales que auditar: la propiedad es mecánica.
Esta distinción — garantía arquitectural versus garantía contractual — es fundamental para las organizaciones cuyos datos están sujetos a una exigencia de localización estricta: defensa, inteligencia, salud, sector público sometido a referenciales de cloud soberano.
Auditoría y análisis forense
Una cadena SHA-256 inviolable
Cada acción del pipeline se registra en una cadena de auditoría criptográfica: cada entrada está firmada por el hash SHA-256 de la anterior. Cualquier modificación retrospectiva de un registro — supresión de un acceso, alteración de una marca de tiempo, modificación de una política aplicada — rompe la cadena y es matemáticamente detectable.
En caso de incidente de seguridad, esta cadena permite una reconstrucción forense completa: quién accedió a qué, en qué momento, con qué resultado, según qué política de filtrado. La investigación no depende de la disponibilidad de logs aplicativos que podrían haber sido alterados o suprimidos. La cadena es la prueba.
Eventos registrados:
| Evento | Datos registrados |
|---|---|
| Documento ingerido | Identificador, hash del contenido, marca de tiempo, colección |
| Datos personales detectados | Categorías, política aplicada, posición en el documento |
| Petición de usuario | Identificador de usuario, texto de la petición, marca de tiempo |
| Documentos recuperados | Identificadores, puntuaciones de relevancia, acceso concedido o denegado |
| Respuesta producida | Hash de la respuesta, fuentes citadas, puntuación de fidelidad |
| Guardrail activado | Tipo de guardrail, motivo del bloqueo, identificador de usuario |
Ausencia de canales de fuga a través de los registros
Un vector de filtración de datos habitualmente descuidado en los sistemas IA es el registro de aplicación: datos sensibles presentes en las peticiones o respuestas que aparecen en claro en los logs del sistema. Lexiane prohíbe por convención de desarrollo el uso de println!() en todo el código de producción. Toda emisión de logs pasa por el framework tracing, con niveles de verbosidad controlables y filtros de estructuración. Esta propiedad se verifica en integración continua.
Lo que su equipo de seguridad puede verificar
La seguridad de Lexiane no se basa en declaraciones. Cada propiedad es verificable en el código fuente, en los artefactos de build, o demostrable por inspección del binario.
| Propiedad de seguridad | Mecanismo de verificación |
|---|---|
| Ausencia de código unsafe en el núcleo | #![forbid(unsafe_code)] — inspección del código fuente |
Ausencia de unwrap() / panic!() en producción | Test automatizado en CI — resultado verificable en la suite de tests |
| Cero dependencias de proveedor en el núcleo | Test automatizado en la compilación — vectrant-core/Cargo.toml inspeccionable |
| Integridad del audit trail | Propiedad criptográfica SHA-256 — verificable algorítmicamente |
| Filtrado PII antes de la indexación | Posición en el pipeline — inspeccionable en el orden de las etapas de ingesta |
| Control de acceso antes de la generación | Posición del puerto AccessControl en el pipeline — inspeccionable en el ensamblado |
Ausencia de println!() | Verificable por grep en todo el código fuente |
| Validación estática de la configuración | Propiedad del ensamblador — inspeccionable en los tests de ensamblado |
| Ninguna llamada de red en modo air-gapped | Inspeccionable en la configuración de los adaptadores activos |
Preguntas frecuentes de los equipos de seguridad y CISOs
¿Han realizado un pentest sobre Lexiane? Los resultados de una auditoría de seguridad externa están disponibles bajo petición en el marco de una conversación cualificada. Las propiedades mecánicas descritas en este documento — ausencia de código unsafe, superficie de ataque reducida al binario, cadena de auditoría inviolable — son verificables de forma independiente por su equipo de seguridad o por un proveedor de su elección.
¿Es Lexiane conforme al referencial OWASP LLM Top 10?
La arquitectura de Lexiane aborda directamente las categorías LLM01 (inyección de prompt vía InputGuardrail), LLM02 (validación de salidas vía OutputGuardrail y FaithfulnessChecker), LLM06 (filtrado PII y AccessControl antes de la generación), y LLM09 (puerta de relevancia y abstención). La evaluación completa de conformidad OWASP para su despliegue específico debe realizarse según su contexto.
¿Cómo gestionar los secretos — claves API, tokens — en la configuración?
Lexiane sigue la convención api_key_env: los campos de configuración referencian el nombre de la variable de entorno que contiene la clave, nunca la clave en sí. Los secretos no transitan por los archivos de configuración TOML. Se inyectan mediante variables de entorno al arranque — compatibles con los gestores de secretos estándar (Vault, Kubernetes Secrets, AWS Secrets Manager).
¿Cuál es la política de gestión de dependencias y CVEs?
Las dependencias del proyecto se someten a una auditoría de seguridad automatizada (cargo audit) en integración continua. Los CVE detectados en las dependencias desencadenan una alerta inmediata. El número de dependencias activas se mantiene tan bajo como sea posible — cada dependencia añadida es una decisión deliberada, no un efecto secundario.
¿Se puede desplegar Lexiane en un entorno con un firewall de aplicación (WAF)? Sí. La API REST de Lexiane es una API HTTP estándar, compatible con todos los WAF del mercado. En configuración air-gapped, la cuestión del WAF se aplica únicamente a los flujos internos — Lexiane mismo no inicia ningún flujo de red saliente.
¿Cómo aislar los derechos de acceso entre varios equipos que usan el mismo despliegue de Lexiane?
El puerto AccessControl permite una segmentación de derechos a nivel documental. Los documentos ingeridos pueden etiquetarse con atributos de clasificación (RBAC o ABAC), y los derechos de acceso se verifican en la recuperación — antes de que el contexto se transmita al modelo. Varios equipos pueden compartir una misma infraestructura sin que sus corpus documentales se mezclen en las respuestas.
Iniciar la conversación sobre su modelo de amenaza.
La seguridad de un sistema IA se construye sobre un análisis de amenazas propio de su contexto: su sector, su modelo de acceso de usuarios, su infraestructura de despliegue, y sus exigencias regulatorias. No proponemos una evaluación genérica.
Proponemos un intercambio estructurado con un equipo que conoce los vectores de ataque específicos de los sistemas RAG, las restricciones de los entornos regulados, y las pruebas que la arquitectura de Lexiane permite proporcionar a sus equipos de seguridad.
Lo que puede esperar:
- Una respuesta en 48h hábiles
- Un interlocutor técnico que conoce el OWASP LLM Top 10, las restricciones de los entornos clasificados, y los requisitos de certificación
- Una cartografía honesta de lo que cubre la arquitectura de Lexiane — y de lo que queda bajo su responsabilidad
→ Contactar
Sin compromiso comercial. Una conversación de seguridad.
Referencias citadas en este documento: — OWASP LLM Top 10, versión 1.1 (2023), actualización 2025 — owasp.org/www-project-top-10-for-large-language-model-applications — CISA, “The Case for Memory Safe Roadmaps”, diciembre de 2023 — Google, “Memory Safe Languages in Android 13”, Android Security Blog — NIST AI Risk Management Framework 1.0, enero de 2023 — Reglamento (UE) 2016/679 (RGPD)
Solicitar acceso al Core Auditable
Regístrese para ser notificado de la apertura del programa de auditoría de nuestro Core. De conformidad con nuestra política de privacidad, su dirección de correo electrónico profesional se utilizará exclusivamente para esta comunicación técnica, sin ningún uso de marketing posterior. Acceso distribuido a través de registro privado seguro.
Contáctenos