Guardrails e Proteção de Agentes Autônomos

Nota do Capítulo 17, pasta de Detecção de Ameaças Contra Sistemas de IA.
Define a arquitetura de guardrails para agentes autônomos, com camadas de validação, limites de ferramentas, budgets de ação, human-in-the-loop e telemetria, e mostra política por ferramenta.
Dialoga com as notas de Prompt Injection e de ATLAS do mesmo capítulo e com a nota de AutoPT, que valida a eficácia desses controles.

1. Contexto e Posicionamento na Biblioteca

A biblioteca chegou ao fim do estudo com a pergunta de governança mais prática do capítulo 17: como deixar um agente autônomo executar trabalho real em um ambiente corporativo sem transformá-lo no pivô de um incidente. Esta nota responde com uma arquitetura de guardrails, entendidos como controles que restringem e observam a ação do agente, e não como filtros de conteúdo. A motivação técnica foi construída nas notas anteriores: o prompt injection mostra que o agente pode ser enganado, o ATLAS cataloga as técnicas que exploram essa superfície, e o caso da campanha de espionagem com agente de codificação mostra o que acontece quando a autonomia opera sem observabilidade.

O posicionamento na biblioteca é o de nota de arquitetura de defesa para a superfície de IA, na mesma posição que os controles PRT ocupam para endpoint e rede no capítulo 15. O leitor deve sair daqui com um modelo de camadas, com um exemplo concreto de política por ferramenta e com a convicção de que telemetria de agente é requisito de produção, e não opcional. A nota de AutoPT complementa a leitura no plano de verificação, porque guardrails sem teste contínuo são apenas configuração sem evidência.

2. Modelo de Risco de Agentes Autônomos

O agente autônomo difere do chatbot em três propriedades que criam risco novo. Primeiro, ele planeja e executa sequências de ações, e o resultado de cada ação alimenta a decisão seguinte, o que permite que um erro inicial se compond em cadeia. Segundo, ele opera com credenciais e ferramentas que a organização concede, herdando permissões que o atacante que o engana não teria. Terceiro, ele decide sem revisão humana intermediária na maior parte das execuções, o que move a fronteira de confiança do usuário para o conteúdo que o agente processa. Juntas, essas propriedades fazem do agente uma identidade de serviço com tomada de decisão probabilística, e é esse o modelo de risco que os guardrails endereçam.

O inventário de danos plausíveis organiza a priorização de controles. Exfiltração de dado sensível via ferramenta, no padrão descrito na nota de prompt injection. Ação destrutiva ou irreversível executada por engano, como exclusão em massa ou mudança de configuração em produção. Excesso de agência, com o agente alcançando objetivo por caminho fora do escopo da tarefa. Abuso de custo, com execução em loop consumindo crédito de API. E pivô de intrusão, no qual o agente comprometido vira credencial viva dentro do perímetro, o caso documentado no capítulo com campanhas orquestradas por IA. Cada camada da arquitetura a seguir responde a um subconjunto desse inventário.

3. Camadas de Guardrails

A arquitetura recomendada organiza os controles em seis camadas que operam em momentos diferentes do ciclo de vida da ação do agente. A tabela resume as camadas, o momento de atuação e o exemplo de controle mais representativo. O princípio de desenho é o mesmo da defesa em profundidade tradicional: nenhuma camada é infalível, e a arquitetura garante que o dano exija furar várias camadas independentes.

A camada de validação de entrada cobre o conteúdo do usuário e, com igual peso, o conteúdo de terceiros, e-mails, documentos, páginas e saídas de ferramenta, aplicando normalização que remove marcação oculta e metadados, na linha das defesas da nota de prompt injection. A camada de instrução define o contrato de comportamento do agente, incluindo a regra de ouro de tratar conteúdo externo como dado não confiável. As camadas de ferramenta, de budget e de human-in-the-loop limitam o que o agente pode fazer quando enganado, e a camada de log garante que tudo isso seja observável. As seções seguintes detalham as camadas que exigem decisão de engenharia.

