Plano de gobierno y seguridad de agentes de IA: arquitectura de referencia

Desplegar un agente de IA que de vez en cuando hace algo es una demo. Desplegar una flota de agentes que tienen acceso real a sistemas reales, realizan acciones reales y funcionan de forma continua es un problema de seguridad en producción, y choca una y otra vez con las mismas tres piezas sin resolver, llegue el equipo por donde llegue: la identidad, la seguridad y la observabilidad. Esta es una arquitectura de referencia que trata las tres como un único sistema conectado, organizado en torno a una pregunta sencilla: ¿qué tiene que ocurrir, correctamente, cada vez que un agente intenta hacer algo? A continuación está la arquitectura completa, y una versión interactiva en la que puedes recorrer cada componente y autoevaluar tu propio entorno frente a ella.

Los tres problemas, planteados con precisión

• Identidad. Un agente nunca debería tener una credencial de larga duración. Debería solicitar un acceso acotado, efímero y específico para la tarea cuando necesite actuar, y ese acceso debería caducar automáticamente: es el privilegio permanente cero, y importa más en los agentes que en las personas porque a un agente se le puede llevar a abusar del acceso que tiene con mucha más facilidad (una inyección de prompts, el resultado envenenado de una herramienta, una mala instrucción) de lo que se puede manipular a una persona en el momento.
• Seguridad. Cada acción que realiza un agente tiene que pasar por una aplicación en tiempo de ejecución que pueda permitir, denegar o derivar a una persona y, lo que es fundamental, necesita una vía de cuarentena para la zona gris, no solo un permitir/denegar binario que bloquea demasiado o permite demasiado.
• Observabilidad. Cuando un agente hace algo mal, la pregunta nunca es solo «¿ocurrió?», sino «¿por qué lo permitió el motor de políticas, qué hizo realmente el agente y quién aprobó qué?». Eso exige una depuración basada en trazas: un registro inmutable hecho para la reconstrucción, no una línea de log que esperas que sea lo bastante detallada.

El flujo central: lo que ocurre en cada acción

1. Gestión de identidades y accesos de los agentes: la base

Un registro de agentes es el inventario centralizado de cada agente, su versión, su responsable, su finalidad y su estado en el ciclo de vida: no puedes gobernar lo que no has inventariado. El privilegio permanente cero significa que los agentes no tienen ningún permiso por defecto y solicitan tokens acotados y efímeros por tarea. El mapeo de la delegación sigue toda la cadena de custodia (usuario, agente, subagente, herramienta) para que siempre puedas responder a «¿quién autorizó esto en última instancia?». Una bóveda de credenciales guarda los secretos reales; los agentes nunca los tocan directamente, solo un token proxy de corta duración que la bóveda emite a petición. Los agentes nunca reciben credenciales de larga duración. Punto.

2. Punto de decisión de políticas: el cerebro central

Un motor de políticas (ABAC/RBAC) evalúa cada acción en función de quién la pide, qué pide, sobre qué recurso y en qué contexto. La puntuación de riesgo pondera la acción frente al historial y el contexto: leer una base de datos es de riesgo bajo, actualizar una incidencia de soporte es de riesgo medio, emitir un reembolso es de riesgo alto. La derivación con una persona en el bucle envía las acciones seguras a la ejecución automática, las de riesgo medio a comprobaciones adicionales, las de riesgo alto a la aprobación de una persona y las ambiguas a la cuarentena. Y la propia política vive como política como código: con control de versiones en Git, revisión por pares, pruebas en seco y un control de paso antes de llegar a producción. Se evalúa cada acción; nada tiene vía libre por parecer rutinario.

3. Puntos de aplicación de políticas: los porteros

Aquí es donde la decisión se hace realidad. La validación de la petición comprueba el token y los permisos. Las salvaguardas en tiempo de ejecución aplican lo que haya decidido el punto de decisión de políticas y vigilan la propia llamada a la herramienta en busca de comportamientos arriesgados mientras ocurre, no solo antes de que empiece. La reescritura de la petición sanea los datos sensibles y aplica límites a la salida antes de que nada llegue a un recurso. Y los resultados de la aplicación son una de tres cosas: permitir con restricciones, denegar con un motivo o enviar a revisión humana. Ninguna acción llega a un recurso protegido sin pasar por un PEP: esa frase es todo el sentido de esta capa.

