RRodrigo M. Reis
ConsultoriaMétodoRobôsMateriaisBlogSobre
Área do ClienteMaterial grátis
R

Rodrigo Munhoz Reis

Vibecoding com Engenharia. Construir com IA, rápido — mas com rigor de engenheiro.

ConsultoriaMétodoRobôsMateriaisBlogSobreÁrea do Cliente
LinkedInInstagram
© 2026 Rodrigo Munhoz Reis. Todos os direitos reservados.Política de Privacidade

Segurança

Como limitar o que um agente pode tocar no seu sistema

Escopo de agente não é instrução no prompt. É permissão no sistema. A diferença entre as duas coisas é o que separa limite de pedido educado.

Rodrigo Munhoz Reis· 08 de setembro de 2026· 3 min de leitura
Como limitar o que um agente pode tocar no seu sistema

Resumo em 3 linhas

Limitar um agente exige separar duas camadas que costumam ser confundidas: a instrução, que é um pedido, e a permissão, que é uma barreira. Instrução pode ser mal interpretada ou contornada por uma formulação inesperada; permissão negada não executa. O desenho seguro combina credencial dedicada com o mínimo necessário, exposição por operação em vez de sistema inteiro, ambiente separado no início e lista explícita de ações que exigem aprovação humana.

Neste artigo

  • Instrução e permissão são camadas diferentes
  • Camada 1: credencial própria
  • Camada 2: o mínimo, listado
  • Camada 3: expõe operação, não sistema
  • Camada 4: ambiente separado no começo
  • Camada 5: lista do que exige aprovação
  • O teste que fecha a configuração

Tem uma confusão que aparece em quase toda configuração de agente, e ela é a origem da maioria dos acidentes.

Escrever no prompt "não apague nada" não é um limite. É um pedido.

Instrução e permissão são camadas diferentes

Instrução é o que você pede. Depende de interpretação, e interpretação varia com a formulação do pedido, com o contexto e com o que apareceu antes.

Permissão é o que o sistema deixa acontecer. Não depende de interpretação nenhuma. Se o acesso não existe, a ação falha, e pronto.

As duas são necessárias, e a segunda é a que segura.

Um agente bem instruído e mal permissionado funciona bem por meses e um dia faz algo que ninguém pediu. Um agente mal instruído e bem permissionado erra dentro de uma caixa, e o erro é chato em vez de caro.

Se você só puder investir em uma, investe na permissão.

Camada 1: credencial própria

Primeira coisa, antes de qualquer outra.

O agente recebe uma credencial dele, não a sua nem a de um funcionário.

Três ganhos imediatos: dá pra ver no registro o que foi feito por ele, dá pra revogar sem afetar ninguém, e dá pra conceder exatamente o que ele precisa em vez de herdar o acesso de uma pessoa, que sempre é maior.

Agente rodando com credencial de gente é a raiz de metade dos problemas de auditoria.

Camada 2: o mínimo, listado

Escreve as ações que a tarefa exige. Concede só essas. O que não está na lista é negado por padrão, não esquecido.

Um exemplo concreto, pra sair do abstrato. Agente que faz triagem de chamados precisa de: ler chamado, ler histórico do cliente, atualizar o campo de categoria, adicionar comentário interno.

Não precisa de: apagar chamado, alterar dado cadastral, ver dado financeiro, responder ao cliente.

Note que a lista do que ele não precisa é maior que a do que precisa. É assim na maioria dos casos, e é por isso que acesso amplo é tão desproporcional.

Camada 3: expõe operação, não sistema

Em vez de dar acesso ao banco, expõe a consulta específica.

Em vez de dar acesso à pasta inteira do drive, expõe a subpasta do mês.

Em vez de dar a API completa, expõe as duas operações necessárias.

A diferença prática é grande: com acesso ao sistema, o limite depende de o agente escolher não usar o resto. Com operação exposta, o resto não existe pra ele.

Camada 4: ambiente separado no começo

Nas primeiras semanas, ele trabalha numa cópia dos dados, não nos dados reais.

Você observa o comportamento sem risco e descobre as interpretações estranhas em ambiente que perdoa. É a mesma lógica de separar dado real de dado de teste.

Camada 5: lista do que exige aprovação

Mesmo com tudo acima, algumas ações nunca deveriam ser automáticas:

  • apagar qualquer coisa
  • enviar mensagem pra fora da empresa
  • gastar dinheiro
  • publicar conteúdo
  • alterar dado de cliente identificado

Nessas, o agente prepara e espera confirmação. É o mesmo princípio de não soltar agente sem revisar permissão.

O teste que fecha a configuração

Depois de configurar, tenta quebrar.

Pede pro agente fazer explicitamente algo que ele não deveria poder: apagar um registro, acessar uma área proibida, enviar uma mensagem.

Duas respostas possíveis. Se ele recusar citando a instrução, você tem instrução funcionando e permissão não testada. Se ele tentar e falhar por falta de acesso, você tem limite de verdade.

O segundo é o que você quer. Instrução é a primeira linha; permissão é a que segura quando a primeira falha.

A decisão é sua.

Perguntas frequentes

Perguntas rápidas

+Não basta escrever no prompt o que ele não pode fazer?

Não. Instrução é pedido, e pedido depende de interpretação. Permissão é barreira: se o acesso não existe, a ação falha independentemente do que foi entendido.

+Qual a primeira coisa a configurar?

Credencial própria para o agente, com o mínimo de acesso necessário. Isso permite auditar o que foi feito por ele e revogar sem afetar pessoas.

+Como decidir o que ele pode alcançar?

Listando as ações concretas que a tarefa exige e concedendo apenas essas. O que não estiver na lista deve ser negado por padrão, não esquecido.

+O que sempre deve exigir confirmação humana?

Qualquer ação irreversível: apagar, enviar para fora da empresa, gastar dinheiro, publicar ou alterar dado de cliente identificado.

Não perca o próximo

Receba os próximos posts no e-mail

Sem enrolação, sem hype. Tutoriais, análise de notícia e método de vibecoding com engenharia. Cancela quando quiser, é só responder pedindo.

Próximo passo

Quer aplicar isso com método?

Baixe os guias gratuitos de vibecoding com engenharia e libere os robôs de IA na Área do Cliente — prompts prontos para usar no ChatGPT, Claude ou Gemini.

Baixar guias grátisConhecer os robôs
RM

Sobre o autor

Rodrigo Munhoz Reis

Consultor de IA e Diretor de Tecnologia (CTO) e sócio de produtos 100% construídos em vibecoding — MeuCurso, DireitoHub e TreinadorOAB. Escreve sobre construir e usar IA com a velocidade da máquina e o rigor de engenheiro: vibecoding com engenharia.

LinkedInInstagramSobre →

Continue lendo

Segurança

Como usar IA em cima de dado sensível sem entregar o dado

Dá pra corrigir prova, analisar contrato e resumir atendimento com IA sem mandar nome, CPF e documento pro modelo. A técnica é simples e quase ninguém aplica.

Segurança

Os 3 lugares por onde dado sensível vaza num app feito com IA

Não é hacker. Na prática, quase todo vazamento em app feito com IA vem de três lugares chatos e previsíveis. Os três dão pra conferir hoje, sem ser programador.

Segurança

Como separar dado real de dado de teste (o que a LGPD cobra)

Testar com a base de produção é o atalho mais comum e o mais caro. Separar ambiente é mais simples do que parece, e a LGPD não trata isso como detalhe.

← Voltar ao blog