Pessoal, deixa eu ser sincero desde o começo.
Eu não estou escrevendo isto como expert em AI Security. Estou escrevendo no ponto em que a pergunta do meu trabalho 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.
Nos últimos meses, percebi que eu já estava ajudando times a acelerar uso de agentes, MCPs e automações, mas ainda não tinha a mesma segurança pra revisar permissões, superfícies de ataque e fluxo de dados. Eu sabia avaliar arquitetura e operação; precisava ampliar essa lente pra segurança de sistemas agentic.
Aí a pergunta na minha cabeça virou outra.
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?
É sobre isso que eu quero estudar em público. Com uma trava de bolso que você já pode usar amanhã.
O reflexo chato (e útil) do Staff
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.
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. É o tipo de coisa que a indústria já tenta organizar em mapa público. Eu uso como âncora de estudo:
A leitura de Staff que eu carrego é bem direta:
Acelerar agente sem olhar permissão é otimizar velocidade com o cinto solto.
Um cenário sintético (pra ficar concreto)
Imagina um agente de coding com:
- shell no repo;
- token de API “amplo pra não travar”;
- memória/RAG misturando nota interna com contexto do ticket.
Você pede: “limpa os arquivos temporários da pasta de build”.
O modelo interpreta “temporários” com generosidade demais. Sem allowlist de path, sem dry-run, sem confirmação humana pra rm… ele pode ir bem além do que você imaginou.
Isso não é case de empresa. É um exemplo sintético do tipo de falha que aparece quando a gente otimiza fluidez e esquece freio.
Se eu tivesse passado o checklist abaixo antes de dar shell + token amplo, pelo menos três perguntas teriam travado o desenho: ação irreversível, menor escopo, e o que impede o dano se a intenção for alucinada.
Artefato: 7 perguntas antes de dar ferramenta a um agente
Copia, cola no PR da automação, e não segue em frente sem responder.
## 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 e defesa em profundidade a uma interface nova: o agente. Capability boundaries e human-in-the-loop entram aí sem drama.
Regra de bolso:
Se alguma resposta ficar vaga, a tool não entra no agente.
É a trava mínima pra gente não confundir produtividade com negligência.
O que vem a seguir
Este é o primeiro texto da minha jornada pública em AI Security. Nos próximos, quero documentar labs, threat models de agentes, MCPs, RAG, permissões e os erros que aparecerem no caminho.
Filtro pessoal que eu tô usando:
Isso me aproxima de ser alguém confiável em arquitetura segura de agentes, ou só me distrai com ferramenta nova?
Privacidade e anonimização vêm antes da vontade de postar rápido. Se você é forte em engenharia, cético com hype e curioso com risco de agente, essa conversa é pra gente.
Pergunta pra comunidade
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?
Se tiver um caso concreto, ainda melhor: o que a tool podia fazer e qual guarda você colocou depois. 🤝
Top comments (0)