Confianza cero para agentes de IA: políticas como código y procedencia

2026-09-01 · Ingeniería ·

El cuestionario que no se responde con diapositivas

En algún momento un prospecto, un auditor o el equipo de seguridad de un cliente empresarial te envía el cuestionario. No «¿tu código es bueno?» — preguntas como: quién puede leer nuestros datos, qué sistemas tocan nuestro repositorio, qué impide que un worker automatizado los exfiltre, y si puedes demostrar todo esto con algo más que tu palabra. Si los agentes de IA están escribiendo porciones significativas de tu base de código, la versión honesta de esa prueba se vuelve más difícil, porque ahora también tienes que responder por actores no humanos que corren en tu propia red, que tienen credenciales, y que producen artefactos que vas a enviar a producción. «Todo está en nuestra LAN» no es una respuesta. Una LAN otorga conectividad, no autoridad — y la diferencia entre esas dos cosas es exactamente lo que una revisión de seguridad existe para sondear.

Este artículo recorre cómo la sección de gobernanza del libro blanco de Koinessa responde a ese cuestionario: identidad de confianza cero aplicada a una LAN llena de agentes, política evaluada como código versionado en lugar de texto de prompt, y una cadena de procedencia para artefactos producidos por agentes construida a partir de los mismos estándares que cita la lista de verificación de tu revisor.

Lo que las secciones 8.1 a 8.3 realmente establecen

Tres afirmaciones, tres límites de evidencia distintos — y el libro blanco etiqueta cada una con su estado real.

La primera es la procedencia y la gobernanza, con estado En vivo: cada acción con consecuencias lleva una cadena consultable desde la intención hasta el resultado — requisito, elemento de trabajo, principal, sesión de agente, modelo, archivos, commit, pipeline, evidencia, decisión de política, aprobación, despliegue, resultado operativo. Un libro mayor temporal responde «qué creíamos cuando esto se autorizó» como una consulta, no como un ejercicio de reconstrucción después de un incidente.

La segunda es la identidad y la política, también con estado En vivo, y es el núcleo de confianza cero. La identidad se separa como la separan los sistemas IAM maduros: identidad del principal (quién opera), identidad de tenant y de proyecto (de quién son los recursos en alcance), identidad de agente y de sesión (qué worker está actuando), autoridad de trabajo (qué tarea acotada posee), autoridad de capacidad (qué clases de acción puede realizar), identidad de proveedor, e identidad de evidencia. Los permisos se evalúan contra una política versionada con decisiones persistidas en lugar de texto de prompt. Las cuotas del gateway y los alcances de escritura se asignan por principal y por tabla, los libros mayores de auditoría y de eventos estampan el principal actuante en cada registro, y el gateway puede exigir un principal de forma directa.

La tercera es el diseño multi-tenant, y aquí el libro blanco es deliberadamente cauteloso. La tenencia de datos tiene estado En curso: de 346 tablas base, 333 llevan project_id y 13 tablas compartidas o de infraestructura no, y el libro blanco declina explícitamente inferir un aislamiento universal de tenants a partir de una propiedad parcial del esquema — TEN-001 está en 78% y MTC-001 en 81% en revisión, con el endurecimiento de principales externos todavía incompleto. La tenencia concurrente de operadores tiene estado En vivo: dos operadores en dos equipos sobre una sola LAN dirigen habitualmente sus propios enjambres de agentes contra el mismo repositorio a través de un solo gateway, hecho seguro mediante reclamos de archivo, arriendos de elementos de trabajo y fencing tokens. La portabilidad del plano de inferencia está en vivo donde hay comprobante, con una neutralidad más amplia como objetivo de diseño declarado, no como propiedad demostrada.

Esa honestidad sobre el estado es en sí misma parte de la respuesta a un revisor de seguridad: el sistema reporta lo que está verificado, lo que está en curso y lo que está bloqueado por un gate — la misma disciplina de resultados de seis estados que el marco de garantía EGAF aplica al código, aplicada a sus propias afirmaciones.