4. Momentos de Intervenção: Entrada, Raciocínio, Ferramenta e Saída

A arquitetura de seis camadas da seção anterior pode ser lida como quatro momentos de intervenção no ciclo de vida de uma ação, e essa leitura é a que melhor orienta o desenho de novos controles. Na entrada, o conteúdo que chega é tratado como não confiável, venha do usuário ou de terceiros. No raciocínio, o contrato de comportamento restringe o que o agente considera fazer com esse conteúdo. Na ferramenta, o que o agente consegue executar é limitado por política externa, com budget e aprovação onde cabe. Na saída, o que o agente produz e envia é filtrado por classificação antes de cruzar qualquer fronteira.

O momento de saída é o mais esquecido nas implementações, e por isso esta nota o trata de forma explícita: a validação de saída é implementada como filtro de classificação aplicado à resposta do modelo e às cargas enviadas por ferramenta, complementando as seis camadas da seção 3. Mesmo com entrada saneada e ferramentas restritas, um modelo pode reproduzir dado sensível presente no contexto de inferência, e a única defesa nesse ponto é inspecionar o que sai. Times que implementam apenas entrada e ferramenta cobrem dois dos quatro momentos, e os testes da nota de AutoPT costumam encontrar exatamente essa lacuna.

5. Padrões de Implementação

O padrão de implementação mais robusto centraliza a decisão de permitir ou negar em um policy engine externo ao agente. O fluxo é direto: o agente propõe uma ação, o runtime envia a proposta ao engine, o engine avalia contra políticas versionadas em código, e apenas as ações aprovadas são executadas. O agente nunca detém a capacidade de decidir sozinho sobre o que pode fazer, e a política é auditável, testável e passível de mudança por pipeline, na mesma disciplina de detecção como código que a nota de Continuous Purple Teaming aplica às regras do SIEM. Engines de política de mercado, como OPA e Cedar, servem ao propósito, e a decisão técnica relevante é manter a política fora do prompt, porque instrução escrita em linguagem natural não é controle executável.

O segundo padrão é a sandbox de execução para ferramentas que tocam código, comandos ou sistema de arquivos. O agente executa em contêiner efêmero, sem credenciais de produção montadas, com egress restrito a destinos da allowlist e com tempo de vida limitado pela tarefa. O terceiro padrão é o proxy de ferramentas, no qual todas as chamadas passam por um serviço intermediário que aplica rate limit, valida parâmetros contra esquema, reescreve destinos bloqueados e registra tudo, funcionando como o único caminho de saída do agente para ferramentas. Esse padrão é o que torna a camada de log da seção 3 tecnicamente viável em escala, porque o registro nasce no mesmo ponto onde a decisão é tomada.

6. Exemplo de Política de Guardrail por Ferramenta

O exemplo abaixo mostra uma política declarativa por ferramenta para um agente de operações, combinando allowlist, limites de parâmetro, budget e exigência de aprovação humana. O formato é ilustrativo, e o importante é a granularidade: cada ferramenta tem contrato próprio, e não existe permissão genérica de ferramenta para o agente inteiro.

agente: assistente-operacoes
ferramentas:
  busca_web:
    destinos_permitidos: ["*.empresa.com", "*.fornecedor-contratado.com"]
    limite_por_tarefa: 10
    bloqueia_parametros_com_dado_classificado: true
  consulta_bd:
    modo: somente_leitura
    limite_linhas: 100
    colunas_proibidas: ["cpf", "salario", "credencial"]
    exige_origem_de_tarefa: ["relatorio_semanal"]
  envia_email:
    destinos_externos: exige_aprovacao_humana
    anexos: somente_de_biblioteca_publica
    limite_por_tarefa: 5
  executa_comando:
    sandbox: efemera_sem_credenciais
    egress: apenas_allowlist_de_busca_web
    exige_aprovacao_humana: ["sudo", "config_change", "delete"]
