Los agentes de IA están dejando de limitarse a responder preguntas. Según Microsoft, ya están reservando vuelos, ejecutando operaciones, escribiendo código y gestionando infraestructura de forma autónoma. A medida que esa autonomía aumenta, también lo hace una pregunta central: cómo gobernar sus acciones.
Ese es el punto de partida del Agent Governance Toolkit, un proyecto open source lanzado por Microsoft con licencia MIT. La propuesta del toolkit es llevar la gobernanza y la seguridad en tiempo de ejecución a los agentes autónomos, con una arquitectura pensada para trabajar con los frameworks que los desarrolladores ya utilizan.
El problema que quiere resolver
Microsoft sitúa el problema en un contexto claro: hoy es cada vez más fácil construir agentes que razonan, planifican y actúan. Frameworks como LangChain, AutoGen, CrewAI, Microsoft Agent Framework o Azure AI Foundry Agent Service han reducido mucho la barrera de entrada.
Sin embargo, esa facilidad para crear agentes no ha ido acompañada, según el texto, por una infraestructura equivalente para gobernar su comportamiento autónomo.
El artículo menciona dos señales que refuerzan esa necesidad:
- En diciembre de 2025, OWASP publicó el Top 10 for Agentic Applications for 2026, una taxonomía de riesgos específica para agentes autónomos.
- También señala la evolución regulatoria, con obligaciones del European Union AI Act para sistemas de alto riesgo a partir de agosto de 2026 y la aplicación del Colorado AI Act desde junio de 2026.
Qué es Agent Governance Toolkit
Microsoft presenta el Agent Governance Toolkit como un proyecto open source publicado bajo la organización de Microsoft y con licencia MIT. Lo describe como el primer toolkit que aborda los diez riesgos de OWASP para IA agéntica mediante una aplicación determinista de políticas con latencia de menos de un milisegundo.
La idea no es sustituir los frameworks existentes, sino añadir una capa de gobernanza sobre ellos.
Los siete componentes del toolkit
El toolkit se organiza en siete paquetes, disponibles en Python, TypeScript, Rust, Go y .NET. Cada uno cubre un área concreta de gobernanza:
Agent OS
Se presenta como un motor de políticas sin estado que intercepta cada acción del agente antes de su ejecución, con una latencia p99 inferior a 0,1 ms.
Incluye soporte para:
- Reglas YAML.
- OPA Rego.
- Cedar.
Microsoft lo define como una especie de kernel para agentes de IA.
Agent Mesh
Se centra en identidad y confianza entre agentes. Incluye:
- Identidad criptográfica basada en identificadores descentralizados.
- Protocolo Inter-Agent Trust Protocol (IATP) para comunicación segura entre agentes.
- Sistema dinámico de puntuación de confianza de 0 a 1000 con cinco niveles de comportamiento.
Agent Runtime
Introduce mecanismos inspirados en niveles de privilegio de CPU y añade capacidades como:
- Anillos dinámicos de ejecución.
- Orquestación saga para transacciones de varios pasos.
- Un kill switch para la terminación de emergencia de agentes.
Agent SRE
Aplica prácticas de fiabilidad de producción a sistemas de agentes. El artículo enumera:
- SLOs.
- Error budgets.
- Circuit breakers.
- Chaos engineering.
- Progressive delivery.
Agent Compliance
Este componente se orienta a la verificación automatizada de gobernanza. Incluye:
- Grading de cumplimiento.
- Mapeo con marcos regulatorios como European Union AI Act, HIPAA y SOC2.
- Recogida de evidencias para las diez categorías de riesgo del OWASP Agentic AI Top 10.
Agent Marketplace
Se enfoca en la gestión del ciclo de vida de plugins, con:
- Firma Ed25519.
- Verificación.
- Control de capacidades por niveles de confianza.
- Seguridad de cadena de suministro.
Agent Lightning
Se dedica a la gobernanza del entrenamiento con aprendizaje por refuerzo. Según Microsoft, incorpora runners con políticas aplicadas y reward shaping para asegurar cero violaciones de política durante el entrenamiento RL.
Un diseño pensado para integrarse con el ecosistema existente
Uno de los ejes del artículo es que una herramienta de gobernanza solo resulta útil si funciona con los frameworks que ya utiliza la gente.
Por eso, Microsoft afirma que el toolkit fue diseñado desde el principio para ser agnóstico al framework. Las integraciones se apoyan en puntos de extensión nativos de cada entorno, como:
- Callback handlers en LangChain.
- Task decorators en CrewAI.
- Plugin system en Google ADK.
- Middleware pipeline en Microsoft Agent Framework.
El texto también enumera integraciones ya operativas con varios frameworks y plataformas, entre ellas Dify, LlamaIndex, OpenAI Agents SDK, Haystack, LangGraph y PydanticAI.
Además, el toolkit se extiende a distintos ecosistemas de lenguaje mediante:
- Un SDK de TypeScript distribuido por npm.
- Un SDK de .NET disponible en NuGet.
Microsoft resume esa accesibilidad con una idea práctica: para los desarrolladores que trabajan con estos frameworks, la gobernanza está a una instalación por pip y unas pocas líneas de configuración.
Por qué Microsoft dice que lo construyó así
El artículo explica que, al observar cómo operan los agentes de IA en la práctica, vieron un patrón ya conocido: múltiples programas no confiables compartiendo recursos, tomando decisiones e interactuando con el exterior con mediación limitada.
A partir de ahí, Microsoft plantea una analogía con soluciones ya probadas en otras capas de la ingeniería:
- Los sistemas operativos resolvieron problemas comparables con kernels, anillos de privilegio y aislamiento de procesos.
- Los service meshes lo hicieron para microservicios mediante mTLS e identidad.
- Las prácticas SRE lo hicieron en sistemas distribuidos con SLOs y circuit breakers.
La propuesta del toolkit nace de trasladar esos patrones a los agentes de IA.
Cómo mapea los riesgos del OWASP Agentic AI Top 10
El artículo dedica una sección específica a vincular cada riesgo del marco OWASP con una capacidad concreta del toolkit.
La correspondencia que presenta es la siguiente:
- Goal hijacking: clasificador semántico de intención en el motor de políticas.
- Tool misuse: sandboxing de capacidades y gateway de seguridad para MCP.
- Identity abuse: identidad basada en DID con puntuación de confianza conductual.
- Supply chain risks: firma de plugins con Ed25519 y verificación de manifiestos.
- Code execution: anillos de ejecución con límites de recursos.
- Memory poisoning: Cross-Model Verification Kernel con majority voting.
- Insecure communications: capa de cifrado del Inter-Agent Trust Protocol.
- Cascading failures: circuit breakers y cumplimiento de SLOs.
- Human-agent trust exploitation: workflows de aprobación con lógica de quórum.
- Rogue agents: aislamiento por anillos, degradación de confianza y kill switch automatizado.
Microsoft señala que esta alineación es deliberada y que la arquitectura inspirada en sistemas operativos busca crear una defensa en profundidad, con capas independientes orientadas a distintas categorías de amenaza.
Open source por diseño
El proyecto se publica con licencia MIT y en formato monorepo, con siete paquetes instalables de forma independiente. El texto insiste en que los equipos pueden adoptar la gobernanza de forma incremental: empezar solo por el motor de políticas, añadir identidad cuando aparezcan escenarios multiagente e incorporar prácticas SRE a medida que el sistema escale.
Microsoft también afirma que considera la gobernanza de agentes demasiado importante como para quedar bajo el control de un único proveedor. Por eso expresa la aspiración de llevar el proyecto a una fundación para que pueda ser gobernado por una comunidad más amplia.
La base técnica y operativa del proyecto
El artículo enumera varias inversiones en fundamentos open source y prácticas de seguridad, entre ellas:
- Más de 9.500 tests en todos los paquetes.
- Fuzzing continuo con ClusterFuzzLite.
- Build provenance compatible con SLSA.
- Seguimiento en OpenSSF Scorecard.
- Escaneo automatizado de vulnerabilidades con CodeQL y Dependabot.
- Dependencias fijadas con hashes criptográficos para tooling de CI.
- 20 tutoriales paso a paso.
- SDKs de .NET y TypeScript además de Python.
También señala que la arquitectura fue diseñada para ser extensible, con interfaces públicas que permiten que herramientas de terceros se conecten al pipeline de gobernanza sin modificar el núcleo del sistema.
Lo que Microsoft dice haber aprendido al construirlo
El texto cierra la parte conceptual con varias lecciones extraídas del desarrollo abierto del toolkit.
1. Conviene reutilizar problemas ya resueltos
Microsoft sostiene que trasladar patrones del kernel de sistemas operativos, de los service meshes y de SRE resultó más eficaz que partir desde cero.
2. La seguridad debe estar en el camino de ejecución
Según el artículo, la gobernanza se integró directamente en la ruta de ejecución, interceptando acciones, en lugar de presentarse como una capa opcional. También añade una matización: ninguna capa de seguridad es una solución total y sigue siendo necesaria una defensa en profundidad junto con monitorización continua.
3. La ausencia de estado simplifica el sistema
El texto afirma que hacer el kernel sin estado facilitó el escalado horizontal, el despliegue en contenedores y la auditabilidad.
4. La confianza no es binaria
Microsoft plantea que un modelo de confianza basado solo en “confiable” o “no confiable” no refleja bien la realidad. En su lugar, destaca la utilidad de una puntuación dinámica con degradación conductual y asignación dinámica de privilegios.
Comunidad y adopción
Microsoft indica que el proyecto ya ha recibido primeras contribuciones de la comunidad, incluyendo un pull request para un módulo de análisis de modos de fallo y una integración con el middleware pipeline de Microsoft Agent Framework.
También señala que está colaborando con iniciativas y grupos como:
- OWASP Agent Security Initiative.
- LF AI & Data Foundation.
- Grupos de trabajo de CoSAI.
El artículo invita a contribuir con nuevos adaptadores para frameworks, plantillas de políticas, mejoras de documentación, informes de bugs y solicitudes de funcionalidades.
Cómo empezar
El texto incluye instrucciones básicas para comenzar a usar el toolkit desde el repositorio y ejecutar una demo de gobernanza.
También precisa que:
- Funciona con latencia de gobernanza inferior a 0,1 ms p99.
- Es compatible con Python 3.10+.
- Los paquetes individuales están disponibles en PyPI para adopción incremental.
Opciones de despliegue en Azure
Para el paso a producción, Microsoft propone tres escenarios sobre Azure:
- Azure Kubernetes Service (AKS): desplegar el motor de políticas como sidecar junto a los agentes.
- Microsoft Foundry Agent Service: utilizar la integración middleware incorporada.
- Azure Container Apps: ejecutar agentes con gobernanza en un entorno serverless basado en contenedores.
El artículo remite a las guías de despliegue del repositorio para el detalle de cada caso.
Una tesis clara: la gobernanza debe llegar antes que los incidentes
La idea central del texto queda resumida en su cierre: si los agentes de IA están convirtiéndose en tomadores de decisiones autónomos en dominios sensibles, la cuestión ya no es si hace falta gobernanza, sino si se construirá de forma preventiva o reactiva.
La posición de Microsoft es explícita: optar por construirla de forma proactiva y hacerlo en abierto.
Fuente
Fuente
Imran Siddique, “Introducing the Agent Governance Toolkit: Open-source runtime security for AI agents”, Microsoft, 2 de abril de 2026.