Durante grande parte de 2024 e início de 2025, a conversa sobre agentes de IA foi dominada por capacidades: modelos melhores, mais ferramentas, contexto mais longo, workflows mais autônomos.
Agora a conversa está mudando.
A pergunta já não é somente:
“O que o agente pode fazer?”
A pergunta que os times de plataforma e segurança estão começando a fazer é muito mais importante:
“O que acontece quando o agente faz algo que não deveria?”
Esse deslocamento de foco está impulsionando uma nova arquitetura operacional que aparece cada vez mais em ferramentas enterprise, frameworks open source e documentação de segurança:
agentes com containment-first
A ideia é simples:
assumir desde o design que o agente eventualmente vai errar, se desviar, alucinar ou abusar de permissões.
E construir o sistema ao redor dessa realidade.
O problema: agentes não são mais chatbots
Um chatbot tradicional produz texto.
Um agente moderno:
- executa comandos
- modifica arquivos
- chama APIs
- interage com infraestrutura
- usa credenciais
- faz deploy de código
- executa testes
- opera navegadores
- toma decisões multi-etapas
Isso o torna uma entidade operacional.
E entidades operacionais precisam de limites.
A maioria dos incidentes recentes envolvendo agentes tem o mesmo padrão de fundo:
- permissões muito amplas
- isolamento insuficiente
- ferramentas sem restrições
- contexto contaminado
- execução não auditada
O problema não é necessariamente que o modelo seja “ruim”.
O problema é que estamos conectando sistemas probabilísticos a superfícies de execução reais.
Por que “prompt engineering” não é suficiente
Por muito tempo, muitas organizações trataram a segurança de agentes como um problema de prompt:
NÃO MODIFIQUE PRODUÇÃO
NÃO DELETE ARQUIVOS
NÃO EXECUTE COMANDOS PERIGOSOS
Isso funciona até deixar de funcionar.
Porque prompts não são limites de segurança.
São instruções probabilísticas.
E quando:
- o contexto muda
- uma ferramenta responde diferente
- o agente entra em loops
- aparece prompt injection
- o raciocínio se desvia
…as instruções leves deixam de ser suficientes.
A indústria está começando a aceitar uma realidade desconfortável:
agentes precisam de restrições técnicas reais, não apenas regras textuais.
O que significa “containment-first”
Containment-first significa desenhar o ambiente operacional assumindo que o agente pode se comportar de maneira incorreta.
Isso muda completamente a arquitetura.
Em vez de:
Modelo → Ferramentas → Produção
o padrão passa a ser algo mais parecido com:
Modelo
↓
Camada de Política
↓
Sandbox / Runtime isolado
↓
Ferramentas limitadas
↓
Aprovação humana (quando aplicável)
↓
Sistemas reais
A segurança deixa de depender de “esperar que o agente entenda”.
Começa a depender de:
- isolamento
- permissões mínimas
- observabilidade
- recuperação
- limites de execução
Exatamente como em infraestrutura distribuída tradicional.
O padrão mais importante: permissões mínimas
A maioria dos agentes atuais tem acesso demais.
Exemplos comuns:
- acesso completo ao filesystem
- acesso total ao repo git
- tokens de cloud reutilizados
- credenciais compartilhadas
- navegação web irrestrita
- shells sem sandbox
Containment-first inverte essa lógica.
O agente recebe:
- apenas as ferramentas necessárias
- apenas os diretórios necessários
- apenas as permissões necessárias
- apenas pelo tempo necessário
Não diferente de como já operamos:
- containers
- IAM roles
- Kubernetes service accounts
- credenciais temporárias
A diferença é que agora a entidade que consome essas permissões é um sistema probabilístico.
Sandboxes: o novo runtime padrão
Uma das mudanças mais visíveis de 2026 é a adoção acelerada de ambientes isolados para agentes.
Cada vez mais ferramentas:
- executam código dentro de containers efêmeros
- isolam filesystem
- bloqueiam networking por padrão
- separam credenciais
- limitam persistência
Porque um agente que:
- gera código
- o executa
- observa resultados
- reitera automaticamente
…sem sandbox, é basicamente RCE assistida por IA.
E isso muda completamente o modelo de risco.
O problema de prompt injection muda tudo
Os sistemas agênticos introduzem uma superfície nova:
prompt injection indireto
Exemplo:
- o agente navega uma página
- a página contém instruções ocultas
- o modelo as interpreta como contexto válido
- o agente executa ações não previstas
Isso não é teórico.
É exatamente o tipo de ataque que aparece naturalmente quando:
- modelos consomem conteúdo externo
- ferramentas têm capacidade de execução
- o contexto não é isolado
Containment-first assume que eventualmente vai ocorrer.
Por isso:
- ferramentas sensíveis requerem aprovação
- os outputs externos são sanitizados
- as capacidades críticas são separadas
- agentes não recebem acesso irrestrito
Observabilidade: a peça que faltava
Outro padrão forte:
execution tracing
Os times querem saber:
- o que o agente decidiu
- qual ferramenta usou
- que contexto viu
- quais outputs produziu
- quais comandos executou
- o que falhou
- por que tomou uma ação
Isso está impulsionando:
- logs estruturados
- tracing de ferramentas
- replay de sessões
- snapshots de contexto
- auditoria de decisões
Em outras palavras:
observabilidade de IA começa a se parecer muito com observabilidade de sistemas distribuídos.
Agentes já estão sendo desenhados como jobs distribuídos
OpenAI, Anthropic, LangGraph, OpenHands e outros ecossistemas estão convergindo para padrões similares:
- retries
- checkpoints
- state persistence
- lifecycle APIs
- resumable execution
- workflow durability
Isso não é coincidência.
A indústria está descobrindo que agentes não são “UX de chat”.
São runtimes operacionais.
E runtimes operacionais precisam de:
- controle
- recuperação
- limites
- isolamento
O erro mais comum hoje
Muitos times ainda fazem deploy de agentes assim:
LLM + tools + production access
sem:
- sandboxes
- limites de permissões
- camada de política
- aprovação humana
- observabilidade séria
Isso funciona em demos.
Não necessariamente sobrevive contato com produção.
O que os times mais maduros estão fazendo
Os padrões que mais aparecem hoje:
1. Tool gating
O agente pode:
- ler arquivos
mas não:
- escrever
- executar
- fazer deploy
sem aprovação explícita.
2. Sandboxes efêmeros
Cada sessão:
- container novo
- filesystem isolado
- networking limitado
- cleanup automático
3. Credenciais temporárias
Nada persistente.
Tokens:
- scopeados
- rotativos
- revogáveis
4. Runtime policies
Camadas explícitas de regras:
- quais ferramentas existem
- quando podem ser executadas
- quais comandos são proibidos
- quais caminhos são válidos
5. Human-in-the-loop
As ações sensíveis:
- requerem aprovação
- ficam auditadas
- podem ser revertidas
A dimensão LATAM
Para times na América Latina, containment-first tem uma vantagem importante:
reduz risco operacional sem exigir organizações gigantes.
Muitos times regionais:
- operam enxutos
- têm menos margem para incidentes
- trabalham com infraestrutura compartilhada
- gerenciam budgets de cloud sensíveis
Nesse contexto:
- um agente com permissões excessivas
- um loop runaway
- um deploy incorreto
- uma filtração acidental
…podem ter impacto desproporcional.
Containment-first permite adotar automação de IA sem assumir níveis de risco difíceis de absorver operacionalmente.
A mudança cultural
Há uma transição cultural interessante ocorrendo.
Por anos:
- mais autonomia
- menos fricção
- mais acesso
- mais ferramentas
eran vistos como progresso natural para agentes.
Agora começa a emergir outra filosofia:
os melhores agentes não são os mais livres.
São os mais controláveis.
O que os times deveriam fazer hojeAntes de implantar agentes em workflows reais:
Revisar permissões
- O que o agente realmente pode tocar?
- O que acontece se ele cometer um erro?
Isolar execução
- Containers
- VMs efêmeras
- Filesystems temporários
Adicionar observabilidade
- logs
- tracing
- replay
- auditoria
Introduzir camadas de política
- limites explícitos
- regras técnicas
- não apenas prompts
Desenhar rollback
- reversão rápida
- checkpoints
- recovery workflows
Veredicto
Agentes com containment-first provavelmente se tornarão o padrão dominante de segurança para IA operacional.
Não porque os modelos piorem.
Mas porque os agentes estão deixando de ser assistentes passivos e começando a operar sistemas reais.
E qualquer sistema que:
- executa ações
- usa ferramentas
- modifica infraestrutura
- toma decisões autônomas
…eventualmente precisa das mesmas propriedades que exigimos do resto de nossa infraestrutura:
- isolamento
- observabilidade
- controle
- recuperação
- governança
A indústria finalmente está começando a tratar agentes como o que realmente são: