# ADR: Executar Código Gerado por IA — Lambda MicroVMs vs. Containers Isolados

Decisão de arquitetura sobre como executar com segurança código gerado por agentes de IA ou submetido por usuários em ambiente multi-tenant, comparando Lambda MicroVMs (lançamento AWS jun/2026), containers efêmeros com gVisor/Firecracker em ECS/EKS e Lambda padrão. A decisão recomendada é Lambda MicroVMs por sessão, orquestrado pelo Bedrock AgentCore, com isolamento em nível de VM sem overhead operacional de virtualização própria.

- URL: https://fernando.moretes.com/studies/adr-codigo-de-ia-com-lambda-microvms

- Markdown: https://fernando.moretes.com/studies/adr-codigo-de-ia-com-lambda-microvms/study.md?lang=pt

- Type: Decisão (ADR)

- Company: Plataforma de agentes (cenário)

- Domain: Serverless / IA

- Status: accepted

- Date: 2026-06-23

- Tags: serverless, ai-agents, security, lambda, bedrock, multi-tenant, isolation, adr

- Reading time: 10 min

---

Quando um agente de IA escreve e executa código arbitrário no seu sistema, o modelo de ameaça muda fundamentalmente. Não é mais uma questão de validar input — é uma questão de conter explosões. Com o lançamento do Lambda MicroVMs em junho de 2026, a AWS entregou uma primitiva serverless com isolamento de nível de VM, estado preservado entre invocações e cold start sub-segundo. Esta ADR documenta a decisão de adotá-la como runtime de execução de código não confiável na plataforma de agentes, e por que as alternativas foram descartadas.

## Fatos do Caso

- **Sistema:** Plataforma de agentes de IA multi-tenant (cenário de referência)
- **Primitiva nova:** AWS Lambda MicroVMs — lançamento junho/2026
- **Regiões disponíveis (lançamento):** us-east-1, us-east-2, us-west-2, ap-northeast-1, eu-west-1
- **Lançamentos relacionados (jun/2026):** Lambda Managed Instances (EC2 gerenciado); payload assíncrono 256 KB → 1 MB
- **Orquestrador de agentes:** Amazon Bedrock AgentCore
- **Modelos de IA relevantes:** Bedrock AgentCore (ex.: Claude 3.x, modelos de terceiros via Bedrock)
- **Domínio de aplicação:** Code interpreter multi-tenant; simulações financeiras geradas por IA
- **Risco principal:** Escape de sandbox entre tenants; exfiltração de dados de sessão cruzada
- **Status da decisão:** Aceita

## O Problema: Code Interpreter Multi-Tenant é um Problema de Contenção, Não de Validação

Plataformas de agentes de IA que executam código — seja Python gerado pelo modelo para análise de dados, scripts de simulação financeira ou ferramentas customizadas invocadas via function calling — enfrentam um problema de segurança que não se resolve com sanitização de input. O código gerado por um LLM é, por definição, não auditável em tempo real. O modelo pode produzir código que tenta ler variáveis de ambiente, fazer syscalls inesperados, ou — em cenários multi-tenant — acessar estruturas de memória compartilhada se o isolamento for insuficiente.

O modelo de ameaça relevante tem três vetores principais: **(1) escape de sandbox** — código malicioso ou mal-formado que sai do contexto de execução e acessa o host ou outros tenants; **(2) exfiltração lateral** — código que lê dados de sessões vizinhas via memória compartilhada, sistema de arquivos temporário ou variáveis de ambiente herdadas de execuções anteriores no mesmo worker; **(3) persistência indesejada** — código que deixa artefatos (processos, arquivos, conexões abertas) que afetam execuções subsequentes.

No contexto financeiro, o risco é ainda mais concreto: imagine um agente gerando e executando uma simulação de Monte Carlo com dados proprietários de portfólio de um cliente. Se o sandbox não isola adequadamente, uma execução subsequente de outro tenant pode herdar estado, variáveis ou conexões de rede da sessão anterior. Isso não é hipotético — é exatamente o vetor que motivou o design do Firecracker pela AWS para o Lambda original e para o Fargate, e que agora motiva o Lambda MicroVMs como primitiva de primeira classe para código de usuário.

