Lo que un toolkit de gobernanza no puede hacer (según su propia documentación)

Una capa de gobernanza en tiempo de ejecución, como el Agent Governance Toolkit open source de Microsoft, es de lo más útil que ha aparecido en la stack de agentes. Intercepta cada llamada a herramienta, decide contra una política escrita si la acción puede dispararse, y registra el veredicto en un registro resistente a manipulación. En su honor, el proyecto publica además una lista honesta de lo que no hace. Esa lista vale más que cualquier análisis, porque define el trabajo que sigue siendo tuyo.

Solo que, en cuanto hay una capa de gobernanza en su sitio, invita a un supuesto peligroso: que el modelo de amenaza ya está cubierto. No lo está. Una capa de gobernanza es necesaria e insuficiente, y tratar "necesaria" como "suficiente" es la forma en que un sistema con aspecto de bien defendido deja abiertas sus brechas reales.

El error es comprar una cerradura para la puerta principal y dejar de pensar en las ventanas.

Gobierna acciones, no intenciones

Un gate en la llamada a herramienta ve la acción, no el razonamiento que hay detrás. Así que no atrapa un hecho alucinado una vez ese hecho se pasa a una acción que el agente tenía permitida. No frena con fiabilidad una instrucción maliciosa colada dentro de contenido que se le dijo al agente que leyera. Y no puede ver que diez acciones inocuas por separado, cada una correctamente permitida, suman un plan dañino.

No son defectos. Son la frontera de lo que puede hacer un gate por llamada. Atraparlos requiere capas distintas: una frontera de contaminación que impida que la entrada no confiable se convierta en instrucción privilegiada, un patrón de doble modelo que separe el componente que lee contenido no confiable del que puede actuar, y análisis a nivel de flujo, que mira la secuencia y no solo el paso.

Corre dentro de la misma frontera de confianza que el agente

Por diseño, una capa de gobernanza a nivel de aplicación vive en el mismo proceso que el agente al que vigila. Lo que significa que un atacante que comprometa del todo al agente puede, en principio, pasar por delante del guardia.

Ese es el sitio correcto para aplicar políticas, y también es por lo que aplicar políticas no es lo mismo que aislar. La contención real necesita una frontera que el agente no pueda rodear: identidades de privilegio mínimo por agente, credenciales de corta duración sin nada estático que robar, ejecución en sandbox y una allow-list de salida. El gate decide qué está permitido. La sandbox decide qué es posible incluso cuando se elude el gate.

Permitir por defecto es un precipicio de configuración

Encendido sin políticas cargadas, la acción por defecto es permitirlo todo. Ejecútalo en modo permisivo sin darte cuenta y todos los agentes quedan, en la práctica, sin gobernar mientras el panel se ve en verde.

Este es el fallo que pasa un comité de cambios. La capa está presente, la casilla está marcada y el libro de reglas está vacío. La gobernanza que permite por defecto es gobernanza que tienes que ganarte activamente, cada vez, con política que alguien escribió a propósito y pruebas que demuestran que está cargada.

Registra en bruto lo que le entregan

El sistema de auditoría registra los parámetros de las llamadas tal como los recibe. Si una llamada lleva datos personales, una credencial o un token como argumento, ese valor puede aterrizar en el registro tal cual. Un registro resistente a manipulación de tus secretos sigue siendo un registro de tus secretos.

La ocultación, la clasificación y una ruta de datos que mantenga el material regulado fuera del registro no son trabajo del toolkit. Son tuyos, y en un entorno regulado no son opcionales.

La auditoría registra el intento, no el resultado

El registro recoge que una acción fue permitida y pasada al mundo exterior. No verifica que la acción tuviera éxito, y no te dice si permitirla fue correcto. Es evidencia de una decisión, no evidencia de una buena decisión. El criterio detrás de la política, y la responsabilidad por el resultado, quedan enteramente fuera del registro.

Necesaria, e insuficiente

Junta las limitaciones y la forma del sistema real queda clara. Una capa de gobernanza es un control entre varios, y los que no puede aportar son precisamente los que separan una demo de un sistema que un regulador aceptará.

Así que la pregunta que llevar a tu próxima revisión de arquitectura no es "¿tenemos una capa de gobernanza en runtime?". Ten una. Es cuáles de las limitaciones que ella misma declara estamos cubriendo con otra capa, y cuáles estamos esperando en silencio que no lleguen a importar. La respuesta honesta a esa pregunta es tu verdadera postura de seguridad. El toolkit te dijo dónde están sus bordes. Construir más allá de ellos es todo el trabajo.

Si quieres mapear una capa de gobernanza contra las capas que tienen que rodearla, reserva una reunión.