El próximo permiso de un agente puede depender de su última acción. Strands Box hace temporal la autorización
AWS lanzó Strands Box en developer preview: un sandbox de agentes de código abierto cuyas políticas Dogwood permiten o deniegan cada acción según lo que el agente ya hizo.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.

Un agente lee una exportación de clientes para responder una pregunta. Unos minutos después intenta publicar en un webhook externo. Cada acción, por separado, es algo que el agente tiene permitido hacer. Juntas forman una ruta de exfiltración.
Una lista estática de permisos no puede distinguirlo. Juzga cada solicitud como si nada hubiera ocurrido antes. Esa es la brecha que AWS quiere cerrar con Strands Box, presentado el 7 de octubre en developer preview: un sandbox de agentes de código abierto, con licencia Apache 2.0, cuyas políticas pueden mirar lo que el agente ya hizo antes de decidir qué puede hacer después.
Cuatro puertas y una memoria
Strands Box combina dos capas. La primera es el confinamiento del sistema operativo, que en macOS, la única plataforma compatible hoy, usa Seatbelt de Apple. La segunda es la aplicación de políticas en cuatro puntos de intercepción: un gateway para la salida de red, un intérprete de Python, un intérprete de shell y un broker para herramientas MCP.
Las políticas se escriben en Dogwood, un nuevo lenguaje de políticas de código abierto que toma prestada la sintaxis de Cedar. La diferencia con un motor de políticas convencional está en una frase del anuncio: «Los permisos pueden depender de acciones anteriores, de su orden y de los límites acumulados con el tiempo.» Cada acción que pasa por esas cuatro puertas queda registrada, y las decisiones posteriores pueden leer ese registro.
El ejemplo de la propia AWS es deliberadamente simple. Una regla permite que el agente publique, pero no más de tres veces cada diez minutos. El cuarto intento dentro de la ventana se deniega, mientras que las operaciones no relacionadas siguen su curso.
Una regla que cuenta lo que ya ocurrió
Se abre la ventanaDiez minutos después
- Publicación 1Permitida
- Publicación 2Permitida
- Publicación 3Permitida
- Publicación 4, a las 10:06Denegada, la regla se nombra en el 403
- Otras accionesAún permitidas
Cuando una política deniega una acción, el gateway devuelve un HTTP 403 que nombra la regla por su identificador y lleva su descripción. Una denegación que indica qué regla se activó es algo que un desarrollador puede depurar y que un revisor de seguridad puede auditar, algo que la mayoría de los guardrails para agentes no ofrece.
Credenciales que el agente nunca tiene
La segunda idea es más silenciosa y puede importar más. Strands Box puede inyectar credenciales fuera del entorno del agente. El agente trabaja con tokens de marcador de posición; el gateway sustituye el secreto real a la salida, para bearer tokens, cabeceras personalizadas, autenticación básica, parámetros de consulta y la firma AWS SigV4. En palabras del anuncio: «El secreto real nunca entra en el entorno del agente.»
Una inyección de prompt puede convencer a un agente de imprimir todo lo que sabe. No puede filtrar una clave que el agente nunca tuvo.
Para qué sirven las reglas que miran el historial
Los límites de tasa son el caso fácil. Las reglas más interesantes, ilustradas aquí y no tomadas de los ejemplos de AWS, son las que los permisos estáticos no pueden expresar en absoluto:
- Volumen a lo largo de una sesión. Permitir borrados, pero no más de un número determinado por tarea, para que una instrucción malinterpretada no pueda vaciar una carpeta.
- Orden. Permitir un despliegue solo después de que una ejecución de pruebas haya tenido éxito en la misma sesión.
- Flujo. Restringir las solicitudes salientes una vez que el agente ha tocado una fuente sensible, que es el escenario con el que abría este artículo.
AWS también incluye en su roadmap las reglas de liveness: obligaciones que un agente debe cumplir tarde o temprano, como cerrar lo que abrió, con detección cuando no lo hace. Eso llevaría la política de «lo que no debe pasar» a «lo que debe pasar». Es un plan, no una función.
Los límites de un developer preview
El anuncio es franco sobre las restricciones, y cualquier plan de adopción debería serlo también.
- Solo macOS por ahora. Otros sistemas operativos son una prioridad declarada, igual que ejecutar Box junto a agentes en Bedrock AgentCore, ECS y Kubernetes. Nada de eso está disponible todavía.
- Los intérpretes se ejecutan fuera del sandbox, lo que amplía la base de cómputo confiable.
- La configuración es manual: un archivo
box.tomly un archivopolicy.dw, con líneas base automáticas en el roadmap. - Las rutas concedidas directamente son invisibles para el historial. Las rutas concedidas en
box.toml, como un directorio de proyecto leído por la propia herramienta de archivos del harness del agente, están acotadas por el confinamiento pero no aparecen en el historial de políticas. Una regla de flujo que depende de «¿ha leído el agente esto?» solo ve las lecturas que pasan por la capa de políticas.
Ese último punto es el que hay que tener en cuenta al diseñar. Una política temporal es tan buena como el registro que lee.
Esta semana Microsoft puso los Execution Containers en disponibilidad general (GA) en Windows, llevando la frontera del agente al sistema operativo. Strands Box añade una pregunta distinta a la misma idea. El confinamiento pregunta si este agente puede hacer algo alguna vez. La política temporal pregunta si puede hacerlo ahora, dado lo que acaba de hacer. Ambas respuestas tienen que venir de fuera del agente, y los agentes en producción necesitarán las dos.