O Lambda padrão já usa Firecracker internamente, mas o modelo de execução **reutiliza sandboxes** entre invocações do mesmo tenant (warm start) e não oferece garantias de isolamento **entre sessões de agentes distintos** do mesmo tenant, muito menos entre tenants diferentes. Para um code interpreter multi-tenant, isso é inaceitável.

## As Forças em Jogo: Por Que Essa Decisão é Difícil

Há uma tensão real entre cinco eixos que não se resolvem todos ao mesmo tempo:

**Isolamento vs. Latência.** Isolamento forte (VM por sessão) tem custo de inicialização. O Firecracker original foi um avanço enorme ao reduzir cold start de VMs de segundos para ~125ms, mas ainda é ordens de grandeza mais lento que um container já aquecido. Lambda MicroVMs promete launch/resume sub-segundo com preservação de estado — o que muda o cálculo para agentes multi-turno, onde o custo de cold start se amortiza ao longo da sessão.

**Controle vs. Carga Operacional.** Operar seu próprio cluster EKS com Kata Containers ou Firecracker dá controle total sobre versão do kernel, políticas de seccomp, limites de cgroups, e networking por pod. Mas isso implica uma equipe de plataforma dedicada, ciclos de patching, gestão de capacity e um runbook de incidentes que a maioria das equipes de produto não quer manter. Lambda MicroVMs transfere essa carga para a AWS — com o trade-off de lock-in e menor visibilidade interna.

**Estado vs. Efemeridade.** Agentes multi-turno precisam de estado entre passos: variáveis Python definidas no turno 1 devem estar disponíveis no turno 3. Lambda padrão não preserva estado entre invocações de forma confiável (o execution environment pode ser reciclado). Soluções baseadas em ECS/EKS podem manter um container vivo por sessão, mas isso implica gerenciar o ciclo de vida desse container, seu escalonamento e sua terminação. Lambda MicroVMs resolve isso nativamente com a semântica de resume.

**Custo vs. Segurança.** Lambda padrão é mais barato por invocação. Lambda MicroVMs terá (estimativa) overhead de custo por conta do isolamento adicional — a AWS não publicou pricing específico no lançamento, mas a analogia com Fargate (que também usa Firecracker com isolamento mais forte) sugere 20-40% de premium sobre Lambda padrão para workloads equivalentes. Containers em ECS/EKS têm custo de compute mais previsível, mas o custo operacional humano frequentemente supera o delta de infraestrutura.

**Cobertura Regional vs. Disponibilidade Imediata.** No lançamento, Lambda MicroVMs está em 5 regiões. Para plataformas com requisitos de residência de dados em outras regiões (ex.: sa-east-1 para clientes brasileiros sob LGPD, ap-southeast-1 para Singapura), isso é um bloqueador real no curto prazo.

## Matriz de Decisão: Opções para Execução de Código Não Confiável

### Opção 1: Lambda MicroVMs (nova primitiva, jun/2026)

**Pros**
- Isolamento em nível de VM por sessão — elimina a classe de risco de escape entre tenants no mesmo worker
- Estado preservado entre invocações da mesma sessão — habilita agentes multi-turno sem armazenamento externo de contexto de execução
- Launch/resume sub-segundo — cold start amortizado ao longo da sessão do agente
- Zero overhead operacional de virtualização — sem gerenciar Firecracker, Kata, kernel versions ou seccomp policies
- Integração nativa com Bedrock AgentCore, IAM, CloudWatch, X-Ray

**Cons**
- Disponível em apenas 5 regiões no lançamento — bloqueador para requisitos de residência de dados em outras regiões
- Lock-in moderado na primitiva AWS — migração futura requer reescrever o runtime de execução
- Pricing não publicado no lançamento (estimativa: premium de 20-40% vs. Lambda padrão)
- Menor visibilidade interna do hypervisor — dependência da AWS para patches de segurança do nível de VM

**Verdict:** RECOMENDADA para code interpreter multi-tenant. Melhor equilíbrio entre isolamento, operação e latência para agentes com sessões multi-turno.

### Opção 2: Containers Efêmeros em ECS/EKS com gVisor ou Firecracker/Kata