budgets:
  chamadas_de_ferramenta_por_tarefa: 25
  tokens_por_tarefa: 200000
  custo_maximo_por_tarefa: "2 USD"
  duracao_maxima: 30m
auditoria:
  loga_toda_decisao: true
  loga_parametros_integralmente: true
  retende_por: 400d

Três detalhes do exemplo merecem destaque de engenharia. O bloqueio por classificação de dado no parâmetro é o controle que impediu o cenário de exfiltração da nota de AutoPT, e depende de classificação aplicada na fonte, e não no momento da chamada. A exigência de origem de tarefa válida na consulta de banco impede que a ferramenta seja usada em cadeia iniciada por conteúdo hostil. E a lista de ações que pedem aprovação humana na execução de comando cobre exatamente os verbos irreversíveis, mantendo a fricção onde o dano não tem desfazer.

A tabela abaixo resume a mesma política em formato de revisão para gestores, que não avaliam YAML em comitê. O formato serve também de gabarito de aprovação formal para novos agentes, com uma linha por ferramenta concedida e sem permissão genérica de agente inteiro. A revisão dessa tabela acompanha o ciclo de vida de permissões descrito na seção de erros.

7. Budgets de Ação e Human-in-the-Loop

O budget de ação é o controle subestimado da arquitetura, e a razão é estatística. Um agente legítimo executa uma tarefa com distribuição previsível de chamadas, de tokens e de custo, e um agente manipulado desvia dessa distribuição, em loop, em encadeamento anômalo ou em custo atípico. O budget funciona então como detector e como limitador ao mesmo tempo: ao exceder o limite, a tarefa é pausada e encaminhada a revisão, o que transforma desvio em evento visível em vez de dano silencioso. Os limiares devem ser calibrados com dados reais de uso, por tipo de tarefa, e não copiados de configuração padrão, porque cada ferramenta tem custo e cadência próprios.

A tabela abaixo organiza os tipos de budget com exemplos de limiar inicial e ação ao exceder. Os números servem de ponto de partida para calibração, e nunca de valor final, porque a distribuição de uso varia por time e por tipo de tarefa. A calibração usa as distribuições reais de uso coletadas pela telemetria da seção 8.

O human-in-the-loop precisa ser desenhado para não virar aprovação automática de fadiga. A regra de operação é reservar a aprovação humana para ações de consequência material, escrita em produção, envio externo, exclusão e mudança de configuração, e deixar o resto fluir sem fricção. Cada pedido de aprovação deve carregar contexto suficiente para decisão em segundos: o que o agente quer fazer, por quê, com quais parâmetros e qual o efeito esperado, e a interface deve mostrar a transcrição da tarefa. Quando o volume de pedidos cresce além da capacidade do aprovador, o antídoto é restringir o escopo do agente, e não acelerar o clique humano, porque a aprovação rubber stamp é o ponto de falha clássico dessa camada. A métrica de saúde dessa camada é a taxa de aprovação, e taxa próxima de cem por cento é sinal de que o controle virou formalidade, o que pede reescopo do agente antes de qualquer aumento de autonomia.

8. Telemetria de Agente e Detecção de Abuso

A telemetria é o que transforma a arquitetura em operação monitorada. O esquema mínimo de log por ação inclui identidade do agente, tarefa de origem, ferramenta chamada, parâmetros, decisão do policy engine com o motivo, resultado da execução, custo e duração. Com esse esquema, o SOC caça padrões de abuso com as mesmas técnicas de baseline que já usa para identidade e endpoint. As três hipóteses de caça de maior rendimento inicial são: agente com taxa de negações do policy engine acima da própria baseline, que indica tentativa de desvio; tarefa com cadeia de ferramentas fora do padrão do tipo declarado, que indica encadeamento manipulado; e chamadas de ferramenta de rede com volume ou destino atípico, que indica exfiltração em curso.

AgentAuditLog
| where TimeGenerated > ago(1d)
| summarize Negadas = countif(Decisao == "negado"),
    Total = count(),
    CustoUSD = sum(Custo),
    DuracaoMax = max(DuracaoSegundos)
    by AgentName, TarefaTipo
