A pergunta principal do meu trabalho como engenheiro mudou de figura nos últimos tempos.
Antes, a pergunta era:
"Como faço esse agente de IA codar e entregar tarefas mais rápido?"
Hoje, a pergunta é:
"Se esse agente tem acesso a ferramentas, o que ele pode quebrar de irreversível e quem assume o risco quando algo der errado?"
Como Staff Engineer, meu papel nunca foi aparecer em todas as reuniões ou ditar regras autoritárias. Meu papel é construir as condições para que os times tomem decisões técnicas excelentes e seguras mesmo quando eu não estiver na sala.
Isso desenvolve um reflexo quase instintivo: olhar para qualquer demonstração mágica de tecnologia e procurar imediatamente o modo de falha.
Neste artigo, vou explicar por que a fronteira entre produtividade e desastre em sistemas com agentes é a segurança, e compartilhar um checklist prático com sete perguntas inegociáveis antes de dar acesso a ferramentas para qualquer IA.
1. Texto Errado é Chato; Ação Indevida é Catastrófica
Quando um modelo de linguagem (LLM) apenas gera texto em uma janela de chat, o dano costuma ser contido: uma resposta truncada, uma explicação imprecisa ou uma alucinação de sintaxe que o desenvolvedor bate o olho e descarta.
Mas quando o mesmo modelo ganha ferramentas de execução (acesso ao terminal, permissão para rodar scripts, consultar bancos de dados de produção e chamar APIs externas), a escala de risco muda drasticamente:
[ Modelo Gerador de Texto (Risco Baixo) ]
Você ──> Prompt ──> LLM ──> Resposta com alucinação ──> Você corrige no chat.
Blast Radius: ZERO.
[ Agente com Ferramentas Desgovernadas (Risco Crítico) ]
Você ──> Prompt: "Limpa a pasta temporária"
│
▼
LLM chama ferramenta: `exec("rm -rf ./build ../tmp")`
│
▼ (Sem sandbox, sem confirmação humana)
💥 APAGOU ARQUIVOS DO PROJETO E DERRUBOU A INSTÂNCIA!
[!NOTE]
Cena didática. Não é telemetria: O exemplo de terminal acima ilustra didaticamente o conceito de Blast Radius descontrolado. Na telemetria real de incidentes corporativos com agentes de código, o dano raramente é um comando de terminal óbvio. Ele surge de forma silenciosa: chamadas recursivas a APIs pagas por alucinação de loop, vazamento de chaves e dados sensíveis em traces de ferramentas, ou mutação de bancos relacionais por scripts sem cláusula de tenant.
A OWASP já catalogou essa vulnerabilidade como uma das maiores ameaças do setor: Excessive Agency (LLM06 - Agência Excessiva). Isso acontece quando damos ao agente funcionalidades amplas demais, permissões excessivas ou autonomia irrestrita sem travas de contenção.
Acelerar a entrega de software com agentes sem olhar para permissões de segurança é o equivalente a pisar fundo no acelerador em uma curva fechada com o cinto de segurança solto.
2. O Tool Access Gate: 7 Perguntas Antes de Conectar Ferramentas
Para evitar que a empolgação com automações gere incidentes de segurança, criei um portão de checagem obrigatório.
Se você estiver desenhando um agente para a sua equipe, responda a estas sete perguntas antes de colocar a ferramenta no ar:
┌──────────────────────────────────────────────┐
│ Tool Access Gate de Segurança │
└──────────────────────┬───────────────────────┘
│
1. Ação Irreversível ───────────────┼──> Qual o pior dano possível? (drop, delete, pay)
2. Menor Escopo ───────────────┼──> Permissão de escrita realmente necessária?
3. Leitura vs Escrita───────────────┼──> Leitura basta em 90% do tempo?
4. Vazamento de Dados───────────────┼──> Algum dado sensível pode vazar no contexto?
5. Auditoria & Logs ───────────────┼──> Como detectamos desvios e abusos?
6. Kill Switch ───────────────┼──> Quem é o dono nomeado para revogar o token?
7. Sandbox & HITL ───────────────┴──> Se o modelo alucinar, o que impede o desastre?
A Regra de Ouro:
Se qualquer uma dessas 7 respostas ficar vaga ou sem dono definido, a ferramenta NÃO tem autorização para entrar no agente.
3. Menor Privilégio na Prática com Agentes
Princípios tradicionais de segurança da informação (como o Princípio do Menor Privilégio e Defesa em Profundidade) continuam mais vivos do que nunca:
| Prática Amadora | Prática de Engenharia Madura |
|---|---|
| Dar chave de API com permissão de Admin "para não travar o teste" | Criar tokens com escopo cirúrgico e permissão apenas de leitura |
| Deixar o agente rodar qualquer comando no shell do sistema | Usar allowlist estrita de comandos (ex: apenas git status e go test) |
| Conectar o agente ao banco de dados principal de produção | Conectar a réplicas Read-Only com dados mascarados |
| Permitir merge automático em branches principais | Exigir sempre Human-in-the-Loop (aprovação humana explícita) |
Para triar a intenção do usuário e classificar riscos localmente sem expor dados confidenciais, você pode usar ferramentas locais em Go como o Downshift (harness-downshift), decidindo na sua própria máquina se o comando exige checagens extras antes de acionar modelos via OpenRouter.
Referências Técnicas Canônicas
Para quem deseja se especializar na interseção entre Inteligência Artificial e Segurança da Informação:
- 📖 Padrão Canônico OWASP: OWASP Top 10 for Large Language Model Applications (LLM06: Excessive Agency) - O guia internacional sobre riscos de autonomia descontrolada, permissões excessivas e falta de contenção em agentes de IA.
- 📖 Framework Governamental: NIST AI Risk Management Framework (AI RMF 1.0) - Framework formal do NIST para governança, mensuração e mitigação de riscos sistêmicos em sistemas de IA.
- 📖 Engenharia Staff: Will Larson: Staff Engineer (Leadership beyond the management track) - A referência canônica sobre liderança técnica, gestão de risco organizacional e autonomia com alinhamento.
A Pergunta que Fica
Segurança em IA não é sobre barrar a inovação ou ser o departamento do "não". É sobre garantir que a inovação seja sustentável, resiliente e confiável.
Quando você olha para os agentes e automações rodando na sua empresa hoje:
Eles operam com cinto de segurança apertado ou estão a um comando de distância de um incidente grave?
Adote o Tool Access Gate e construa o futuro da inteligência artificial com governança e responsabilidade.
Top comments (0)