**Pros**
- Controle total sobre o stack de isolamento — kernel version, seccomp profiles, network policies, cgroup limits
- Portabilidade multi-cloud — o mesmo runtime funciona em GKE, AKS ou on-premises
- Disponível em todas as regiões AWS — sem restrição geográfica
- Isolamento comprovado em produção (ex.: Google Colab, Kaggle, Judge0) com gVisor/Kata

**Cons**
- Carga operacional alta: gerenciar cluster, runtime de isolamento, patching, capacity planning, autoscaling de pods por sessão
- Cold start de container + runtime de isolamento: 2-8s para Kata/Firecracker em EKS (estimativa baseada em benchmarks públicos)
- Estado de sessão requer solução própria (Redis, EFS montado, ou manter container vivo com custo associado)
- Equipe de plataforma dedicada necessária — custo humano frequentemente supera o delta de infraestrutura
- gVisor (modo ptrace) tem overhead de CPU de 10-30% vs. execução nativa em workloads intensivos

**Verdict:** Recomendada apenas se: (a) requisito de região não coberta por Lambda MicroVMs, (b) portabilidade multi-cloud é mandatória, ou (c) equipe de plataforma já existe e o controle granular é necessário.

### Opção 3: Lambda Padrão (execução atual)

**Pros**
- Menor custo por invocação — sem overhead de isolamento adicional
- Disponível em todas as regiões — sem restrição geográfica
- Operação zero — primitiva Lambda padrão, sem configuração adicional
- Ecossistema maduro: layers, extensions, SnapStart (JVM), integrações nativas

**Cons**
- BLOQUEADOR DE SEGURANÇA: reutilização de execution environment entre invocações — variáveis globais, /tmp e conexões abertas podem vazar entre sessões do mesmo tenant
- Sem isolamento forte entre tenants distintos no mesmo worker — modelo de ameaça inaceitável para code interpreter multi-tenant
- Sem preservação de estado entre invocações de forma garantida — agentes multi-turno requerem serialização/deserialização de contexto completo a cada passo
- Firecracker subjacente não é exposto como primitiva controlável — sem garantias de isolamento por sessão de agente

**Verdict:** NÃO RECOMENDADA para execução de código não confiável multi-tenant. Aceitável apenas para ferramentas internas com código auditado e tenant único.

## Decisão de Arquitetura

**Status:** accepted

**Contexto**

A plataforma de agentes precisa executar código arbitrário gerado por modelos de IA (Python, scripts de análise, simulações financeiras) em ambiente multi-tenant, com múltiplos turnos por sessão de agente. O requisito de isolamento é equivalente ao de um sistema financeiro: dados de um tenant não podem ser acessíveis a outro tenant em nenhuma condição. O lançamento do Lambda MicroVMs em junho/2026 oferece uma primitiva que resolve os três problemas simultaneamente — isolamento VM, estado preservado e operação zero — nas regiões onde a plataforma opera primariamente (us-east-1, us-east-2, eu-west-1).

**Decisão**

Adotar Lambda MicroVMs como runtime exclusivo para execução de código não confiável (gerado por agentes ou submetido por usuários), com uma MicroVM por sessão de agente, orquestrada pelo Bedrock AgentCore. Cada sessão recebe uma MicroVM isolada que é lançada no início da sessão, preserva estado entre os turnos do agente, e é terminada ao fim da sessão ou por timeout de inatividade. Ferramentas externas (APIs financeiras, bancos de dados) são acessadas via IAM com autorização contextual por sessão — a MicroVM não tem acesso direto a credenciais de longa duração. Para regiões não cobertas pelo Lambda MicroVMs no lançamento, a Opção 2 (ECS/EKS com Kata Containers) é o fallback até expansão regional.