4. Auditoría, trazas y cumplimiento: el registro

Un registro de auditoría inmutable recoge cada acción, cada decisión de política, cada llamada a una herramienta y su resultado, cada aprobación humana y cada evento de seguridad. El cumplimiento y los informes convierten todo eso en registros de auditoría listos para SOC 2 y el RGPD, en informes generados y en la materia prima para el análisis forense cuando haya que investigar algo después. El objetivo es la trazabilidad completa del agente a la acción y de la acción al resultado: reconstruible, no solo registrada.

La válvula de seguridad: cuarentena y revisión humana

Las acciones rechazadas o ambiguas no desaparecen sin más en un registro de denegaciones. Se guardan, se avisa al equipo de seguridad, una persona las revisa y decide y, si se aprueban, la acción vuelve a entrar en el flujo de políticas en lugar de perderse. Esto es lo que hace llevadera en la práctica una aplicación estricta: el sistema puede ser conservador con lo que bloquea sin perder para siempre el trabajo legítimo por un falso positivo.

Cinco capas que lo mantienen en marcha a escala

Los cuatro componentes anteriores están directamente en el camino de cada acción. Otros cinco están a su lado, y importan más a medida que un despliegue pasa de un puñado de agentes a una flota real:

• Operaciones de la flota: la torre de control: el ciclo de vida de los agentes (desplegar, actualizar, retirar), la monitorización de la salud de la flota, las versiones y los despliegues graduales, un interruptor de parada para emergencias y la gestión de la configuración y de los feature flags.
• Gobierno de costes: la capa de FinOps: el seguimiento de tokens por agente, el enrutamiento de modelos según el coste, los límites y alertas de presupuesto, la atribución de costes por equipo o proyecto y la limitación automática cuando se alcanzan los topes de gasto.
• Gobierno regional: la resiliencia multirregión: despliegue activo-activo, residencia regional de los datos, coherencia de las políticas entre regiones, conmutación por error automática y recuperación ante desastres.
• Observabilidad y monitorización: realmente transversal, no una capa por encima de las demás: trazado distribuido en el que cada acción es un span, logs estructurados y consultables, paneles y alertas, detección de anomalías en el comportamiento de los agentes y las métricas básicas: latencia, tasa de éxito y tasa de denegación de políticas.
• Controles operativos: primitivas de seguridad y fiabilidad tomadas de la práctica de los sistemas distribuidos y aplicadas a los agentes: limitación de peticiones, mamparos (bulkheads), salvaguardas configurables, cortacircuitos (circuit breakers), comprobaciones de salud y runbooks de guardia para cuando algo sale mal.

Por qué esto está convergiendo ahora en una sola arquitectura

Los tres problemas centrales anteriores no son hipotéticos: ahora mismo, cada uno es toda la razón de ser de una startup reciente y bien financiada. Agentic Fabriq (YC W26) construye identidad y permisos específicos para agentes de IA, y se describe como «el Okta de los agentes». Clam (YC W26) construye seguridad en tiempo de ejecución para agentes con acceso amplio a sistemas empresariales. Traceforce (YC S26) construye monitorización de seguridad a nivel de toda la empresa y visibilidad de las conexiones MCP para aplicaciones de IA. Tres empresas distintas, tres rondas de financiación distintas, tres productos distintos, y cada uno elige exactamente uno de los tres problemas (identidad, seguridad u observabilidad) y construye una empresa a su alrededor. Es una señal razonable tanto de que los tres problemas son reales como de que ninguno está resuelto todavía. Esta arquitectura los trata como tres caras de un mismo sistema y no como tres compras separadas, porque en producción no son realmente separables: un sistema de identidad que no puede alimentar una decisión de política, aplicada por un portero que no puede registrar lo que hizo, no forma nada que un equipo de seguridad pueda defender ante un auditor.

