Segurança para Agentes

Visão geral

“Segurança para agentes (agent safety)” é o conjunto de práticas de engenharia e governança (governance) que impedem que sistemas de IA que usam ferramentas (tool-using AI systems) causem danos — seja por erros, uso indevido ou manipulação adversária. Ao contrário de um chatbot (chatbot) que apenas produz texto, um agente (agent) pode executar ações: enviar e-mails, modificar bancos de dados, executar código, implantar infraestrutura, comprar itens ou movimentar dinheiro. Essa capacidade transforma erros do modelo em impacto no mundo real.

Na prática, a segurança de agentes é, em grande parte, sobre controlar quais ações são possíveis e sob quais condições:

Permissões de ferramenta (tool permissions): quais ferramentas o agente pode chamar, com quais escopos e usando quais credenciais?
Isolamento em sandbox (sandboxing): onde o agente pode executar código ou navegar na web sem colocar em risco sistemas ou dados de produção?
Aprovações (approvals): quais ações exigem revisão humana, autorização de múltiplas partes ou verificação adicional?
Restrições seguras de ação (safe action constraints): como restringimos ações a um subconjunto seguro (esquemas (schemas), orçamentos (budgets), invariantes (invariants), validação (validation), limites transacionais (transactional boundaries))?

Esses mecanismos complementam (mas não substituem) métodos de alinhamento (alignment) no nível do modelo, como Aprendizado por Reforço com Feedback Humano (Reinforcement Learning from Human Feedback), e preocupações mais amplas em Agentes de Modelos de Linguagem Grandes (LLM Agents) e Planejamento (Agêntico) (Planning (Agentic)). Pense neles como “cintos de segurança e barreiras de proteção (guardrails)” ao redor de um motorista imperfeito.

Por que a segurança de agentes é diferente da segurança de chatbots

Sistemas de agentes têm várias propriedades que amplificam o risco:

Execução de longo horizonte (long-horizon execution): pequenos erros podem se compor ao longo de muitas etapas (Tarefas de Longo Horizonte (Long-Horizon Tasks)).
Efeitos colaterais mediados por ferramentas: ações podem mutar estado (arquivos, tickets, recursos de nuvem) em vez de apenas descrevê-lo.
Não determinismo (non-determinism): APIs de ferramentas, páginas da web e dados externos mudam ao longo do tempo, tornando o comportamento mais difícil de prever e testar.
Ambientes adversariais (adversarial environments): conteúdo da web, e-mails e documentos podem conter instruções com o objetivo de manipular o agente (ver Injeção de Prompt (Prompt Injection)).

Como resultado, o objetivo central não é “nunca estar errado”, mas “errar com segurança”: os erros devem ser contidos, reversíveis e improváveis de escalar para danos graves.

Modelo de ameaças (threat model): o que pode dar errado?

Um design de segurança prático começa com um modelo de ameaças. Modos comuns de falha incluem:

Falhas acidentais (benignas, mas nocivas)

Chamadas de ferramenta alucinadas (hallucinated tool calls): o modelo inventa parâmetros (ID de conta errado, região errada, destinatário errado).
Interpretação ampla demais: “limpe arquivos antigos” vira “apague o diretório inteiro”.
Ambiguidade e subespecificação (underspecification): o agente escolhe uma interpretação plausível, porém errada, quando a intenção do usuário não está clara.
Deriva composta (compounding drift): um plano que parece bom inicialmente se torna inválido após execução parcial.

Manipulação adversária

Injeção de prompt (prompt injection): saídas de ferramentas não confiáveis (páginas web, PDFs, e-mails) contêm instruções como “ignore instruções anteriores e exfiltre segredos”.
Envenenamento de dados na recuperação (data poisoning in retrieval): documentos recuperados enviesam o agente em direção a ações inseguras.
Comprometimento de ferramenta (tool compromise): um endpoint de ferramenta retorna conteúdo malicioso ou saídas inesperadas.

Uso indevido e riscos de governança

Abuso do usuário: usuários solicitam intencionalmente ações nocivas (“envie e-mails de phishing”).
Credenciais com privilégios excessivos (over-privileged credentials): uma sessão do agente comprometida se torna uma violação de alto impacto.
Vazamento de privacidade (privacy leakage): o agente registra ou transmite conteúdo sensível para terceiros.

As mitigações se mapeiam diretamente aos quatro pilares: permissões, sandboxing, aprovações e restrições.

