Seguridad de Agentes IA: Prompts vs Enforcement Real
El Microsoft Agent Governance Toolkit acaba de demostrar que la seguridad basada en prompts es teatro. Aquí están los números.
Por AI SOCIETY
El problema que nadie quiere nombrar en producción
Hay una conversación incómoda que sucede en casi todos los proyectos de agentes IA que llegan a nuestra mesa: el equipo técnico pregunta cómo contener al agente, y la respuesta que dan es "lo instruyamos bien en el system prompt."
Eso no es governance. Es esperanza.
Los números ya no permiten ignorarlo: en red-team testing controlado, los agentes con seguridad basada en prompts violan sus propias reglas el 26.67% de las veces. Los agentes con enforcement a nivel aplicación — es decir, con un policy engine determinista que evalúa cada acción antes de ejecutarla — registran 0.00% de violaciones. Los datos provienen del Microsoft Agent Governance Toolkit (AGT), publicado en mayo de 2025 como proyecto open source, validado sobre más de 13,000 pruebas.
Esta no es una diferencia de grado. Es una diferencia de categoría. Y para cualquier empresa que opere en banca, salud o gobierno, marca exactamente la línea entre un sistema auditable y uno que simplemente parece seguro.
Por qué la seguridad basada en prompts es teatro
La seguridad basada en prompts tiene una lógica intuitiva: si le dices al modelo exactamente qué no debe hacer, no lo hará. El problema es que esa lógica asume que el modelo es el único punto de decisión — y que sus instrucciones de sistema son inviolables.
Ninguna de las dos cosas es verdad.
Los LLMs son sistemas probabilísticos. Un prompt de sistema no es un guardrail determinista: es una instrucción que el modelo interpreta en contexto, y ese contexto puede ser manipulado. Los vectores son conocidos: prompt injection en datos externos, jailbreaks vía concatenación de instrucciones aparentemente inocentes, o simplemente variaciones de entrada que el modelo no generalizó correctamente durante el fine-tuning.
"Confiar en el propio modelo para hacer cumplir sus propias restricciones de seguridad crea una dependencia circular. El componente que debe ser controlado es también el mecanismo de control."
— Microsoft Agent Governance Toolkit, Technical Overview, mayo 2025
El resultado no es un sistema inseguro a propósito. Es un sistema que parece seguro en demos y falla silenciosamente en producción, bajo cargas de trabajo que nadie anticipó.
El OWASP Agentic Top 10 no es una lista de conceptos abstractos
En 2025, OWASP publicó por primera vez su lista de los 10 riesgos principales específicos para sistemas agénticos. No son riesgos genéricos de aplicaciones web. Son riesgos propios de arquitecturas donde un modelo puede encadenar herramientas, escalar privilegios, leer contexto externo y ejecutar acciones con efectos reales.
El AGT de Microsoft cubre los 10. Eso es relevante porque significa que alguien construyó una solución sobre una taxonomía de riesgos validada — no sobre intuiciones de ingeniería.
Qué hace el Microsoft Agent Governance Toolkit, sin marketing
El AGT no es un wrapper de prompts. Es una capa de infraestructura que se inserta entre el modelo y sus herramientas, y evalúa cada acción antes de permitir su ejecución. Funciona de forma independiente del modelo subyacente — no importa si usas GPT-5, Claude, Gemini o un modelo local.
Los números que importan:
- 0.012ms de latencia p50 en evaluación de políticas. No añade overhead operativo relevante.
- 0.00% tasa de violación bajo red-team testing con enforcement a nivel aplicación.
- 26.67% tasa de violación con prompt-based safety en el mismo set de pruebas.
- 13,000+ tests de cobertura.
- Compatible con 20+ frameworks: LangChain, CrewAI, AutoGen, OpenAI Agents SDK, AWS Bedrock, entre otros.
- SDKs disponibles en Python, TypeScript, .NET, Rust y Go.
Cuatro niveles de privilegio, no dos
Uno de los elementos más relevantes del AGT desde una perspectiva de governance es su modelo de sandboxing con cuatro niveles de privilegio. La mayoría de los sistemas agénticos operan en binario: el agente puede o no puede hacer algo. AGT introduce granularidad real:
- Sin acceso — la herramienta o recurso está bloqueado completamente.
- Acceso de lectura — el agente puede consultar pero no modificar.
- Acceso supervisado — la acción requiere confirmación humana antes de ejecutarse.
- Acceso pleno — la acción se ejecuta dentro del sandbox con audit trail.
Esto es lo que permite a un agente financiero leer saldos de cuentas sin tener acceso a órdenes de transferencia, o a un agente de soporte técnico diagnosticar un sistema sin poder modificar su configuración. La diferencia entre "el agente no debería hacer esto" y "el agente técnicamente no puede hacerlo" es donde vive el compliance real.
Zero-trust identity para agentes
El AGT implementa identidad zero-trust para agentes: cada agente tiene una identidad verificable, y cada acción está firmada y atribuida. Esto resuelve un problema que muy pocos plantean antes de llegar a auditoría: ¿cómo demuestras que fue el agente A — y no el agente B, ni un humano, ni un proceso externo — quien ejecutó esta acción específica a las 03:17 del martes?
Sin identity a nivel runtime, la respuesta es: no puedes. Y en entornos regulados, "no puedes demostrar quién lo hizo" es equivalente a "no pasas la auditoría."
Dos casos donde esto cambia el análisis de riesgo
Un banco mexicano de primer nivel
Un banco con operaciones en seis estados de la república quería desplegar agentes para automatización de procesos de crédito: recopilación de documentos, validación de identidad, scoring preliminar. El equipo de tecnología construyó el flujo. El equipo de riesgo lo detuvo.
El problema no era el modelo. Era la incapacidad de demostrar, ante una auditoría de la CNBV, que el agente no podía acceder a datos fuera del scope de cada operación, que no podía tomar decisiones de crédito sin supervisión humana, y que cada acción quedaba registrada de forma independiente del sistema que la ejecutó.
Con un policy engine a nivel runtime, los tres problemas tienen solución técnica verificable. Sin él, la respuesta es un documento de política interna que nadie puede auditar en producción.
Un operador de salud en sector privado
Una empresa de gestión hospitalaria en México intentó desplegar un agente de coordinación clínica — scheduling, alertas de interacción medicamentosa, comunicación entre áreas. El agente funcionaba correctamente en staging. En producción, bajo carga real, empezó a generar alertas en contextos donde no debía, porque accedía a datos de pacientes fuera del turno activo.
El bug no era del modelo. Era de la ausencia de un mecanismo que limitara el scope de acceso en tiempo real, por contexto clínico, no por instrucción de sistema. La instrucción decía "solo accede a datos del turno activo." El modelo la interpretaba correctamente el 96% de las veces. El 4% restante era suficiente para violar LFPDPPP.
Por qué el mayor bloqueador no es el modelo
La conversación sobre agentes IA en industrias reguladas sigue centrándose en el modelo equivocado. Literalmente. Las preguntas que recibimos con más frecuencia son sobre qué LLM usar, qué tan grande debe ser el contexto, si usar fine-tuning o RAG. Son preguntas válidas. No son las preguntas que están bloqueando el despliegue.
Lo que bloquea el despliegue de agentes en banca, salud y gobierno no es la capacidad del modelo. Es la ausencia de una capa de governance que sea:
- Determinista: que evalúe políticas con lógica verificable, no con probabilidades.
- Independiente del modelo: que funcione igual si cambias de proveedor de LLM.
- Auditable: que produzca registros que un tercero pueda verificar sin acceso al modelo.
- Operable en producción: que no añada latencia operativa significativa.
El AGT de Microsoft cumple los cuatro criterios. Es open source, lo que significa que puede ser auditado, extendido y desplegado sin dependencia de vendor. Y la señal de comunidad es relevante: el anuncio fue amplificado por Bilgin Ibryam, autor de Kubernetes Patterns (O'Reilly) y committer de Apache Camel — no es hype de marketing, es validación técnica de personas que construyen infraestructura en producción.
Lo que esto valida sobre ARCA y la arquitectura Local-First
Cuando construimos ARCA con audit trail nativo y arquitectura Local-First, la decisión no fue estética. Fue una respuesta al mismo problema que el AGT resuelve ahora con un toolkit independiente: los agentes en producción necesitan enforcement que no dependa del propio modelo.
ARCA opera con audit trail desde el día uno — cada acción de cada agente queda registrada de forma independiente de la capa de modelo. Cada despliegue es Local-First por defecto: los datos no salen del perímetro controlado sin autorización explícita. El policy engine no es un system prompt: es infraestructura.
El AGT de Microsoft es la validación externa de que esa arquitectura no era excesiva — era necesaria. Y para organizaciones que ya tienen ARCA desplegado, el AGT es un complemento de infraestructura compatible que puede añadir cobertura específica del OWASP Agentic Top 10 donde se requiera profundidad adicional.
La pregunta que deberías hacerte hoy
No es "¿tenemos una política de uso de IA?" Esa pregunta tiene respuesta fácil y dice muy poco.
La pregunta es: ¿tienes enforcement a nivel runtime, auditable e independiente del modelo, que demuestre que tus agentes no pueden exceder su scope autorizado?
Si la respuesta es "confiamos en el system prompt", tienes un 26.67% de probabilidad de que eso sea teatro bajo condiciones adversariales. En una empresa regulada, eso no es un riesgo aceptable.
Si la respuesta es "tenemos documentación de políticas", tienes documentación. No tienes governance.
Si la respuesta es "tenemos un policy engine determinista con audit trail independiente del modelo", estás en el percentil correcto. El mercado acaba de ponerte una etiqueta: producción auditable.
Qué hacer ahora
Evalúa el Microsoft Agent Governance Toolkit si construyes sobre LangChain, CrewAI, AutoGen o cualquiera de los 20+ frameworks compatibles. Es open source, Apache 2.0 (verificar licencia en repo), y el overhead de latencia p50 es de 0.012ms — no hay argumento de performance que justifique no evaluarlo.
Si operas en una industria regulada en México o LatAm y necesitas un análisis de tu postura actual de governance de agentes — qué tienes, qué falta, qué necesitas demostrar ante auditoría — es exactamente el trabajo que hacemos en AI SOCIETY.
Y si ya estás evaluando ARCA, esta es la conversación que deberíamos tener: cómo se integra el enforcement a nivel runtime con tu arquitectura actual, qué niveles de privilegio necesitas definir, y qué produce tu audit trail para los reguladores que tienes frente a ti.
Los agentes en producción sin governance de runtime no son una apuesta técnica. Son una apuesta regulatoria. Y los números de Microsoft ya dijeron cuánto vale esa apuesta.