Pruébalo tú mismo

Leer nueve componentes en una lista no es lo mismo que ver cómo se conectan. La versión interactiva de esta arquitectura funciona por completo en tu navegador (prueba gratis: una cuenta gratuita incluye 3 usos de herramientas Pro; después, Pro): recorre los nueve componentes para ver el detalle real de cada uno, después autoevalúa la madurez de tu propio entorno en cada uno y mira cómo el diagrama se convierte en tu propio mapa de brechas, con una lista directa de las áreas más débiles que conviene priorizar.

Preguntas frecuentes

¿Qué problema resuelve exactamente esta arquitectura? Tres, en concreto: la identidad (un agente nunca debería tener una credencial de larga duración, sino solicitar un token acotado y de corta duración exactamente para la tarea en curso), la seguridad (cada acción de un agente tiene que pasar por un punto de aplicación de políticas que pueda permitir, denegar o derivar a revisión humana, con una vía de cuarentena para los casos ambiguos, que no son claramente seguros ni claramente maliciosos) y la observabilidad (cuando algo sale mal, necesitas un registro inmutable y trazable de exactamente lo que hizo el agente, por qué lo permitió o lo bloqueó el motor de políticas y quién aprobó qué).

¿Qué es el «privilegio permanente cero» y por qué importa en los agentes? El privilegio permanente cero significa que un agente no tiene ningún permiso en reposo: solicita a una bóveda de credenciales un acceso acotado, efímero y específico para la tarea solo cuando necesita actuar, y ese acceso caduca automáticamente. Importa más en los agentes que en los usuarios humanos porque a un agente se le puede engañar para que realice una acción (con una inyección de prompts, el resultado malicioso de una herramienta, una mala instrucción) con mucha más facilidad de lo que se puede manipular a una persona para que haga un mal uso de una credencial en la que no está pensando. El privilegio permanente en un agente es una superficie de ataque mucho mayor y siempre disponible.

¿Por qué la cuarentena es un componente aparte en lugar de una simple denegación? Porque un permitir/denegar plano pierde el caso real más habitual: las acciones que no son claramente seguras ni claramente maliciosas. Un motor de políticas que no puede expresar «retén esto y pregunta a una persona» acaba bloqueando de forma demasiado agresiva (lo que mata la utilidad legítima del agente) o permitiendo de forma demasiado laxa (lo que anula el sentido de la aplicación). La cuarentena da a la zona gris un destino real (guardarla, avisar a seguridad, obtener la decisión de una persona y dejar que vuelva a entrar en el flujo de políticas si se aprueba) en lugar de obligar a cada caso dudoso a entrar en uno de dos cubos equivocados.

¿Es el mismo problema en el que trabajan las startups de infraestructura para agentes respaldadas por YC? Los tres pilares encajan bien con lo que varias promociones recientes de Y Combinator han construido de forma independiente como productos propios: Agentic Fabriq (YC W26) construye identidad y permisos específicos para agentes de IA; Clam (YC W26) construye seguridad en tiempo de ejecución para agentes con acceso amplio; Traceforce (YC S26) construye observabilidad y monitorización a nivel de toda la empresa para agentes de IA y conexiones MCP. Que tres empresas distintas y bien financiadas hayan elegido cada una uno de estos tres problemas para construir toda una empresa a su alrededor es una señal razonable de que los tres son reales y ninguno está resuelto todavía; esta arquitectura es una forma de pensar en los tres como partes de un mismo sistema y no como tres compras separadas.

¿Necesito los nueve componentes para sacarle partido? No. Los cuatro componentes del flujo central (identidad del agente, punto de decisión de políticas, puntos de aplicación de políticas y auditoría/trazas) son los que están de verdad en el camino de cada acción de un agente y los que más importa hacer bien primero. Las cinco capas transversales (operaciones de la flota, gobierno de costes, gobierno regional, observabilidad y controles operativos) son lo que mantiene un despliegue maduro funcionando de forma fiable a escala, y es razonable desarrollarlas poco a poco a medida que crece tu flota de agentes, en lugar de todas a la vez.