La doctrina: la presencia en la red no es autoridad

El fundamento intelectual aquí tiene cincuenta años. «The Protection of Information in Computer Systems», de Saltzer y Schroeder (Proceedings of the IEEE 63(9), 1975), estableció los principios de diseño que todavía sostienen el control de acceso serio — mínimo privilegio, valores por defecto a prueba de fallos, mediación completa de cada acceso, economía de mecanismo, diseño abierto. Dos de ellos hacen el trabajo pesado específicamente para la infraestructura de agentes. El mínimo privilegio dice que un worker recibe exactamente la autoridad que su tarea acotada requiere y nada más. La mediación completa dice que cada acceso se verifica contra la autoridad cada vez — no existe eso de «se conectó correctamente una vez, así que está bien».

El SP 800-207 del NIST, «Zero Trust Architecture» (2020), pone en operación la misma postura para las redes modernas: no se otorga confianza implícita a ningún activo o cuenta según su ubicación física o de red, y la autenticación más la autorización son funciones discretas que se realizan antes de cada sesión hacia un recurso. Escrito para empresas que digieren el trabajo remoto y los activos en la nube, se lee como una especificación para una LAN de agentes. Tus agentes de codificación son trabajadores remotos que resultan ser procesos. Se mueven entre máquinas, tienen credenciales de API, y la red en la que están no demuestra nada sobre lo que se les debería permitir hacer.

El libro blanco aplica esto literalmente: una conexión LAN no otorga confianza implícita, y las propias lecturas están identificadas por bearer token en cualquier enlace que no sea loopback. Un worker puede ser capaz de alcanzar un recurso sin tener la autoridad de política para usarlo, y ambos hechos se verifican de forma independiente. Para un fundador cuyo mayor temor es que el código propietario o los datos de negocio se filtren a un servicio externo innecesario, esta es la versión mecánica de la promesa: incluso dentro de tu propio perímetro, en tu propio hardware, cada lectura y cada escritura lleva una identidad y es mediada.

Política como código, no como texto de prompt

La objeción natural es que el comportamiento de los agentes se gobierna mediante instrucciones — prompts de sistema, archivos de reglas, AGENTS.md. Esas son necesarias, pero no son autorización. Un prompt es un consejo para un sistema probabilístico; una decisión de política es una comprobación determinista con un resultado registrado. Open Policy Agent (openpolicyagent.org) es la implementación de referencia del patrón general: política expresada como código versionado y comprobable, evaluada fuera de aquello que se gobierna, con las decisiones registradas. El libro blanco cita a OPA como una fuente del patrón y es explícito en que Koinessa no afirma incorporarlo — el préstamo es arquitectónico, no literal.

La aplicación luce así. Las sesiones llevan un principal. Las comprobaciones de permisos se evalúan contra una política versionada, y las propias decisiones se persisten — así que «por qué se permitió esto» es una consulta, no un argumento. Las cuotas y los alcances de escritura se asignan por principal y por tabla en el gateway, que es el único punto de estrangulamiento que cruza toda escritura externa. Los libros mayores de auditoría y de eventos estampan el principal actuante, de modo que la cadena de custodia pasa a través de las operaciones, no alrededor de ellas.

Esto es lo que hace segura la subida de la autonomía por niveles de riesgo. Cuando la autoridad de capacidad es un hecho separado y verificable respecto de la identidad de sesión, puedes concederle a un agente el peldaño de «commit» sin el peldaño de «push», ampliar esa concesión por clase de tarea a partir de un historial verificado, y revocarla sin tocar un solo prompt. La política deja de ser prosa que esperas que el modelo lea y pasa a ser código que puedes diferenciar, probar y auditar.

Procedencia para artefactos producidos por agentes

La identidad y la política gobiernan lo que los agentes pueden hacer. La procedencia gobierna lo que puedes decir sobre lo que hicieron. El mundo de la cadena de suministro pasó los últimos años construyendo exactamente esta maquinaria, y el libro blanco trae tres piezas de ella hacia el desarrollo agéntico:

