Isole agentes de IA com Lambda MicroVMs na AWS

Para isolar um agente de IA na AWS, execute cada sessão ou tarefa em uma Lambda MicroVM distinta. Parta de uma imagem sem identidade de cliente, limite entrada e saída, entregue permissões mínimas e crie segredos e identificadores no hook de execução, depois que a VM for restaurada do snapshot.

Assim, o agente ganha seu próprio ambiente de sistema operacional sem receber acesso implícito ao orquestrador ou a outra sessão. A documentação do AWS Lambda MicroVMs confirma o isolamento em nível de VM, a inicialização por snapshot, os controles de rede e a preservação de memória e disco durante a suspensão; IAM, filtragem de saída e descarte de estado continuam sob responsabilidade da arquitetura.

Use uma MicroVM como fronteira da sessão

Adote um vínculo direto: uma sessão, um trabalho do agente e uma MicroVM. O plano de controle deve iniciar a instância antes da primeira ferramenta, associar seu identificador ao usuário e ao locatário e rejeitar chamadas que não correspondam a esse vínculo.

Não reutilize uma MicroVM de uma sessão encerrada como ambiente de outro cliente. A suspensão serve para retomar o mesmo trabalho, pois preserva memória e disco; ela não limpa a sandbox. Quando a sessão terminar ou atingir sua duração máxima, encerre a instância e remova a associação no plano de controle.

Registre a versão da imagem, a MicroVM, os conectores, a role de execução e a autorização de cada ferramenta. Uma identidade verificável no log permite reconstruir a decisão sem armazenar tokens, chaves ou conteúdo sigiloso.

Faça a imagem comum e deixe a identidade para o boot

A imagem deve conter apenas elementos reutilizáveis: Amazon Linux 2023, runtime, dependências fixadas, binários, certificados públicos e o processo que atende aos hooks. Não inclua UUIDs, chaves privadas, tokens, arquivos de cliente ou conexões que identifiquem uma sessão.

Isso é necessário porque o build inicia a aplicação e captura processos, memória e disco em um snapshot Firecracker. Segundo os conceitos centrais de Lambda MicroVMs, conteúdo exclusivo criado nessa fase pode ser compartilhado por todas as instâncias da mesma versão; ele deve ser regenerado depois da restauração, no hook /run.

No /run, valide a associação entre a MicroVM e a sessão, crie identificadores com um gerador criptograficamente seguro e prepare um diretório de trabalho vazio. Passe no payload somente a configuração variável indispensável, como identificadores opacos ou referências a credenciais temporárias, e não um segredo permanente em texto aberto.

Trate cada versão da imagem como imutável. Publique outra versão quando atualizar dependências, valide-a sem dados reais e fixe explicitamente a versão usada pela sessão; depender da versão ativa mais recente pode alterar o ambiente de um trabalho ainda em andamento.

Restrinja entrada e saída separadamente

A entrada ocorre por um endpoint HTTPS próprio da MicroVM e exige token de autenticação. Emita o token apenas para o cliente autorizado, limite-o às portas usadas pela aplicação e defina validade curta. O endpoint não deve funcionar como identidade permanente da sessão.

Na saída está o risco menos visível: MicroVMs têm acesso público à internet por padrão. A configuração de rede das MicroVMs permite tratar ingress e egress de forma independente e encaminhar o tráfego de saída por um conector VPC, onde security groups e ACLs de rede passam a restringi-lo.

Use conectores diferentes no build e no runtime. O build pode precisar alcançar repositórios de pacotes, enquanto o agente em execução talvez necessite somente de uma API interna, um bucket ou um banco específico. Se downloads dinâmicos forem inevitáveis, encaminhe-os por proxy ou repositório intermediário com allowlist e registros; liberar HTTPS para qualquer destino também abre um caminho de exfiltração.

Separe IAM e entregue segredos após a restauração

Crie uma role de build para obter o artefato no S3 e produzir a imagem, e uma role de execução distinta para o runtime. A segunda deve permitir apenas as ações e os recursos necessários àquela classe de tarefa, sem curingas, permissões do operador humano ou acesso a todos os projetos de um locatário.

O /run pode receber a referência a um segredo no Secrets Manager ou uma URL assinada de curta duração. A role de execução resolve a referência somente após a MicroVM iniciar, e a aplicação conserva o valor apenas durante o uso. Essa entrega tardia evita gravar a credencial no snapshot, mas não impede que código autorizado a lê-la tente enviá-la; por isso, validade curta, privilégio mínimo e egress restrito precisam atuar juntos.

Ao retomar uma instância, use o hook /resume para renovar credenciais vencidas, refazer conexões e confirmar que a sessão ainda está autorizada. Sockets, tokens e decisões de acesso preservados durante a suspensão não devem ser aceitos sem nova validação.

Encerre o estado, não apenas o processo

No hook /suspend, conclua gravações pendentes e feche conexões que não devam atravessar a pausa. No /terminate, exporte somente resultados aprovados, revogue acessos temporários e retire a referência da sessão no plano de controle. O disco da sandbox não deve ser o registro permanente do trabalho.

Defina um período de inatividade para suspensão e uma duração máxima para encerramento. Mantenha também um reconciliador externo que encontre sessões finalizadas com MicroVMs ainda ativas: hooks podem falhar, portanto expiração de credenciais e remoção de acesso não podem depender exclusivamente de código dentro da sandbox.

Checklist da sandbox por sessão

Uma MicroVM distinta atende cada sessão ou tarefa e nunca muda de locatário.
A imagem contém somente dependências comuns; identificadores, segredos e arquivos exclusivos surgem no /run.
Build e runtime usam roles e conectores adequados às suas necessidades diferentes.
Tokens de entrada têm portas e validade limitadas.
O egress público padrão é substituído por destinos explicitamente autorizados.
O /resume renova credenciais e revalida a autorização da sessão.
Suspensão preserva a continuidade; encerramento remove recursos e vínculos.
Logs correlacionam sessão, imagem, MicroVM e ferramentas sem registrar segredos.

Essas fronteiras têm funções complementares: a MicroVM contém a execução, IAM limita quais recursos ela pode solicitar, a rede reduz os destinos alcançáveis e o ciclo de vida impede que o estado de um trabalho seja entregue ao seguinte.

Agente de IA ganhou uma VM própria — isole rede, segredos e estado na AWS