Por que um Staff Engineer está estudando AI Security

Pessoal, a pergunta do meu trabalho mudou.

Antes: como eu faço esse agente entregar mais rápido?

Agora: se esse agente tem ferramenta, o que ele pode quebrar, e quem assume o risco?

A trava que você cola no PR amanhã: sete perguntas antes de dar tool access a um agente. Se alguma resposta ficar vaga, a tool não entra.

Não escrevo como expert. Em agosto de 2026 comecei Defesa Cibernética na Impacta. Este post é o marco zero público.

Tabela de Conteúdo

• 1. A pergunta mudou
• 2. Texto errado é uma coisa. Ação indevida é outra
• 3. O caso que eu já rodei. O rm é o desenho
• 4. Sete perguntas antes da tool entrar no agente
• 5. Qual trava você colocaria primeiro?

1. A pergunta mudou

Eu passo o dia em cima de sistema sob pressão: confiabilidade, observabilidade, incidente, decisão que precisa continuar fazendo sentido quando eu saio da sala. Nos últimos tempos, passei a operar de verdade com LLM, agente, MCP e memória/RAG.

Staff, pra mim, nunca foi aparecer em tudo. Foi construir condições para que as squads tomem boas decisões sem depender da minha memória.

Isso cria um reflexo meio chato: olhar pra demo bonita e perguntar pelo modo de falha.

• O webhook falha como?
• O retry duplica o quê?
• Essa métrica explica impacto ou só joga stacktrace na tela?
• Tem kill switch ou a gente só torce?

Agora esse mesmo reflexo precisa olhar pra prompt, ferramenta, memória e permissão de agente. Não porque eu mudei de carreira da noite pro dia. Porque a unidade de risco mudou.

2. Texto errado é uma coisa. Ação indevida é outra

Quando o modelo só gera texto, o estrago costuma ser contido: chato, caro às vezes, mas contido. Alucinação, vazamento por descuido, resposta ruim.

Quando o mesmo modelo ganha ferramenta (ler arquivo, chamar API, abrir PR, mexer em dado, acionar automation), o jogo muda.

Aí o risco deixa de ser só “falou besteira”. Passa a ser:

• fez uma ação irreversível com confiança alta demais;
• tinha permissão bem maior do que o trabalho pedia;
• puxou pro contexto uma informação que não deveria sair dali;
• conectou um MCP/skill poderoso sem auditoria decente.

Isso não é paranoia de blog. A OWASP chama o desenho de Excessive Agency (LLM06:2025): tool demais, permissão demais, autonomia demais. O NIST AI RMF fala a mesma coisa em linguagem de governança. Eu estudo pelos dois. O gate mais abaixo é o dia 1 no desk.

A leitura de Staff que eu carrego é bem direta:

Acelerar agente sem olhar permissão é otimizar velocidade com o cinto solto.

3. O caso que eu já rodei. O rm é o desenho

O caso meu no ar não é shell em prod. É texto.

No 09 eu quase mandei 23 “vulnerabilidades” pra maintainer. XSS fantasma, CORS, um SVG. Volume. Se eu fosse o cara do outro lado da issue, eu levaria isso a sério? Parei. O que vingou foi hardening público e silêncio quando a invariante segurou. O denominador está lá. Aqui não reconto os findings.

No gate, isso é pergunta 1 e pergunta 7. A ação irreversível era abrir issue com ruído. O que impediu o dano fui eu na porta, não o modelo. HITL. Blast radius do texto.

Este post é a outra ponta. Não o que o agente afirma. O que ele pode executar.

Desenho do gate. Pedagógico. Não é o caso acima.

você:     limpa os temporários da pasta de build
agente:   rm -rf ./build ../tmp
          (prestativo. path saiu da pasta. token ainda chama API)
você:     quase dá enter

Sem allowlist de path, sem dry-run, sem humano no rm, o modelo não “alucinou um ensaio”. Montou o rm na leitura generosa de “temporários”.

O gate, preenchido neste desenho. Resposta vaga = a tool não entra.

#	Pergunta	Neste desenho	Entra?
1	Ação irreversível mais cara	rm no tree. Token que chama API.	Não
2	Menor escopo que ainda resolve	Token amplo “pra não travar”.	Não
3	Precisa escrever, ou leitura basta?	Escrita porque senão não demo.	Não
4	O que no contexto não deveria sair	Nota interna misturada no ticket.	Não
5	Como detecta abuso ou erro	Sem dry-run. Sem log do comando.	Não
6	Kill switch, com dono	Ninguém nomeado pra revogar o token.	Não
7	Se alucinar a intenção, o que impede o dano	Sem allowlist de path. Sem HITL no rm.	Não

Sete vagos. A tool não entra. LLM06 neste caso não é paper. É essa tabela. O caso meu, com issue, já está no 09: mesma disciplina, outra porta.

4. Sete perguntas antes da tool entrar no agente

Copia, cola no PR da automação, e não segue em frente sem responder. Cópia solta: gist do gate.

## Tool access gate (agente)

1. Qual é a ação irreversível mais cara que essa tool permite?
   (apagar, pagar, publicar, exfiltrar, merge, deploy)
2. Qual é o menor escopo de permissão que ainda resolve o trabalho?
3. O agente precisa de escrita, ou leitura bastaria na maior parte do tempo?
4. O que entra no contexto (RAG/memória) que não deveria sair dali?
5. Como eu detecto abuso ou erro? (log, audit trail, alerta, dry-run)
6. Qual é o kill switch? (revogar token, desligar tool, pausar automation)
7. Se o modelo alucinar a intenção, o que ainda impede o dano?
   (allowlist, HITL, confirmação humana, sandbox)

No fundo, as sete perguntas tentam aplicar princípios antigos (menor privilégio, redução de blast radius, auditabilidade, defesa em profundidade) a uma interface nova: o agente. Capability boundaries e human-in-the-loop entram aí sem drama.

Se alguma resposta ficar vaga

Regra de bolso:

Se alguma resposta ficar vaga, a tool não entra no agente.

Leitura vs escrita é a ramificação que mais gente pula. “Precisa escrever porque senão não demo” não é menor escopo. É conveniência. Kill switch sem dono também não conta: se ninguém sabe quem revoga o token, você não tem kill switch.

É a trava mínima pra gente não confundir produtividade com negligência.

5. Qual trava você colocaria primeiro?

Este texto para no gate. O dia 1. O caso que eu já rodei está no H3, no 09. RAG, MCP e fine-tuning como camada é o 10. Sem calendário.

Filtro que eu uso, pra não trocar de hobby toda semana:

Isso me deixa mais confiável com agente, ou só me distrai com logo novo?

Você já viu um agente receber mais permissão do que precisava? O que colocaria como primeira trava: allowlist, sandbox, aprovação humana ou token restrito?

Caso concreto fica opcional. O gate preenchido no rm já dá pra responder. O 09 também.