El movimiento del libro blanco es extender esta disciplina hacia atrás, desde la procedencia de build hasta la procedencia de origen. Git registra qué contenido cambió; el paquete de evidencia — diseñado bajo EGD-001 — registra por qué cambió y bajo la autoridad de quién: la revisión de origen, la sesión de agente y el modelo, la autorización de trabajo, las versiones de herramientas, las comprobaciones ejecutadas con sus estados canónicos, el perfil de política que las interpretó, las aprobaciones, y el digest final del artefacto. Una sola cadena desde la intención hasta el despliegue.

Importan dos matices, y el libro blanco expone ambos con claridad. Primero, estos mapeos no confieren un nivel SLSA ni una procedencia confiable sin relaciones de confianza verificadas — adoptar los formatos es necesario, no suficiente. Segundo, la división de capacidades es real: el pipeline de CI construye y firma manifiestos de evidencia como jobs, en vivo donde esos jobs corren, mientras que los libros mayores de paquete, suficiencia y conformidad del lado del cerebro tenían cero filas en la instantánea del 2026-08-23 — escritores y pruebas en su lugar, no habilitados. La evidencia firmada la puedes inspeccionar hoy; la integración más profunda de los libros mayores está registrada como inconclusa.

Qué te da esto en una revisión de seguridad

Aquí es donde la arquitectura se encuentra con el cuestionario. El AI Risk Management Framework del NIST y su Generative AI Profile (nist.gov) fijan las expectativas para gobernar el riesgo de IA; el SP 800-218, el Secure Software Development Framework v1.1, y el SP 800-218A, el generative-AI SSDF Community Profile (final 2024, escrito para apoyar la Executive Order 14110), definen las prácticas de desarrollo seguro que cada vez más se les pide a los adquirentes que exijan. El SP 800-218A está dirigido precisamente a los lectores de este artículo: productores de sistemas de IA, y los adquirentes que los evalúan.

Los paquetes de evidencia se corresponden con esas expectativas de estilo SSDF, control por control. Cuando un revisor pregunta cómo proteges el entorno de build, la respuesta son los manifiestos firmados del pipeline. Cuando pregunta cómo gobiernas el código generado por IA, la respuesta es política versionada con decisiones persistidas y auditoría por principal. Cuando pregunta quién accedió a qué, el libro mayor temporal devuelve filas. El planteamiento del propio libro blanco es el honesto, y vale la pena tomarlo prestado para tu próxima revisión: los marcos son orientación, un control es comportamiento implementado, la evidencia demuestra que el comportamiento ocurrió, y la certificación es una determinación aparte. Koinessa está en prelanzamiento, operado por su fundador, y no está auditado de forma independiente — reclama controles y comprobantes, no certificados.

Esa postura encaja naturalmente con el despliegue local-first: el gateway, los libros mayores y los modelos que elijas corren en cómputo controlado por el cliente, de modo que «a dónde va nuestro código» tiene un diagrama de red como respuesta, y la verificación fail-closed significa que un éxito no verificado nunca se reporta como un pass.

Lo esencial

«Demuestra que mi código y mis datos se mantienen privados» se descompone en tres afirmaciones demostrables: todo acceso está identificado y autorizado, sin importar de qué red llega (Saltzer y Schroeder, SP 800-207); toda decisión de autorización es código versionado con un resultado persistido, no texto de prompt (el patrón OPA); y todo artefacto enviado a producción lleva una cadena firmada desde la intención hasta el despliegue (SLSA, in-toto, Sigstore). Koinessa implementa esos puntos como controles en vivo donde existen los comprobantes, y etiqueta el resto — 78%, 81%, no habilitado — como lo que es. El argumento completo, con el modelo de identidad completo y la disciplina de evidencia de seis estados detrás de estas afirmaciones, está en el libro blanco, y las lecciones de seguridad de la sección 2 trazan el linaje de cincuenta años sobre el que se apoya.