Seguridad
La seguridad, tal como la aplica el código.
Un agente tiene accesos, actúa, se equivoca. NakamaOS lo trata como un empleado de riesgo: solo hace lo que usted autoriza, cada acción queda registrada y lo que sale espera su validación. Estas son las cinco reglas, y lo que las sostiene.
Trabajamos en francés. Si está en España, escríbanos.
Las cinco reglas
-
1
Acceso mínimo
Lo que lee pasa; lo que escribe, envía o publica espera un permiso.
Lo que impideQue un texto leído por el agente — una página, un correo, un ticket — desencadene una escritura o un envío que nadie ha visto pasar. El control de acceso defectuoso sigue siendo la primera categoría de riesgo de las aplicaciones, haya agentes o no.
El detalle técnico
Una herramienta que solo lee — leer un fichero, buscar, hacer una búsqueda web — se ejecuta sin preguntar. La búsqueda web y la lectura de una página pasan, por tanto, sin preguntar: es una vía de salida conocida; cerrarla es un ticket abierto, y la fecha estará en el diario. Cualquier otra herramienta se detiene y espera una respuesta: rechazar, autorizar una vez, para la sesión, o siempre. Ese control está en el código que ejecuta la llamada, no en una frase de la consigna. El permiso se da herramienta por herramienta y vale para todos los agentes: una persona es una ficha de puesto colocada al principio del mensaje, no un juego de derechos. En el navegador, leer la página es libre; abrir una página, hacer clic o escribir pide permiso, porque una página leída puede contener una instrucción. Un comando solo pasa sin preguntar si es simple: programa autorizado, ningún metacarácter, ningún intérprete, ninguna ruta fuera de la carpeta de trabajo. La carpeta de los permisos, las claves y la sesión está cerrada a los agentes, en lectura y en escritura. Permisos distintos por persona serían el siguiente paso; diremos aquí el día en que esté puesto.
Referencias: OWASP Top 10:2025; CWE-284: Improper Access Control; OWASP Top 10 for Agentic Applications
-
2
Revisión
Lo que produce un agente se valida antes de entrar en producción: código, respuesta a un cliente, documento.
Lo que impideQue un defecto introducido por un agente — o una dependencia introducida por un agente — llegue a producción sin que nadie lo haya mirado.
El detalle técnico
Para un agente de código, la salida es una pull request con su informe, validada antes de fusionar: a partir de la rama estable, nada entra sin validación línea a línea. Esta regla está escrita en las instrucciones del repositorio y la sostiene la validación, no el motor. Una respuesta a un cliente, un artículo, un documento pasan por la misma puerta, y lo que se publica lleva el nombre de quien lo redactó y de quien lo validó. Los cambios que tocan la autenticación, los derechos o los datos tienen prioridad en la validación, sea cual sea su tamaño. Una dependencia añadida por un agente se fija a una versión y se justifica en la solicitud: un agente que instala una biblioteca actúa sobre su cadena de suministro.
Referencias: Secure Software Development Framework 1.1 (SP 800-218); SLSA — Supply-chain Levels for Software Artifacts, v1.1; OWASP Top 10:2025
-
3
Registro
Cada acción queda trazada, consultable, copiable tal cual.
Lo que impideQue un incidente se constate sin poder decir qué se tocó, por quién y cuándo — y que haya que creer al agente bajo palabra.
El detalle técnico
Cada conversación se registra evento a evento: los mensajes, las llamadas a herramientas, las solicitudes de permiso y las respuestas. Las misiones y sus fallos van a un registro de actividad, y cada clasificación de sensibilidad a un registro de enrutado. Esos registros los escribe el motor que ejecuta la llamada, no el agente: un agente no cuenta su acción, la sufre. Los rechazos cuentan tanto como los aciertos: un permiso denegado deja rastro, y son esas líneas las que se leen primero. Son ficheros de texto, una línea por evento, legibles y copiables tal cual — no una pantalla que haya que pedirnos.
Referencias: OWASP Top 10:2025; Directiva (UE) 2022/2555 (NIS2); MITRE ATT&CK
-
4
El nivel confidencial
En el nivel confidencial, las llamadas secundarias van a un modelo local; la conversación principal se queda en el modelo elegido.
Lo que impideLa fuga de información sensible por el camino más banal: un documento vertido en un contexto que va a un tercero.
El detalle técnico
El dato se clasifica por su origen — la carpeta, la etiqueta del documento — o por un nivel elegido explícitamente. El enrutamiento lee ese nivel: en el nivel confidencial, las llamadas secundarias — la clasificación, el trabajo delegado a un segundo modelo — van a un modelo que funciona en la máquina. Cada decisión de enrutamiento queda escrita en un registro consultable: para cada turno, el nivel aplicado y la razón. Lo que esta regla no cubre, y preferimos decirlo: la conversación principal sigue el modelo elegido para la instalación, bajo su contrato y con su clave, y el enrutamiento puede desactivarse en los ajustes; el registro muestra entonces que lo está; en Nakama, todavía lo está. El nivel confidencial solo afecta a las llamadas secundarias: la página «Adónde van sus datos» nombra cada flujo.
Referencias: OWASP Top 10 for LLM Applications; Recomendaciones de seguridad para un sistema de IA generativa; Reglamento (UE) 2022/2554 (DORA)
-
5
Validado antes de salir
Lo que envía, publica, paga o fusiona espera una validación. El agente prepara.
Lo que impideQue una cadena de llamadas automáticas produzca un compromiso que nadie ha querido, y que la autoridad de un agente la tome prestada otro.
El detalle técnico
Las acciones que comprometen — enviar, publicar, pagar, responder sobre un contrato — se detienen en el código y esperan a una persona: ese punto de paso está en el motor, no en la consigna. La fusión de una pull request la sostienen la regla escrita en el repositorio y la validación, no el motor. Una persona puede conceder de una vez por todas un permiso a una herramienta concreta — está en su derecho, y queda escrito en un fichero que se puede releer. Lo que sigue siendo imposible es que un agente se lo conceda a sí mismo: el fichero de permisos le está cerrado por el código, porque una sola escritura en él bastaría para tumbar todo lo demás. Una misión programada prepara y no expide; tiene un disparador, un perímetro de herramientas y un plazo al cabo del cual se detiene.
Referencias: Reglamento (UE) 2024/1689 sobre inteligencia artificial; AI Risk Management Framework 1.0 (NIST AI 100-1); CWE-441: Unintended Proxy or Intermediary («Confused Deputy»)
El modelo de amenazas de un agente
Un agente no es un programa más. Tiene accesos: tokens, un buzón, un repositorio. Tiene herramientas que actúan: escribir, enviar, llamar, ejecutar. Tiene una memoria que sobrevive a la tarea. Y decide solo el orden de las operaciones. Es la definición de un empleado, sin el contrato de trabajo ni el criterio.
Lo que implica cabe en una frase: el control se pone en el código, no en la consigna. Al modelo se le puede engañar; el perímetro, en cambio, no negocia.
| Riesgo | En qué se traduce en la práctica | Lo que oponemos |
|---|---|---|
| Inyección de instrucciones | Un texto leído por el agente — ticket, página, correo, archivo — contiene una orden. El agente cambia de objetivo a mitad de tarea. | Toda entrada es un dato, nunca una orden. En el navegador, leer es libre; abrir, hacer clic o escribir pide permiso. Toda acción que escribe o envía se detiene y espera a una persona. |
| Envenenamiento de los datos y de la memoria | Una información falsa entra en la memoria o en la base de conocimiento, y se repite en cada tarea siguiente. | Memoria con escritura controlada, fuentes fechadas y atribuidas, caducidad, validación humana de lo que sirve de referencia. |
| Fuga por la herramienta | Una herramienta legítima copia un extracto sensible donde no debería: un registro, un ticket, un mensaje, un contexto enviado fuera. | Clasificación en el origen; en el nivel confidencial, las llamadas secundarias en un modelo local; registro del enrutamiento; ningún secreto en el contexto del modelo. |
| Confusión de delegado | Un agente ejecuta para un solicitante una acción que ese solicitante no tenía derecho a hacer — porque el agente sí lo tiene. | Los permisos son los que la persona ha dado, herramienta por herramienta, y ningún agente puede concedérselos. En modo respuesta directa, un agente no puede lanzar otro: el código rechaza la llamada. |
| Salida del perímetro | Una cadena de llamadas que empieza dentro del perímetro termina fuera: un envío, una compra, una escritura no previstos. | Permiso por defecto sobre todo lo que escribe o envía; para una misión, un juego de herramientas reducido, un plazo de 8 minutos por defecto y ningún permiso que pueda obtener; validación sobre lo que compromete. |
| Cadena de suministro | Una dependencia, un modelo o un servidor de herramientas de terceros cambia bajo los pies del agente. | Versiones fijadas, procedencia verificada de los artefactos, todo añadido pasa por una solicitud validada, ninguna instalación en tiempo de ejecución. |
| Acción irreversible sin humano | Un pago enviado, un código fusionado, un mensaje publicado que nadie ha validado. | Punto de paso humano en el código para lo que envía, publica o paga; para la fusión, la regla escrita en el repositorio y la validación; fichero de permisos cerrado a los agentes, registro de cada conversación. |
Leer el análisis completo
Lo que le ocurre no tiene nada de exótico. Lee un ticket, una página, un correo, un archivo — y ese texto contiene una instrucción escrita para él. Llama a una herramienta que hace algo más de lo que anuncia su nombre. Encadena diez llamadas, y la décima sale del perímetro que las nueve primeras respetaban. Ninguna de estas tres situaciones supone un atacante sofisticado. Basta con escribir en un sitio que el agente lea.
De ahí la primera consecuencia: una consigna no es un control. El modelo recibe la instrucción del sistema y el dato que lee por el mismo canal, texto. Todo lo que se apoya en «el agente tiene instrucciones de no…» es una política de seguridad escrita en el campo más fácil de influir. Si una prohibición importa, la aplica el código que ejecuta la llamada, fuera del modelo.
El segundo pliegue es la identidad. Un agente actúa por alguien, con derechos que no son los de ese alguien. En cuanto un agente llama a otro, la pregunta pasa a ser: ¿de quién vienen los derechos de la llamada? La respuesta debe ser la misma en todas partes: del solicitante de origen. Es el caso clásico del delegado confuso, y no se vuelve nuevo porque haya un modelo en medio.
El tercero es la memoria. Lo que un agente retiene le influye mucho después de la tarea en la que lo leyó. Un dato falso u hostil escrito una vez se repite en cada tarea siguiente, sin que salte ninguna alerta. Por eso tratamos la memoria como una base de datos: quién escribe, qué está fechado, qué caduca, qué se revisa.
Lo que nunca hacemos
- Nombrar a un cliente, pegar código de un cliente, publicar un dato personal.
- Publicar cualquier cosa que ayude a un atacante: ni modo operativo, ni vulnerabilidad sin corregir, ni detalle de arquitectura explotable.
- Dejar que un agente envíe, publique, pague o fusione sin validación.
- Dejar que un agente lea o modifique sus propios permisos, o poner un secreto en claro en su contexto.
- Publicar una cifra sin su fuente, o callar un incidente constatado.
En su empresa: instalado, configurado, verificado cada mes
La versión instalada en su empresa es NakamaOS completo, probado cada día en Nakama, configurado por un especialista en seguridad aplicativa para que los agentes solo hagan lo que usted autoriza, y verificado cada mes.
Cada mes: la versión estable, las pruebas repetidas en su versión, la configuración controlada — catálogo de herramientas, autorizaciones permanentes, conectores, cifrado del disco —, el diff de las consignas y las misiones. El boletín lo preparan los agentes y se valida; sigue siendo suyo.
Instalamos en una empresa a la vez, por orden de la lista de espera.
Cada componente de NakamaOS se fija y se verifica en cada versión. Si se publica una vulnerabilidad, una consigna de corte sale en un día hábil, y la corrección nunca se factura aparte.
Tres preguntas de un CISO
¿Cómo impiden que un agente saque nuestros datos?
Con tres barreras, en este orden. El dato se clasifica por su origen, así que el agente no decide él mismo su nivel. El enrutamiento lee ese nivel: en el nivel confidencial, las llamadas secundarias van a un modelo que funciona en la máquina; la conversación principal se queda en el modelo elegido, bajo su contrato y con su clave. Y todo lo que escribe o envía pide un permiso, que un agente no puede concederse. Cada decisión de enrutamiento queda escrita en un registro, lo que permite verificar después, línea a línea, qué llamada fue adónde. La respuesta honesta cabe en una frase: el nivel confidencial solo afecta a las llamadas secundarias, y la página «Adónde van sus datos» nombra cada flujo y cada subcontratista.
¿Qué pasa cuando un agente se equivoca?
Se equivoca, está previsto. Lo que produce no es producción: es una propuesta — una pull request, un borrador, un ticket cualificado. El error se atrapa en la validación, y la validación es una persona, no un segundo agente. Si pasa de todos modos, el registro dice qué se tocó, cuándo y con qué herramienta, lo que reduce el perímetro de la corrección a minutos en lugar de días. El informe del mes cuenta lo que se rechazó en la validación, cuando se cuenta (pull requests rechazadas), y dice por qué.
¿Qué nos dan para nuestra propia auditoría?
Los registros primero: cada conversación, evento a evento, con marca de tiempo, escrita por el motor y no por el agente, entregada en forma de ficheros que su auditor relee con sus propias herramientas. Después, el fichero de permisos tal como se aplica realmente, herramienta por herramienta, y la traza de los enrutamientos, que muestra qué llamada secundaria fue a qué modelo. Después, la cadena de entrega: quién propuso, quién validó, quién fusionó, para cada cambio. Por último, el expediente de instalación, el boletín del mes, y la correspondencia entre nuestras reglas y los marcos que usa su auditor. No entregamos un certificado; entregamos con qué verificar.
Señalar una vulnerabilidad
Una vulnerabilidad en NakamaOS, en este sitio o en nuestro servicio en línea de ciberseguridad se señala a security@nakamaos.ai; la dirección está en /.well-known/security.txt. Una respuesta escrita, preparada por nuestros agentes y validada; para una instalación en un cliente, una consigna de corte en un día hábil.
Lo que daría un modo operativo a un atacante nunca se publica: una vulnerabilidad se describe por su clase, una vez corregida, con la fecha de la corrección.
Las referencias
Los marcos en los que se apoyan estas reglas, y para qué sirve cada uno aquí. Los enlaces van a sus autores, no a nosotros.
- 1
OWASP Top 10:2025
OWASP Foundation, 2025
La lista de referencia de los riesgos de las aplicaciones: el control de acceso sigue siendo el primero, y la cadena de suministro entra en el tercer puesto.
- 2
OWASP Top 10 for LLM Applications
OWASP Gen AI Security Project, 2026
La taxonomía de los riesgos propios de las aplicaciones con modelos de lenguaje: inyección de instrucciones, divulgación de información sensible, envenenamiento.
- 3
OWASP Top 10 for Agentic Applications
OWASP Gen AI Security Project, 2026
El marco propio de los agentes autónomos: planificación, uso de herramientas, identidad, memoria, comunicación entre agentes.
- 4
MITRE ATT&CK
MITRE, actualizado
La rejilla con la que alineamos lo que un registro debe permitir detectar y contar después de un incidente.
- 5
MITRE ATLAS
MITRE, actualizado
El equivalente de ATT&CK para los sistemas de IA: las técnicas realmente observadas contra modelos y sus cadenas de herramientas.
- 6
AI Risk Management Framework 1.0 (NIST AI 100-1)
NIST, 2023
El marco de gestión del riesgo de IA al que pertenece nuestro punto de paso humano.
- 7
Secure Software Development Framework 1.1 (SP 800-218)
NIST, 2022
Las prácticas de desarrollo seguro a las que se vincula la revisión obligatoria antes de la puesta en producción.
- 8
CWE-284: Improper Access Control
MITRE, actualizado
La designación precisa del defecto que la regla «acceso mínimo» busca hacer imposible.
- 9
CWE-1427: Improper Neutralization of Input Used for LLM Prompting
MITRE, actualizado
La formulación normalizada de la inyección de instrucciones, adscrita a la familia de las inyecciones y no a una curiosidad de la IA.
- 10
CWE-441: Unintended Proxy or Intermediary («Confused Deputy»)
MITRE, actualizado
El nombre del problema de delegación que reaparece en cuanto un agente llama a otro.
- 11
SLSA — Supply-chain Levels for Software Artifacts, v1.1
OpenSSF, 2025
Los niveles de procedencia con los que se mide que un artefacto venga realmente de la cadena anunciada.
- 12
Reglamento (UE) 2024/1689 sobre inteligencia artificial
Unión Europea, 2024
El texto que fundamenta la obligación de supervisión humana y la clasificación de los usos de alto riesgo.
- 13
Reglamento (UE) 2024/2847 (Cyber Resilience Act)
Unión Europea, 2024
Los requisitos de seguridad del producto y de gestión de vulnerabilidades que se aplicarán al software que entregamos.
- 14
Directiva (UE) 2022/2555 (NIS2)
Unión Europea, 2022
Las obligaciones de gestión del riesgo y de notificación de incidentes que el registro debe permitir cumplir.
- 15
Reglamento (UE) 2022/2554 (DORA)
Unión Europea, 2022
El marco que nos oponen nuestros clientes del sector financiero sobre el riesgo de los proveedores informáticos externos.
- 16
ISO/IEC 27001:2022 — Sistemas de gestión de la seguridad de la información
ISO / IEC, 2022
La rejilla de lectura de un auditor sobre el registro, la gestión de accesos y la prueba documental.
- 17
ISO/IEC 42001:2023 — Sistema de gestión de la inteligencia artificial
ISO / IEC, 2023
La norma con la que comparamos nuestra organización, sin reivindicarla.
- 18
Recomendaciones de seguridad para un sistema de IA generativa
ANSSI, 2024
La referencia francesa sobre la compartimentación de los entornos de inferencia y la seguridad de una arquitectura de IA generativa.
¿Pasarían sus agentes este examen?
La auditoría de IA y agentes empieza por ahí: qué accesos tienen hoy sus herramientas de IA, quién valida lo que producen, y qué pasa cuando se equivocan. Una respuesta escrita, preparada por nuestros agentes y validada.