**Consequências**
- POSITIVO: Isolamento em nível de VM elimina a classe de risco de escape entre tenants — o blast radius de código malicioso ou mal-formado é contido dentro da MicroVM da sessão.
- POSITIVO: Estado preservado entre turnos habilita agentes que iteram sobre resultados (ex.: agente financeiro que refina uma simulação em múltiplos passos sem re-serializar contexto completo).
- POSITIVO: Zero overhead operacional de virtualização — a equipe de produto não mantém cluster, runtime de isolamento ou políticas de kernel.
- NEGATIVO: Cobertura regional limitada no lançamento — regiões fora das 5 disponíveis requerem fallback operacionalmente mais complexo (ECS/EKS com Kata).
- NEGATIVO: Lock-in moderado na primitiva AWS Lambda MicroVMs — migração futura para outro provider ou solução própria requer reescrever o runtime de execução e o modelo de sessão.
- NEGATIVO: Custo por sessão maior que Lambda padrão (estimativa: 20-40% de premium) — para plataformas com alto volume de sessões curtas, o delta de custo deve ser monitorado.

## Conectando ao Mundo Financeiro: Por Que Isolamento VM-Level Importa em FinTech

Em sistemas financeiros, o modelo de isolamento não é apenas uma decisão técnica — é um requisito regulatório. Frameworks como SOC 2 Type II, PCI DSS e, no Brasil, a Resolução BCB 4.893/2021 (gestão de riscos de TI para instituições financeiras) exigem que dados de clientes distintos sejam isolados de forma demonstrável. Um code interpreter multi-tenant sem isolamento forte não passa em uma auditoria de controles técnicos.

Considere o caso de uso concreto: um agente de IA que recebe dados de portfólio de um cliente institucional, gera código Python para calcular VaR (Value at Risk) com Monte Carlo, e executa esse código para produzir um relatório. O código gerado pelo modelo acessa dados que, por definição, são confidenciais e sujeitos a acordos de não-divulgação. Se esse código roda em um Lambda padrão com warm start, há risco real de que variáveis globais ou arquivos em `/tmp` de uma execução anterior (de outro cliente) estejam acessíveis.

Com Lambda MicroVMs, cada sessão de cliente recebe uma VM isolada. O código do agente roda dentro dessa VM. Mesmo que o código tente acessar `/proc`, variáveis de ambiente do host ou fazer syscalls não autorizados, o hypervisor Firecracker bloqueia o escape. O blast radius é a sessão — não o worker, não o tenant vizinho.

Além disso, a preservação de estado tem valor direto em workflows financeiros multi-passo: um agente que primeiro carrega dados históricos (turno 1), depois calibra parâmetros do modelo (turno 2), depois executa a simulação (turno 3) e finalmente gera o relatório (turno 4) pode fazer isso dentro da mesma MicroVM, sem re-serializar gigabytes de dados entre cada passo. Com Lambda padrão, cada turno seria uma nova invocação potencialmente em um execution environment diferente, exigindo que o agente re-carregue o contexto completo — latência e custo adicionais.

O payload assíncrono expandido para 1 MB (também lançado em junho/2026) complementa esse cenário: datasets de entrada maiores podem ser passados diretamente para a MicroVM sem precisar de um estágio intermediário de S3 para inputs pequenos-médios.

## Arquitetura: Execução de Código por Agente com Lambda MicroVMs

Fluxo de execução de código não confiável gerado por agente de IA: do usuário ao Bedrock AgentCore, passando pela MicroVM isolada por sessão, até ferramentas externas com autorização contextual e telemetria centralizada.

### 👤 Client / Tenant

- User / App Tenant A or B (user)

### 🧠 AI Orchestration — Bedrock

- Bedrock AgentCore Orchestrator (ai)
- Foundation Model (Claude / Bedrock) (ai)

### 🔐 Security & AuthZ

- IAM Per-session role (STS AssumeRole) (security)
- Secrets Manager Tool credentials (security)

### ⚡ Execution — Lambda MicroVMs (per session)

- Lambda MicroVM Session: Tenant A [Firecracker VM] State preserved (compute)
- Lambda MicroVM Session: Tenant B [Firecracker VM] State preserved (compute)

### 🛠️ Tools & Data (Authorized Access)

- S3 Portfolio data (tenant-scoped prefix) (storage)
- Financial API (market data, risk engine) (external)
- RDS / Aurora Client records (row-level security) (data)

### 📊 Observability

- CloudWatch Logs + Metrics Session alarms (security)
- X-Ray Distributed trace per session (security)

