Audiência: Engenheiros sênior / segurança / equipes de plataforma
Formato: Opinião + padrões de arquitetura
Contexto: Governança de IA em desenvolvimento
TL;DR
- Agentes de código já não são apenas ferramentas — são atores com permissões
- O problema principal não é o que geram, mas o que podem executar
- Sem isolamento (sandboxing), o risco passa de código incorreto para execução perigosa
A mudança silenciosa
Durante o último ano, o foco esteve em:
- qualidade do código gerado
- velocidade
- produtividade
Mas a mudança real é outra:
os agentes agora interagem com seu ambiente
- executam comandos
- leem/escrevem arquivos
- interagem com Git
Isso muda completamente o modelo de risco.
Caso recente: execução via Git hooks
Uma vulnerabilidade recente em ferramentas de IA coding permitiu que:
- repositórios aninhados incluíssem hooks maliciosos
- o agente executasse operações Git
- o código fosse executado sem visibilidade clara
Não é um bug isolado.
É um sintoma.
O problema real: permissões implícitas
Muitos agentes operam sob suposições perigosas:
- acesso completo ao filesystem
- execução de shell sem restrições
- confiança em repositórios externos
Em outras palavras:
demasiado poder, muito pouca fricção
O erro conceitual
Estamos tratando agentes como se fossem:
- autocomplete avançado
Quando na verdade são mais próximos a:
- processos automatizados com privilégios
E isso requer outro modelo mental.
Padrão correto: sandbox primeiro
Antes de pensar em prompts, pense em isolamento.
1. Isolamento de execução
- contêineres efêmeros
- ambientes sem acesso direto ao host
2. Permissões explícitas
Nada implícito.
Exemplo:
permissions:
filesystem: read-only
git: restricted
shell: disabled
3. Auditoria
Tudo o que o agente faz deve ser:
- registrado em log
- rastreável
4. Confirmações humanas
Para ações sensíveis:
- execução de scripts
- mudanças em infraestrutura
- operações destrutivas
Arquitetura recomendada
Em lugar de:
agente com acesso total
Use:
agente → camada de controle → ambiente isolado
Fluxo:
- agente propõe ação
- camada valida permissões
- execução em sandbox
- resultado auditado
Trade-offs
Sim, há fricção:
- menor velocidade
- mais configuração
Mas o benefício:
- controle
- segurança
- previsibilidade
O que as equipes devem fazer hoje
Passo 1
Mapear o que os agentes podem fazer hoje:
- comandos
- acessos
- integrações
Passo 2
Reduzir permissões por padrão
Passo 3
Introduzir sandboxing progressivo
Passo 4
Definir políticas claras
Perspectiva de engenharia
Isso não é paranoia.
É evolução natural.
Cada vez que uma ferramenta ganha capacidade de execução:
precisa de limites mais claros
Veredicto
O problema não é que agentes escrevam código.
É que agora o executam.
Reflexão final
A próxima geração de ferramentas de desenvolvimento não vai se diferenciar por:
- quão bem geram código
Mas por:
- quão bem controlam o que esse código pode fazer
Porque em 2026, o risco não é o código incorreto.
É o código correto sendo executado no contexto errado.