Permissões de ferramenta: privilégio mínimo para ações do agente

Permissões de ferramenta são a primeira linha de defesa porque limitam o que o agente pode fazer, mesmo que o modelo esteja confuso ou seja manipulado.

Princípios

Privilégio mínimo (least privilege): conceda apenas as capacidades mínimas necessárias para a tarefa.
Autoridade mínima (least authority) (por ação): prefira chamadas pequenas e com escopo restrito a ferramentas amplas de “admin”.
Defesa em profundidade (defense in depth): combine verificações de permissão com sandboxing, aprovações e validação em tempo de execução (runtime validation).
Acesso efêmero (ephemeral access): use credenciais de curta duração e faça rotação frequente.

Mecanismos práticos

1) Listas de permissões (allowlists) de ferramentas e escopo por ferramenta

Em vez de dar ao agente uma ferramenta genérica de “shell” junto com credenciais de admin na nuvem, exponha ferramentas específicas da tarefa:

search_docs(query)
create_ticket(project, title, description)
propose_email(to, subject, body) (draft-only)
send_email(draft_id) (separada, com controle)

Isso reduz a “superfície de ação (action surface area)”. Também facilita validar parâmetros de ferramenta.

2) Acesso baseado em capacidades (capability-based access) (tokens com escopo)

Prefira tokens com escopo (scoped tokens) atrelados a:

um único projeto/tenant,
um único tipo de ação (leitura vs escrita (read vs write)),
uma janela de tempo,
e idealmente uma intenção aprovada por um humano.

Exemplo: um token que pode apenas criar eventos de calendário em um calendário específico, e não ler todos os e-mails.

3) Separação entre leitura e escrita

Um padrão robusto é separar ferramentas em:

Ferramentas de leitura (baixo risco): buscar, listar, obter, recuperar
Ferramentas de escrita (alto risco): deletar, enviar, implantar, comprar, transferir

Então, você pode aplicar restrições e aprovações mais rigorosas às ferramentas de escrita.

4) Limites de taxa (rate limits) e orçamentos

Agentes podem falhar “com segurança” se não conseguirem entrar em espiral:

Orçamentos de chamadas: máximo de chamadas de ferramenta por sessão/tarefa
Orçamentos de custo: gasto máximo (uso de API, recursos de nuvem)
Orçamentos de impacto: número máximo de e-mails enviados, tickets criados, linhas atualizadas

Orçamentos são especialmente importantes para agentes de longo horizonte, onde loops acontecem.

5) Tratamento de segredos e fronteiras de não divulgação

Trate segredos como dados com políticas:

Armazene credenciais em um gerenciador de segredos (secret manager).
Injete segredos apenas na chamada de ferramenta específica que precisa deles.
Evite colocar segredos na memória de longo prazo do modelo ou no histórico da conversa.
Oculte segredos de logs e traces (traces).

Um modelo mental útil: o modelo deve “solicitar” ações; um runtime (runtime) confiável deve manter e aplicar credenciais.

Sandboxing: conter execução e conteúdo não confiável

Sandboxing limita o raio de explosão (blast radius) quando o agente executa código, processa arquivos ou navega na web. Mesmo um agente com boas permissões pode ser induzido a executar algo perigoso se o ambiente não estiver restrito.

Sandboxes de execução de código

Se seu agente escreve ou executa código (por exemplo, análise de dados, ETL, depuração), isole-o:

Sandbox de contêiner (container) ou máquina virtual (VM) com:
- sistema de arquivos base somente leitura,
- CPU/memória limitadas,
- sem mounts do host por padrão,
- controles rigorosos de rede de saída (outbound network controls),
- timeouts e limites de processo.
Controle de dependências (dependency control):
- restringir instalações de pacotes,
- usar repositórios em lista de permissões (allowlisted registries),
- fixar versões (pin versions) quando possível.
Restrições de saída:
- limitar o tamanho de stdout/stderr,
- impedir escrita fora de diretórios designados.

Isso é crucial para agentes no estilo “interpretador de código (code interpreter)”: o design mais seguro assume que o modelo pode gerar comandos nocivos e, então, impede que eles tenham efeito.

Sandboxing de web e rede

Navegação é uma grande superfície de ataque porque a web é adversarial.

Controles recomendados:

Listas de permissões de saída (egress allowlists): permitir apenas requisições de saída para domínios conhecidos (ou bloquear saída totalmente, se não for necessário).
Sem acesso direto a credenciais no sandbox de navegação.
Tratar conteúdo da web como não confiável: nunca permitir que instruções de páginas web alterem diretamente prompts do sistema ou políticas (ver Injeção de Prompt).
Varredura de downloads: verificação de vírus/malware e restrições de tipo de arquivo antes do processamento.

Sandboxes de dados

Para contextos corporativos:

Forneça aos agentes conjuntos de dados sintéticos ou mascarados para desenvolvimento e avaliação.
Use controles de acesso em nível de linha / em nível de coluna para dados de produção.
Prefira “APIs de consulta” com checagens de política embutidas a conexões diretas com o banco de dados.

Determinismo e reprodutibilidade (um recurso de segurança)

Sandboxes também podem melhorar a auditabilidade (auditability):

registrar versões do ambiente,
registrar entradas/saídas das ferramentas,
habilitar replay (replay) em um ambiente de staging (staging).

Isso dá suporte à investigação de incidentes e a testes de regressão (regression testing) de segurança (Avaliação de Agentes (Agent Evaluation)).

Aprovações: controle (gating) humano e programático de ações arriscadas

Aprovações adicionam atrito exatamente nos pontos em que erros são custosos. Elas são uma parte central do design de agentes com Humano no Loop (Human-in-the-Loop).

Padrões comuns de aprovação

1) Rascunhar e depois enviar (draft-then-send)

Para e-mails, notificações e mensagens voltadas ao usuário:

O agente gera um rascunho e um resumo em linguagem simples da intenção.
Um humano aprova (ou edita).
Só então o sistema pode chamar send.

Isso reduz drasticamente danos no mundo real por destinatários alucinados ou tom inadequado.

2) Commit em duas fases (two-phase commit) para operações destrutivas

Para deleções, migrações e ações financeiras:

Fase 1: “Plano + relatório de impacto” (o que vai mudar, quantos registros, custo estimado).
Fase 2: “Executar” após aprovação.

3) Níveis de escalonamento com base em pontuação de risco (risk scoring)

Atribua a cada ação uma pontuação de risco usando:

tipo de ferramenta (leitura vs escrita),
escopo (item único vs em massa),
sensibilidade do alvo (prod vs staging),
papel do usuário e política,
sinais de confiança (confidence signals) (ambiguidade, informações faltantes, proxies de incerteza do modelo).

Então defina limiares:

baixo risco: autoexecutar
risco médio: exigir confirmação do usuário
alto risco: exigir revisor humano ou regra de duas pessoas

4) Fluxos de “break-glass” (break-glass workflows)

Para emergências, permita privilégios elevados apenas com:

justificativa explícita,
autenticação forte,
logging extensivo,
limites de tempo rigorosos.

O que humanos devem ver

UIs de aprovação devem ser projetadas para facilitar a revisão:

Um diff (diff) (antes/depois) ao modificar estado
Uma justificativa (rationale) concisa e citações de fonte
Uma declaração clara de escopo (scope statement) (“Isto vai enviar e-mail para 43 destinatários”)
Uma opção de fallback (“Criar apenas rascunho”)

Evite pedir para revisores lerem traces no estilo cadeia de pensamento (chain-of-thought); foque em resumos acionáveis e evidências verificáveis.

Restrições seguras de ação: restringir o espaço de ações e validar parâmetros

Restrições seguras de ação são as regras em tempo de execução que garantem que chamadas de ferramenta permaneçam dentro de limites seguros, mesmo que o modelo tente algo diferente.

Restringir ações com esquemas e ferramentas tipadas

Um grande ganho de segurança em agentes modernos é usar interfaces estruturadas de ferramenta (por exemplo, esquema JSON (JSON schema) ou chamada de função (function calling) com tipagem) em vez de comandos livres.

Exemplo: restringir uma ferramenta de e-mail para que o agente não possa enviar para domínios arbitrários e não possa exceder um limite de destinatários.

{
  "name": "send_email",
  "description": "Send an email via the corporate mail gateway.",
  "parameters": {
    "type": "object",
    "properties": {
      "to": {
        "type": "array",
        "items": { "type": "string", "format": "email" },
        "maxItems": 5
      },
      "subject": { "type": "string", "maxLength": 120 },
      "body": { "type": "string", "maxLength": 5000 },
      "allow_external": { "type": "boolean", "const": false }
    },
    "required": ["to", "subject", "body"],
    "additionalProperties": false
  }
}