### Fluxos

- user -> agentcore: Requisição + contexto de sessão
- agentcore -> llm: Prompt + histórico de turno
- llm -> agentcore: Código gerado + tool calls
- agentcore -> iam: AssumeRole por sessão
- agentcore -> microvma: Launch/Resume MicroVM
+ código + payload (≤1MB)
- agentcore -> microvmb: Sessão isolada
Tenant B
- microvma -> s3: Acesso via role temporária
(tenant-scoped)
- microvma -> finapi: API call autenticado
(Secrets Manager)
- microvma -> rds: Query com RLS
por tenant_id
- microvma -> cw: Logs + métricas de sessão
- microvma -> xray: Trace distribuído
- microvma -> agentcore: Resultado de execução
(output + estado preservado)
- agentcore -> user: Resposta do agente

## O Que Essa Decisão Não Resolve: Limites e Riscos Residuais

Ser honesto sobre o que uma decisão arquitetural não resolve é parte do trabalho sênior. Lambda MicroVMs resolve o isolamento de execução — mas não resolve tudo.

**Prompt Injection ainda é um vetor.** Se o modelo gera código que exfiltra dados via canal legítimo (ex.: escreve dados de portfólio em um arquivo e faz upload para um S3 bucket controlado pelo atacante via uma chamada de API autorizada), o isolamento da VM não ajuda. A defesa aqui é autorização contextual granular nas ferramentas: a MicroVM tem permissão de escrever apenas no prefixo S3 do tenant, não em buckets arbitrários. Isso requer que o Bedrock AgentCore implemente scoping de permissões por sessão, não apenas por função Lambda.

**Denial of Wallet é um risco real.** Uma MicroVM por sessão com estado preservado significa que sessões longas ou zumbis acumulam custo. Um agente mal-configurado (ou um usuário malicioso que força sessões longas) pode gerar custo inesperado. Mitigação: timeout de sessão hard limit (ex.: 30 minutos de inatividade), alarme CloudWatch em sessões com duração > P99 esperado, e circuit breaker no AgentCore para sessões com consumo de tokens anômalo.

**Visibilidade do hypervisor é limitada.** Você não tem acesso ao nível de Firecracker para inspecionar o que acontece dentro da VM além dos logs que o código produz. Em um incidente de segurança, a forensics é limitada ao que o CloudWatch e X-Ray capturam. Para plataformas com requisitos de auditoria forense detalhada, isso pode ser insuficiente — nesse caso, a Opção 2 (EKS com Kata) dá mais visibilidade via eBPF/Falco.

**Cobertura regional é um risco de roadmap.** A AWS pode expandir Lambda MicroVMs para outras regiões rapidamente, ou pode levar trimestres. Plataformas com clientes em regiões não cobertas precisam manter o fallback ECS/EKS operacional — o que significa que a redução de carga operacional prometida pela Opção 1 é parcial até a expansão regional completa.

**O modelo de preço ainda não está publicado.** Toda análise de custo aqui é estimativa. Antes de comprometer workloads de alto volume com Lambda MicroVMs, é necessário validar o pricing real com a AWS e fazer um modelo de custo baseado em sessões/dia, duração média e compute por sessão.

## Lente do AWS Well-Architected

- **security**: VM-level isolation por sessão elimina a classe de risco de escape entre tenants. IAM com STS AssumeRole por sessão garante princípio de menor privilégio. Autorização contextual nas ferramentas (prefixo S3 por tenant, RLS no banco) fecha o vetor de exfiltração lateral via canal legítimo. Dependência de patches do hypervisor pela AWS é aceitável dado o histórico do Firecracker.
- **reliability**: Cobertura regional limitada (5 regiões no lançamento) requer fallback ECS/EKS para outras regiões. Timeout de sessão e terminação explícita de MicroVM são necessários para evitar sessões zumbi. O modelo de resume sub-segundo reduz risco de timeout em agentes multi-turno.
- **performance**: Cold start amortizado ao longo da sessão — o custo de launch da MicroVM é pago uma vez por sessão, não por turno. Resume sub-segundo entre turnos é comparável ao warm start do Lambda padrão. Para sessões com muitos turnos curtos, o modelo é mais eficiente que re-inicializar contexto a cada invocação.
- **sustainability**: MicroVMs efêmeras por sessão evitam desperdício de compute de containers ociosos. Terminação explícita ao fim da sessão é necessária para evitar custo e consumo energético de sessões zumbi.

