Introducción
Los agentes de IA compositivos ejecutan workflows mediante secuencias de llamadas a herramientas, pero las políticas de autorización tradicionales, como las escritas en Cedar, evalúan cada request de forma aislada. Esto deja vacuos de seguridad: no es posible expresar restricciones como «requerir aprobación previa», «mantener un total acumulado» o «bloquear acciones tras acceder a datos confidenciales». AWS resolvió este problema con Dogwood, un lenguaje de políticas open source que extiende Cedar con condiciones temporales para analizar el historial de eventos del agente.
Qué ocurrió
El 16 de agosto de 2026, AWS anunció el código abierto de Dogwood, una extensión de Cedar (el lenguaje de políticas de permisos contribuido por AWS al CNCF en noviembre de 2025) que incorpora lógica temporal. Dogwood permite definir reglas que evalúan no solo la solicitud actual, sino también la secuencia de llamadas a herramientas realizadas previamente por el agente. El proyecto se libera bajo licencia Apache 2.0 y ya es soportado por AgentCore Policy, el servicio de AWS (lanzado en re:Invent 2025) que actúa como capa de control determinista fuera del modelo de lenguaje.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de Seguridad, Dogwood cierra una brecha crítica en la gobernanza de agentes: hasta ahora, las políticas solo podían autorizar o denegar acciones individualmente, sin contexto de lo ocurrido antes. Esto impedía implementar controles como:
- Aprobaciones por pasos: «Permitir la eliminación de recursos solo si el agente consultó primero el estado de backup».
- Límites acumulados: «Bloquear si el gasto total en llamadas a APIs supera $1000 en la última hora».
- Aislamiento de datos: «Prohibir el acceso a sistemas internos si el agente interactuó con datos de clientes».
El impacto es relevante para Cloud y DevOps porque:
- Compatibilidad con MCP: Dogwood genera esquemas de acción automáticamente desde los manifestos de herramientas Model Context Protocol (MCP), estandarizando la integración con herramientas arbitrarias. La especificación MCP 2026-07-28 (publicada el 28 de julio de 2026) ya incluye headers obligatorios (method y tool-name) que hacen el tráfico de agentes legible para infraestructura HTTP, complementando Dogwood.
- Integración con AgentCore: Los equipos que usen AgentCore Policy pueden adoptar Dogwood inmediatamente para gobernar agents en producción, aunque con las limitaciones que detalla AWS.
Detalles técnicos
Dogwood extiende Cedar con un segundo tipo de cláusula: condiciones temporales (when temporal), que evalúan el historial de eventos del agente. Cada evento representa una solicitud de llamada a herramienta y su resultado, e incluye:
- Principal que realizó la solicitud.
- Herramienta llamada y argumentos de entrada.
- Marca de tiempo (confiable, según advierte AWS).
Operadores temporales
Dogwood implementa cuatro operadores como macros sobre un subconjunto de Metric First-Order Temporal Logic (MFOTL):
when temporal {
formerly(hasPrincipal(«user:alice») && action.is(«DeleteResource»))
}
when temporal {
count_within(hasResource(«arn:aws:s3:::bucket/*»), 1h) <= 5
}
El operador bind permite referenciar un agregado en la condición:
when temporal {
bind totalSpent = sum_within(action.request amount, 1h);
totalSpent < 1000
}
Arquitectura y limitaciones
- Interpretación: Las condiciones temporales se traducen a campos de contexto de Cedar, que el intérprete completa con el historial de eventos antes de evaluar la política.
- Estado: Requiere mantener un log de eventos por agente, lo que introduce:
– Latencia: El tiempo de evaluación escala con el tamaño del historial.
– Memoria: AWS recomienda definir políticas de retención para evitar almacenar datos sensibles innecesariamente.
- Análisis formal: Las herramientas de reasoning automatizado de Cedar (como cedar-validate) no soportan condiciones temporales. Esto significa que las políticas con when temporal no pueden ser verificadas formalmente para detectar conflictos o redundancias.
- Concurrency: Las políticas deben evaluarse sobre solicitudes (no respuestas) para evitar race conditions. AWS incluye un ejemplo revelador:
– Una política que suma respuestas de transferencias (sum_within sobre eventos de éxito) puede permitir 3 transferencias concurrentes de $2000 cada una si todas se aprueban antes de que ninguna se complete (total: $6000, superando un límite de $5000).
– La misma política sobre solicitudes (eventos de ToolCall) bloquea la tercera transferencia.
Compatibilidad
- Retrocompatibilidad: Toda política válida de Cedar es válida en Dogwood.
- Precedencia: forbid sigue teniendo prioridad sobre permit, y el default es deny.
- Implementación: El repositorio incluye un interprete de referencia en Rust, pero AWS aclara que no está listo para producción. El código está disponible en github.com/aws/cedar (Dogwood es parte del mismo repositorio que Cedar).
Qué deberían hacer los equipos técnicos
– Identificar workflows de agentes donde las políticas actuales (Cedar o IAM) son insuficientes. Priorizar escenarios con riesgos altos, como cambios en recursos críticos o acceso a datos sensibles.
– Probar Dogwood con políticas de ejemplo para validar que las condiciones temporales cubren los requisitos. El repositorio incluye ejemplos para aprobar antes de actuar, límites de gasto y aislamiento de datos.
– Implementar un log de eventos de agentes confiable:
– Garantizar autenticación de eventos (firmas o tokens de integridad).
– Sincronizar timestamps con una fuente autoritativa (ej: NTP).
– Almacenar eventos en un sistema duradero (ej: Amazon EventBridge, Loki, o una base de datos inmutable).
– Definir políticas de retención según la sensibilidad de los datos (ej: 30 días para logs de herramientas de billing, 7 días para interacciones con datos de usuarios).
– Asegurar el aislamiento de tenants: El historial de un agente no debe ser accedible por otros tenants.
– Asegurar que las herramientas expuestas a agentes implementen la especificación MCP 2026-07-28, que incluye los headers obligatorios (method y tool-name). Esto permite a gateways o proxies inspeccionar el tráfico y alimentar el log de eventos requerido por Dogwood.
– Generar esquemas de acción para Dogwood a partir de los manifestos de herramientas:
dogwood schema generate –tools mcp-manifest.json –output schemas/
– Comenzar con políticas simples y testearlas exhaustivamente:
policy Set(Principal: Principal, Action: Action, Resource: Resource) {
permit(
principal: Principal,
action: Action,
resource: Resource
) when {
// Cedar: condición estática
resource.tag.department == «finance»
} when temporal {
// Dogwood: condición temporal
formerly(action.is(«RequestApproval») && action.resource == resource)
}
}
– Evitar race conditions: usar count_within o sum_within sobre solicitudes (ToolCall), no respuestas.
– Documentar las políticas, especialmente las temporales, ya que no pueden analizarse formalmente.
– El intérprete de referencia no está auditado para uso en producción. AWS recomienda usarlo solo para exploración y pruebas.
– Para entornos productivos, esperar a que AWS o un third-party ofrezca una implementación certificada, o implementar una propia con revisiones de seguridad.
Conclusión
Dogwood resuelve un problema fundamental en la gobernanza de agentes: la capacidad de definir políticas que dependen del contexto histórico. Su integración con Cedar y MCP, junto con la licencia Apache 2.0, facilita su adopción en ecosistemas existentes. Sin embargo, las limitaciones en análisis formal y el requerimiento de una infraestructura de logs confiable imponen desafíos operativos. Para los equipos de seguridad y cloud, Dogwood es una herramienta prometedora, pero su uso en producción debe esperar a implementaciones maduras y a la resolución de los trade-offs entre expresividad y verificabilidad.
Fuentes
- AWS Open-Sources Dogwood, Extending Cedar to Govern Sequences of Agent Tool Calls
- Especificación MCP 2026-07-28
- Repositorio de Cedar (incluye Dogwood)