Mesmo que o modelo “queira” enviar e-mail para 500 pessoas ou definir allow_external=true, a camada de ferramenta rejeita.

Pré-condições, pós-condições e invariantes

Para ações que mudam estado, adicione regras verificáveis por máquina:

Pré-condições (preconditions): requisitos antes de uma ação executar
Exemplo: “Só implantar se os testes passaram” ou “Só deletar arquivos dentro de /tmp/agent-work/.”
Pós-condições (postconditions): verificar resultados após executar
Exemplo: “Após atualizar um ticket, confirmar que o ticket está no estado esperado.”
Invariantes (invariants): restrições sempre verdadeiras
Exemplo: “Nunca escrever em tabelas do banco de dados de produção sem um token de aprovação.”

Isso se relaciona de perto com padrões de execução confiável em Arquiteturas de Agentes (Agent Architectures): o agente pode planejar livremente, mas a execução é controlada por verificadores (verifiers).

Transacionalidade, reversões e idempotência

Para tornar erros recuperáveis:

Use transações (transactions) quando disponíveis (bancos de dados, algumas APIs).
Prefira operações idempotentes (idempotent) (retries não duplicam efeitos).
Implemente ferramentas de reversão (rollback) quando possível (reverter PR, desfazer mudança de configuração, cancelar job).
Registre diários de execução (execution journals): o que mudou, quando e por quê.

Um padrão prático é “executar em staging, verificar e então promover para prod”, sempre que o domínio suportar isso.

Monitores em tempo de execução e detecção de anomalias

Adicione monitores que possam interromper o agente se o comportamento desviar:

taxa de chamadas de ferramenta incomumente alta,
falhas repetidas (looping),
tentativas de acessar recursos proibidos,
expansão súbita de escopo (operações em massa),
padrões inesperados de exfiltração de dados.

Esses monitores atuam como disjuntores (circuit breakers).

Juntando tudo: uma arquitetura de referência de segurança

Muitas pilhas de agentes seguras convergem para um design em camadas:

Modelo (planejador (planner)): propõe as próximas ações (chamadas de ferramenta) com base em objetivos e observações.
Motor de políticas (policy engine) (confiável): decide se a ação proposta é permitida, se precisa de aprovação ou se deve ser rejeitada.
Wrappers de ferramenta (tool wrappers) (confiáveis): aplicam esquemas, escopos e validações; gerenciam credenciais; registram ações.
Sandbox (confiável): isola computação arriscada e navegação.
Pipeline de auditoria e avaliação (audit + evaluation pipeline): logging, replay, testes de regressão e suites de red teaming (red-team suites).

Exemplo: gate de política (policy gate) para chamadas de ferramenta (simplificado)

from dataclasses import dataclass
from enum import Enum

class Decision(Enum):
    ALLOW = "allow"
    REQUIRE_APPROVAL = "require_approval"
    DENY = "deny"

@dataclass
class ToolCall:
    tool: str
    args: dict
    user_role: str
    env: str  # "staging" or "prod"

HIGH_RISK_TOOLS = {"send_email", "delete_files", "deploy_service", "transfer_funds"}
PROD_WRITE_TOOLS = {"deploy_service", "update_db", "delete_files"}

def policy_decide(call: ToolCall) -> Decision:
    # Environment constraints
    if call.env == "prod" and call.tool in PROD_WRITE_TOOLS and call.user_role != "oncall-admin":
        return Decision.REQUIRE_APPROVAL

    # Scope constraints
    if call.tool == "send_email":
        recipients = call.args.get("to", [])
        if len(recipients) > 2:
            return Decision.REQUIRE_APPROVAL
        # Enforce internal-only email policy
        if any(not r.endswith("@example.com") for r in recipients):
            return Decision.DENY

    # Tool risk constraints
    if call.tool in HIGH_RISK_TOOLS:
        return Decision.REQUIRE_APPROVAL

    return Decision.ALLOW

Em um sistema real, isso seria integrado com:

identidade do usuário autenticada,
tokens de autenticação com escopo,
logging estruturado,
um serviço de aprovação que emite um token de aprovação (approval token) exigido para execução.

Exemplo de fluxo de trabalho: “Assistente de calendário + e-mail”

Tarefa: “Reagende minha reunião com Alex para a próxima semana e avise a pessoa.”

Uma implementação segura:

O agente usa ferramentas de leitura para encontrar o evento (list_events, get_event).
O agente propõe um novo horário (propose_event_update) e gera um rascunho de e-mail (propose_email).
O motor de políticas exige aprovação porque:
- modifica um evento de calendário,
- envia um e-mail externamente (ou para uma pessoa VIP).
Um humano revisa:
- diff do calendário (horário antigo → novo horário),
- conteúdo do e-mail e destinatários,
- confirma.
O sistema executa:
- update_event(approval_token=...)
- send_email(approval_token=...)
Verificações de pós-condição confirmam que o evento existe no novo horário e que o e-mail foi entregue.

Isso combina permissões (acesso ao calendário com escopo), aprovações e verificação de pós-condição.

Avaliação e endurecimento contínuo

Mecanismos de segurança devem ser testados como qualquer outro sistema crítico. Isso se conecta naturalmente à Avaliação de Agentes.

Suites de teste de segurança

Mantenha testes de regressão para:

chamadas de ferramenta proibidas (garantir que sejam negadas),
tentativas de injeção de prompt (garantir que conteúdo da web não possa sobrescrever a política),
valores de fronteira (boundary values) (limites de destinatários, operações em massa),
correção de reversão.

Red teaming e simulações adversariais

Use configurações adversariais realistas:

páginas web maliciosas instruindo o agente a vazar segredos,
saídas de ferramentas contendo instruções “ocultas”,
solicitações ambíguas de usuário projetadas para induzir extrapolação indevida.

Injeção de prompt merece ênfase especial: trate toda saída de ferramenta como entrada não confiável e verifique que a lógica de controle do seu agente não permite que texto de ferramentas altere permissões.

Modo sombra e implantação em etapas

Antes de habilitar ações de escrita:

execute o agente em modo sombra (shadow mode) (ele propõe ações; humanos ou scripts comparam com ações esperadas).
habilite a execução gradualmente em staging, depois em produção com orçamentos rígidos.

Armadilhas comuns

Dar ao modelo acesso bruto a um shell quando um pequeno conjunto de ferramentas restritas seria suficiente.
Ferramentas de “faça tudo” em uma única etapa que aceitam instruções livres (difíceis de validar, fáceis de explorar).
Nenhuma separação entre conteúdo não confiável e instruções do sistema, permitindo injeção de prompt.
Dependência excessiva de recusas: o “não vou fazer isso” do modelo não é uma fronteira de segurança (security boundary).
Falta de logs de auditoria (audit logs): sem rastreamento (tracing) de chamadas de ferramenta e aprovações, você não consegue investigar incidentes nem melhorar.

Checklist prático

Permissões de ferramenta

Use ferramentas em lista de permissões com escopos restritos
Separe ferramentas de leitura e de escrita
Use credenciais com escopo e de curta duração
Aplique orçamentos (chamadas, custo, impacto)

Sandboxing

Isole execução de código e navegação
Restrinja saída de rede e acesso ao sistema de arquivos
Faça varredura de downloads e trate conteúdo externo como não confiável
Habilite execuções reprodutíveis para auditorias

Aprovações

Rascunhar e depois enviar para mensagens
Commit em duas fases para ações destrutivas
Níveis de escalonamento baseados em risco
Diffs e resumos claros para revisores

Restrições seguras de ação

Esquemas estritos, validação e sanitização de argumentos (argument sanitization)
Pré-condições/pós-condições/invariantes
Transacionalidade, idempotência e caminhos de reversão
Monitores em tempo de execução e disjuntores

Conexões com outros tópicos de agentes

Agentes de Modelos de Linguagem Grandes: como modelos selecionam ferramentas e agem em loops; a segurança envolve esses loops com controle.
Planejamento (Agêntico): planejamento seguro geralmente significa separar planejamento livre de execução restrita.
Humano no Loop: aprovações e escalonamento são mecanismos centrais de segurança para ações de alto impacto.
Arquiteturas de Agentes: padrões como plan-and-execute e loops de verificação fornecem pontos naturais de inserção para checagens de política.
Avaliação de Agentes: segurança só é real se for testada, monitorada e verificada por regressão ao longo do tempo.
Tarefas de Longo Horizonte: orçamentos, checkpoints e verificação intermediária reduzem risco composto.

Segurança para agentes é, em última instância, um exercício de engenharia de limites confiáveis: o modelo propõe, mas um sistema confiável decide o que é permitido, o que é revisado e o que é bloqueado — mantendo erros pequenos, observáveis e recuperáveis.