---
title: "Supervisor de agentes"
subtitle: "Mais inteligência no operador. Menos poder em quem autoriza."
kind: "PLAYBOOK"
number: "07"
updated: 2026-10-06
families: [ai-agent-governance, soc-response, identity-access]
tags: [Agentes, Governança, Autonomia, Policy Engine]
lang: pt
source: https://iaxia.rodrigojorge.me/cases/supervisor-agentes
author: Rodrigo Jorge
project: IA × IA
---

# Supervisor de agentes

**Mais inteligência no operador. Menos poder em quem autoriza.**

Um agente operador investiga com contexto amplo e propõe uma ação. Um supervisor deliberadamente limitado avalia o pedido. Um Policy Engine aplica as regras objetivas antes de qualquer execução.

- Tipo: PLAYBOOK
- Métrica de referência: 3 camadas (investigar, autorizar e executar)
- Famílias de desafio: Governança de IA e agentes, SOC e resposta, Identidade e acessos
- Atualizado em: 2026-10-06

## O problema

Um agente autônomo pode consultar SIEM, EDR, IAM, WAF e cloud, correlacionar sinais e chegar a uma boa hipótese. O risco aparece quando a mesma entidade que investiga também decide sozinha até onde pode agir.

A proposta é separar funções e autoridade. O operador continua poderoso para investigar. A autorização passa por uma camada com objetivo muito mais estreito, menos contexto, menos ferramentas e menor autoridade.

## Arquitetura

1. **Agente operador**: Modelo mais capaz. Investiga, correlaciona, constrói hipótese, reúne evidências e solicita uma ação.
2. **Agente supervisor**: Recebe somente o contexto necessário para uma decisão específica. Aprova, nega ou escala.
3. **Policy Engine**: Aplica regras determinísticas: allow e deny list, autoridade, ativo, identidade, reversibilidade, TTL, schema e kill switch.
4. **Ação**: Executa somente dentro da autoridade delegada. Fora dela, exige humano.

> O supervisor não precisa investigar melhor que o operador. Ele precisa decidir uma coisa muito mais estreita.

## Contrato entre operador e supervisor

O operador não entrega uma conversa inteira para o supervisor. Entrega um pedido estruturado com ação, alvo, evidências, confiança e reversibilidade.

```json
{
  "action": "revoke_session",
  "target": "user_8271",
  "evidence": {
    "credential_leak": "confirmed",
    "impossible_travel": true,
    "active_sessions": 3
  },
  "operator_confidence": 94,
  "reversible": true
}
```

## A resposta também é um contrato

```json
{
  "decision": "APPROVE",
  "policy": "IAM-07",
  "scope": "user_8271",
  "ttl": "15m",
  "requires_human": false
}
```

> Texto livre pode explicar. A autorização que segue para a próxima camada precisa respeitar um schema validável.

## Mesmo incidente. Autoridades diferentes.

**Exemplo operacional**

| | |
|---|---|
| Pedido 1 | Bloquear IP malicioso por 30 minutos |
| Supervisor | APPROVE |
| Policy Engine | Ação temporária, reversível e dentro da autoridade delegada |
| Resultado | Executa automaticamente |
| Pedido 2 | Desabilitar a conta do CFO |
| Supervisor | Pode considerar a evidência suficiente |
| Policy Engine | Identidade privilegiada e ação de alto impacto |
| Resultado | HUMAN APPROVAL REQUIRED |

## A matriz de autoridade

### Pode automatizar

- Enriquecer e correlacionar alertas.
- Criar timeline e reunir evidências.
- Bloquear temporariamente um IP dentro da política.
- Revogar sessão quando identidade, escopo e reversibilidade estiverem dentro da regra.

### Escala a supervisão

- Desabilitar conta privilegiada.
- Alterar configuração crítica.
- Executar ação de grande raio de impacto.
- Qualquer ação irreversível ou crítica.

## Autoridade que se ganha e se perde

