Os limites de um agente de IA não se escrevem no prompt. Escrevem-se no modelo de permissões. A regra prática publicada pela Meta em novembro de 2025, a Agents Rule of Two, defende que um agente deve satisfazer no máximo duas de três propriedades: processar entradas não fidedignas, aceder a dados sensíveis e alterar estado ou comunicar para o exterior. Um agente que reúne as três pode ser transformado numa ferramenta de exfiltração de dados por um único texto injetado. Um modelo de permissões que funciona opera em quatro camadas — identidade, ferramenta, argumento e orçamento — e marca à partida as ações irreversíveis para aprovação humana.
Porque é que um prompt não é um controlo de segurança
A instrução mais comum que encontramos nos projetos que herdamos é mais ou menos esta: não apagar clientes, não enviar email sem aprovação, não expor informação interna. Essa frase está no prompt de sistema e dá a sensação de proteção. Não é.
Um prompt é uma sugestão estatística, não uma permissão. Compete pela atenção do modelo com todos os outros textos presentes no contexto — incluindo os que chegaram do exterior. No momento em que o agente lê um email, uma página web, um ficheiro carregado por um cliente ou o resultado de uma ferramenta, esse texto ocupa o mesmo espaço que as suas instruções. É esta a ideia central da prompt injection, e é por isso que não se sai do problema mudando a formulação.
A separação correta é simples: o prompt define a intenção, o modelo de permissões define a capacidade. Aquilo que o agente tecnicamente não consegue fazer, não fará — por mais convincente que seja a persuasão de que deveria.
Teste rápido: se a sua única defesa contra uma ação destrutiva é uma frase num prompt, não tem uma defesa. Tem um pedido educado.
A Rule of Two: o enquadramento mais prático publicado até hoje
A 1 de novembro de 2025 a Meta publicou um enquadramento invulgarmente simples para desenhar agentes mais seguros. Identifica três propriedades e defende que um agente, dentro de uma mesma sessão, deve satisfazer no máximo duas.
| Propriedade | O que significa | Exemplo típico |
|---|---|---|
| A. Entrada não fidedigna | O agente lê conteúdo controlado por outra pessoa | Emails recebidos, formulários, páginas web, documentos carregados |
| B. Acesso a dados sensíveis | O agente pode ler dados privados ou sistemas internos | CRM, salários, base de conhecimento interna, caixa de correio |
| C. Alteração de estado ou comunicação externa | O agente pode escrever, enviar ou publicar | Envio de email, chamada a uma API externa, atualização de um registo, cobrança |
O perigo está na combinação das três. Um agente que lê um email recebido (A), extrai dados de cliente do CRM (B) e pode enviar email (C) torna-se uma máquina de exfiltração no momento em que alguém lhe envia uma mensagem com uma instrução escondida. O atacante não precisa de partir nada; basta-lhe escrever texto.
A própria Meta sublinha que a regra não é uma linha de chegada. Não protege contra erros do agente, nem contra injeções que se limitam a produzir desinformação na resposta, nem contra permissões demasiado amplas dentro dos dois eixos que manteve. É uma ferramenta para reduzir o pior cenário, não um substituto de uma defesa em profundidade.
Como quebrar a combinação na prática
Na maioria dos casos não tem de abdicar de capacidade; tem de a repartir por dois agentes ou duas fases. Estes são os três padrões que funcionam.
| Padrão | O que é separado | Quando usar |
|---|---|---|
| Leitor e executor | Um agente lê a entrada não fidedigna e devolve apenas um resumo estruturado; um segundo agente atua sobre esse resumo contra os sistemas reais | Processamento de emails, formulários, documentos de clientes |
| Assinatura humana | O agente reúne as três propriedades, mas a ação C passa por aprovação humana | Quando o processo realmente não pode ser dividido |
| Canal de saída fechado | O agente só pode escrever para destinos que constem de uma allowlist fixa | Relatórios internos, atualização de registos, geração de rascunhos |
O segundo padrão é o mais comum e é também o que se degrada: uma aprovação que se torna reflexo deixa de ser um controlo. Onde colocar exatamente o ponto de aprovação, e como mantê-lo com significado, está tratado no nosso guia de aprovação humana.
Um modelo de permissões em quatro camadas
A permissão de um agente não é uma questão binária de acesso a sistemas. Constrói-se em quatro camadas, e cada camada que se salta abre uma classe inteira de falhas.
| Camada | A pergunta a que responde | O que acontece quando falta |
|---|---|---|
| Identidade | Em nome de quem o agente atua | Ações atribuídas a uma conta de serviço anónima; sem trilho de auditoria, sem reconstituição |
| Ferramenta | Que ações existem sequer para ele | O agente descobre uma capacidade que nunca deveria ter tido, como apagar através de uma ferramenta genérica de atualização |
| Argumento | Sobre o que pode executar essa ação | Ferramenta certa, âmbito errado — uma atualização aplicada a todos os registos em vez de um |
| Orçamento | Quanto, com que rapidez e até quando | Um ciclo que corre centenas de passos ou milhares de chamadas antes de alguém dar por isso |
A camada dos argumentos é a mais esquecida e a que causa a maior parte dos danos reais. Um agente autorizado a atualizar o estado de uma encomenda sem limite de âmbito pode atualizar todas as encomendas. A regra simples: cada ferramenta de escrita valida os seus argumentos do lado do servidor, não em instruções ao modelo.
Prompt injection e uso indevido de ferramentas: o que já aconteceu
Em dezembro de 2025 a OWASP publicou o seu Top 10 de riscos para aplicações agênticas. O risco identificado como ASI02, Tool Misuse and Exploitation, descreve exatamente o caso em que um agente usa de forma destrutiva uma ferramenta autorizada — e a mitigação recomendada são permissões granulares e validação rigorosa dos argumentos antes da execução. Não é uma recomendação teórica.
Um exemplo concreto: a CVE-2025-59528 no Flowise, uma plataforma low-code para construir aplicações agênticas, resultava do tratamento inseguro dos dados de configuração CustomMCP e permitia a injeção e execução de JavaScript arbitrário. A falha não estava no modelo. Estava na camada entre o modelo e as ferramentas — precisamente o sítio que a maioria das equipas trata como canalização.
A própria especificação vai no mesmo sentido: a revisão estável do Model Context Protocol datada de 28 de julho de 2026 coloca o reforço da autorização entre as suas alterações principais, a par da passagem a um protocolo sem estado. Quem constrói hoje uma camada de ferramentas parte de uma base melhor do que há um ano, mas essa base não substitui as suas próprias decisões.
O que um agente nunca faz sozinho
A lista que se segue é independente do setor. São ações em que o custo de um erro excede o custo do atrito.
- Movimentar dinheiro. Cobrar, creditar, reembolsar, alterar condições de pagamento.
- Comunicar para o exterior em nome da empresa. Email a clientes, mensagens, publicação — redigir sim, enviar não.
- Apagar ou qualquer ação irreversível. Tudo o que não tem botão de anular.
- Alterar permissões. Um agente que consegue alargar as suas próprias permissões não é um agente, é um buraco.
- Atuar em âmbito largo. Atualizações em massa, exportações de base de dados, alterações à configuração do sistema.
- Decisões com consequência legal ou regulatória. Recusar um sinistro, classificar um trabalhador, cotar um preço vinculativo.
O que um agente pode ler é uma questão distinta e igualmente importante — a classificação da informação que pode entregar a um modelo está tratada no nosso guia de classificação de dados na empresa.
Qual é o aspeto disto quando está bem feito
Um bom modelo de permissões é aborrecido. Parece uma tabela: cada ferramenta tem um responsável, um nível de risco, um intervalo de argumentos permitido, um teto diário de chamadas e um indicador que diz se exige aprovação. Essa tabela escreve-se antes do primeiro prompt e revê-se a cada alteração.
Três testes que vale a pena correr em qualquer agente antes de produção: tentar injetar uma instrução por cada canal de entrada não fidedigna e confirmar que nunca chega a uma ferramenta de escrita; correr cada ferramenta de escrita com um argumento fora do intervalo e confirmar que é rejeitado do lado do servidor; e lançar o agente contra um objetivo impossível e confirmar que para no teto de orçamento em vez de continuar. O método completo destes testes está no nosso guia de avaliação, e a estrutura em que tudo assenta está explicada em Anatomia de um agente de IA empresarial.
Perguntas frequentes
O que é a Rule of Two da Meta?
Um enquadramento de segurança publicado pela Meta em novembro de 2025 segundo o qual um agente, dentro de uma mesma sessão, deve satisfazer no máximo duas de três propriedades: processar entradas não fidedignas, aceder a dados sensíveis e poder alterar estado ou comunicar para o exterior. Reunir as três transforma uma única prompt injection numa fuga de dados.
É possível prevenir totalmente a prompt injection?
Não com os métodos disponíveis hoje. Qualquer texto que entre no contexto compete pela atenção do modelo, incluindo texto de origem externa. A defesa não é por isso a prevenção mas a limitação do dano: permissões mínimas, separação entre ler a entrada e executar ações, e aprovação humana para os passos irreversíveis.
Qual é a diferença entre permissões de utilizador e permissões de agente?
As permissões de utilizador são verificadas uma vez no início de sessão e pressupõem juízo humano ao longo de toda a sessão. As de um agente têm de ser verificadas a cada chamada, ao nível da ferramenta e ao nível do argumento, porque entre passos não existe juízo humano. Na prática isso significa validação do lado do servidor em vez de confiança nas instruções dadas ao modelo.
Como se restringe um agente sem o tornar inútil?
Dividir em vez de bloquear. Um agente leitor que devolve um resumo estruturado, mais um agente executor que atua apenas sobre esse resumo, preserva toda a capacidade de negócio eliminando a combinação perigosa. Onde dividir é impossível, acrescente um ponto de aprovação apenas na ação de saída.
De quem deve ser o modelo de permissões?
De quem suporta as consequências se sair uma ação errada — normalmente o responsável pelo processo de negócio, não a equipa de desenvolvimento. A equipa técnica implementa-o, mas decidir que ações são irreversíveis e quais exigem aprovação é uma decisão de negócio.
Continuar a ler
Correr agentes de IA na sua própria infraestrutura – Onde os limites de permissão são realmente aplicados, assim que o agente fala com ferramentas reais.
Como avaliar um agente antes de o expor a um cliente – O método para confirmar que os limites aguentam, execução após execução.