| extend TaxaNegacao = round(1.0 * Negadas / Total, 2)
| where TaxaNegacao > 0.2 or CustoUSD > 5

A consulta acima exemplifica a primeira hipótese, e a regra de operação é tratar agente como identidade com baseline própria, por tipo de tarefa e por horário. A integração com o SIEM usa o mesmo pipeline do grupo DAT do capítulo 15, com os eventos de agente entrando como fonte nova e normalizada. Para o hunting estruturado, cada hipótese citada vira ficha do grupo HNT, com fonte de dados declarada e critério de avaliação, fechando o ciclo com a metodologia que a biblioteca desenvolveu no capítulo 7.

A tabela abaixo consolida as hipóteses com fonte e sinal, no formato de ficha de caça do grupo HNT. A baseline por tipo de tarefa é o antecedente de todas elas, e sem baseline a consulta da seção produz apenas ruído. O resultado de cada execução deve ser registrado com data e analista, inclusive quando negado, para construir histórico de cobertura.

9. Testes Contínuos dos Guardrails

Guardrails são controles, e controles sem teste degradam. O ciclo de teste recomendado é o da nota de AutoPT: cenários de ataque contra o agente completo, com o ambiente espelhando produção, medindo a taxa de bloqueio por camada e alimentando regressão. O catálogo mínimo de testes cobre os danos da seção 2, com casos de exfiltração via ferramenta, de encadeamento anômalo que estoura budget, de ação destrutiva que deve parar no human-in-the-loop e de saída de ferramenta contendo instrução plantada. Cada caso declara qual camada deveria bloquear e qual evento deveria ser gerado, e o teste falha se o bloqueio ocorrer sem telemetria, porque bloqueio invisível não sustenta resposta a incidente.

A cadência operacional segue a lógica do pipeline de detecções: todo cambio de política, de prompt ou de permissão de ferramenta passa pelo ciclo de teste antes do merge, e a rotina periódica revalida o catálogo completo para regressão. Esse requisito fecha a arquitetura com o mesmo padrão de qualidade do resto da biblioteca, em que controle declarado, controle testado e cobertura validada são três coisas diferentes, e é a diferença entre elas que o dashboard de maturidade de IA deve exibir.

10. Erros Comuns e Pontos de Atenção

Um ponto de atenção final é o ciclo de vida da permissão. Ferramentas concedidas a um agente piloto frequentemente sobrevivem ao piloto, e a revisão de permissões de agente deve entrar no mesmo processo de revisão de acesso de identidades que a organização já executa, com direito a desprovisionamento. Agente que muda de escopo precisa de política que mude junto, e essa disciplina pertence à governança de identidade descrita no capítulo 8 da biblioteca, não à engenharia de prompt.

11. Integração com o Restante da Biblioteca

A nota fecha o capítulo 17 conectando a superfície de IA aos padrões que a biblioteca já estabeleceu. Com a nota de Prompt Injection, fornece as defesas cuja lógica foi construída lá, agora em formato executável de política. Com o AutoPT, recebe o ciclo de teste que transforma configuração em controle verificado. Com a nota de ATLAS, alinha cada camada às técnicas que ela mitiga, permitindo que o gap analysis cite a camada como resposta. E com o capítulo 15, herda o desenho de grupos de controles, com telemetria no DAT, testes no SIM e KPIs no MET, estendendo o Framework CTH à camada de agentes.

Para o leitor que encerra a biblioteca, a recomendação final é tratar esta nota como checklist de produção. Antes de autorizar qualquer agente autônomo a operar com dados corporativos, confirmar as seis camadas implementadas, a política por ferramenta assinada, os budgets calibrados, os eventos fluindo ao SIEM e o primeiro ciclo de testes executado com evidência. Essa disciplina é o que separa a adoção responsável de IA da adoção que a biblioteca inteira foi escrita para evitar.