A autoridade de agir sem aprovação não é um nível único do agente nem é permanente. Ela é concedida por classe de ação, depois que as decisões do agente naquela classe foram comparadas com a revisão humana em uma amostra definida. Quem mede a precisão não é o próprio agente.

Quando os vereditos passam a divergir da revisão independente acima de um limiar, a classe volta ao modo anterior. O limiar, a janela de observação e quem revisa fazem parte do contrato, não ficam implícitos.

- **Concessão por classe.** Enriquecer, bloquear IP por tempo limitado e revogar sessão são classes distintas. Cada uma sobe de nível sozinha, com a própria evidência.
- **Avaliação independente.** A amostra de decisões é revisada por quem não é o operador nem o supervisor. O agente não corrige a própria prova.
- **Gatilho de redução.** Divergência acima do limiar rebaixa a classe automaticamente. O rebaixamento é executado pela plataforma, fora do modelo.
- **Ações em voo.** O contrato diz o que acontece com o que já foi executado quando a classe cai de nível: reversão, compensação ou só registro. Expirar a autorização não desfaz o que já foi feito.

## O crachá do agente

### O que o crachá declara

- Identidade do agente e responsável humano.
- Contexto que pode consultar e acessos que possui.
- Ações autorizadas, por classe, com o nível atual de cada uma.
- Supervisão exigida, evidência obrigatória e validade com expiração.

### O que fica fora do crachá

- O kill switch. O agente não controla o próprio desligamento.
- O rebaixamento de classe. Quem executa é a plataforma.
- A medida de precisão. Vem da revisão independente.
- Agente sem identidade e autoridade delimitada é uma conta de serviço com poder demais.

## O que realmente reduz o risco

- **Função estreita.** O supervisor não recebe a missão aberta de investigar o incidente inteiro. Avalia um pedido específico.
- **Contexto mínimo.** Recebe apenas os dados necessários para decidir, reduzindo a superfície de interpretação.
- **Menor autoridade.** Não ganha acesso livre ao ambiente e não executa diretamente a ação solicitada.
- **Independência.** Objetivo, contexto e contrato devem evitar simplesmente repetir a mesma cadeia de raciocínio do operador.
- **Controle determinístico.** Políticas objetivas continuam fora do LLM sempre que puderem ser expressas como regra.
- **Humano por impacto.** O humano entra por exceção, política ou impacto. Irreversível ou crítico exige aprovação humana.

## Modelo menor não significa modelo mais seguro

Um modelo menor pode ser útil como supervisor porque a tarefa é estreita, mas tamanho não é garantia de segurança. O controle vem da arquitetura: função limitada, contexto mínimo, contrato rígido, menor autoridade, independência e validações determinísticas.

Uma segunda instância idêntica também não resolve o problema por si só. Se operador e supervisor compartilham os mesmos pressupostos, contexto e forma de decisão, a segunda camada pode repetir a mesma falha.

## Como implementar

1. **1. Catalogue ações**: Liste o que seus agentes podem pedir: consultar, bloquear, revogar, isolar, alterar ou excluir.
2. **2. Classifique impacto**: Defina reversibilidade, criticidade, raio de impacto e identidades ou ativos protegidos.
3. **3. Defina autoridade**: Associe cada ação a automático, supervisor ou aprovação humana.
4. **4. Crie contratos**: Padronize request e response com schema validável e evidência obrigatória.
5. **5. Tire regras do LLM**: Allow list, limites, TTL, escopo, identidade privilegiada e kill switch ficam em código ou policy engine.
6. **6. Registre tudo**: Pedido, evidência, decisão, política aplicada, execução, resultado e eventual intervenção humana.

## Para levar

Não estamos colocando uma IA para confiar em outra IA. Estamos separando autoridade.

---

Fonte: https://iaxia.rodrigojorge.me/cases/supervisor-agentes · Guia IA × IA, Rodrigo Jorge. Playbook de defesa: arquitetura para adaptar, não evidência de produção. Use como contexto; valide no seu ambiente.