> **Minha Leitura Sênior:** Lambda MicroVMs é a primitiva que eu esperava há anos para resolver o problema do code interpreter multi-tenant sem operar virtualização própria. O Firecracker sempre esteve lá, mas como detalhe de implementação interno do Lambda — não como superfície controlável. Agora é uma primitiva de primeira classe, e isso muda o cálculo para qualquer plataforma que precise executar código não confiável.

O que me convence a recomendar sem hesitação para o caso de uso descrito: o isolamento VM-level não é um 'nice to have' em multi-tenant com dados financeiros — é o piso mínimo aceitável. E a preservação de estado é o diferencial real para agentes multi-turno: a alternativa de serializar/deserializar contexto completo entre cada turno não é apenas mais lenta, é arquiteturalmente errada — você está pagando para mover dados que deveriam estar em memória.

O que me faz recomendar com ressalvas: o pricing não está publicado, a cobertura regional é limitada, e o lock-in é real. Minha postura prática: adotar Lambda MicroVMs para as regiões cobertas, manter o fallback ECS/EKS operacional para as demais, e revisar a decisão em 6 meses quando o pricing estiver claro e a expansão regional estiver mais avançada.

Um detalhe que vejo ser subestimado: a autorização contextual nas ferramentas é tão importante quanto o isolamento da VM. Uma MicroVM isolada com permissões IAM excessivamente amplas ainda permite exfiltração via canal legítimo. O isolamento da VM contém o escape — mas o scoping de permissões por sessão contém o abuso de ferramentas. Você precisa dos dois. O Bedrock AgentCore precisa ser configurado para emitir roles temporárias com escopo mínimo por sessão, não roles de função Lambda com acesso amplo.

Para equipes em FinTech: essa arquitetura passa no modelo de ameaça de uma auditoria SOC 2 para isolamento de dados de clientes em execução de código — desde que você documente o modelo de autorização contextual e o timeout de sessão. Isso é o que vai aparecer no questionário do auditor.

## Veredicto

Lambda MicroVMs é a escolha correta para execução de código não confiável em plataformas de agentes multi-tenant, nas regiões onde está disponível. A decisão não é sobre hype de IA — é sobre um problema de engenharia de segurança concreto (isolamento entre tenants em execução de código arbitrário) que agora tem uma solução serverless de primeira classe, sem o custo operacional de gerenciar virtualização própria.

O trade-off de custo (estimativa: 20-40% de premium vs. Lambda padrão) é justificado pelo isolamento VM-level e pela preservação de estado — especialmente em contextos financeiros onde o custo de um incidente de vazamento de dados entre tenants supera em ordens de grandeza qualquer economia de compute. A cobertura regional limitada no lançamento é o único bloqueador real, e requer um fallback ECS/EKS operacional para regiões não cobertas.

A lição arquitetural mais ampla: quando uma nova primitiva de plataforma resolve simultaneamente um problema de segurança, um problema de estado e um problema operacional — sem introduzir complexidade adicional — a adoção é a decisão racional. Lambda MicroVMs faz exatamente isso para o problema do code interpreter multi-tenant. A ressalva é validar o pricing real antes de comprometer workloads de alto volume, e nunca tratar o isolamento da VM como substituto para autorização contextual granular nas ferramentas que o agente pode invocar.

## Referências

- [AWS — Lambda MicroVMs (What's New, Jun/2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms/)
- [AWS — Lambda Managed Instances (Region Expansion, Jun/2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-managed-instances-region-expansion/)
- [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
- [AWS Lambda — Product Page](https://aws.amazon.com/lambda/)

## Fontes do caso

- [AWS — Lambda MicroVMs (What's New, jun/2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms/)
- [AWS — Lambda Managed Instances](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-managed-instances-region-expansion/)
- [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)
- [AWS Lambda](https://aws.amazon.com/lambda/)