← Todos os insights

Análise de notíciaRecorte: Brasil4 min de leitura

A próxima permissão de um agente pode depender da última ação. AWS Strands Box torna a autorização temporal

A AWS lançou o Strands Box em developer preview: um sandbox de agente open source cujas políticas Dogwood permitem ou negam cada ação com base no que o agente já fez.

Ouça este artigo · 5 min

Narração completa do artigo, gerada por IA.

Catracas de metrô em fila, em duotone La Madre, ao lado das palavras O que veio antes
Foto: rawpixel (CC0)

Um agente lê uma exportação de cliente para responder a uma pergunta. Poucos minutos depois, tenta postar em um webhook externo. Cada ação, por si só, é algo que o agente tem permissão para fazer. Juntas, elas formam um caminho de exfiltração.

Uma lista estática de permissões não consegue fazer essa distinção. Ela julga cada requisição como se nada tivesse acontecido antes. É essa lacuna que a AWS mira com o Strands Box, apresentado em 7 de outubro em developer preview: um sandbox de agente open source, licenciado sob Apache 2.0, cujas políticas podem olhar para o que o agente já fez antes de decidir o que ele pode fazer em seguida.

Quatro portas e uma memória

O Strands Box combina duas camadas. A primeira é a contenção do sistema operacional, que no macOS, a única plataforma suportada hoje, usa o Seatbelt da Apple. A segunda é a aplicação de políticas em quatro pontos de interceptação: um gateway para egress de rede, um interpretador Python, um interpretador de shell e um broker para ferramentas MCP.

As políticas são escritas em Dogwood, uma nova linguagem de políticas open source que empresta a sintaxe do Cedar. A diferença em relação a um motor de políticas convencional está em uma frase do anúncio: “As permissões podem depender de ações anteriores, sua ordem e limites acumulados ao longo do tempo.” Toda ação que passa por essas quatro portas é registrada, e decisões posteriores podem ler esse registro.

O exemplo da própria AWS é deliberadamente simples. Uma regra permite que o agente poste, mas não mais de três vezes a cada dez minutos. A quarta tentativa dentro da janela é negada, enquanto operações não relacionadas continuam.

Uma regra que conta o que já aconteceu

Janela abreDez minutos depois

  1. Post 1Permitido
  2. Post 2Permitido
  3. Post 3Permitido
  4. Post 4, às 10:06Negado, regra nomeada no 403
  5. Outras açõesAinda permitido
Exemplo da AWS: a mesma requisição é permitida três vezes e negada na quarta, porque a decisão lê o histórico recente do agente.

Quando uma política nega uma ação, o gateway retorna um HTTP 403 que nomeia a regra pelo seu identificador e carrega sua descrição. Uma negação que diz qual regra disparou é algo que um desenvolvedor pode depurar e um revisor de segurança pode auditar, o que é mais do que a maioria dos guardrails de agente oferece.

Credenciais que o agente nunca detém

A segunda ideia é mais silenciosa e pode importar mais. O Strands Box pode injetar credenciais fora do ambiente do agente. O agente trabalha com tokens placeholder; o gateway substitui pelo segredo real na saída, para bearer tokens, cabeçalhos personalizados, autenticação básica, parâmetros de consulta e assinatura AWS SigV4. Nas palavras do anúncio, “O segredo real nunca entra no ambiente do agente.”

Uma injeção de prompt pode persuadir um agente a imprimir tudo o que sabe. Não pode vazar uma chave que o agente nunca teve.

Para que servem regras cientes do histórico

Limites de taxa são o caso fácil. As regras mais interessantes, ilustradas aqui em vez de tiradas dos exemplos da AWS, são as que permissões estáticas não conseguem expressar de forma alguma:

  • Volume por sessão. Permita exclusões, mas não mais de um número definido por tarefa, para que uma instrução mal interpretada não esvazie uma pasta.
  • Ordem. Permita um deploy somente depois que um teste tiver sido bem-sucedido na mesma sessão.
  • Fluxo. Restrinja requisições de saída depois que o agente tiver tocado em uma fonte sensível, que é o cenário com que este artigo abriu.

A AWS também lista regras de vivacidade em seu roadmap: obrigações que um agente deve eventualmente cumprir, como fechar o que abriu, com detecção quando não o faz. Isso moveria a política de “o que não deve acontecer” para “o que deve acontecer”. É um plano, não um recurso.

Os limites de um developer preview

O anúncio é franco sobre as restrições, e qualquer plano de adoção também deveria ser.

  • Somente macOS por enquanto. Outros sistemas operacionais são uma prioridade declarada, assim como rodar o Box ao lado de agentes no Bedrock AgentCore, ECS e Kubernetes. Nada disso está disponível ainda.
  • Os interpretadores rodam fora do sandbox, o que amplia a base de computação confiável.
  • A configuração é manual: um arquivo box.toml e um arquivo policy.dw, com baselines automáticos no roadmap.
  • Caminhos concedidos diretamente são invisíveis para o histórico. Caminhos concedidos no box.toml, como um diretório de projeto lido pela ferramenta de arquivo do próprio harness do agente, são limitados pela contenção, mas não aparecem no histórico de políticas. Uma regra de fluxo que depende de “o agente leu isto?” só vê leituras que passam pela camada de políticas.

Esse último ponto é o que se deve levar em conta no design. Política temporal é tão boa quanto o registro que ela lê.

Esta semana a Microsoft tornou os Execution Containers em disponibilidade geral (GA) no Windows, movendo a fronteira do agente para o sistema operacional. O Strands Box adiciona uma pergunta diferente à mesma ideia. A contenção pergunta se este agente pode alguma vez fazer algo. A política temporal pergunta se ele pode fazer isso agora, dado o que acabou de fazer. Ambas as respostas precisam vir de fora do agente, e agentes em produção precisarão de ambas.

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso