Para quem é este playbook
CIO, CISO, plataforma e owners de agentes que já passaram da pergunta “qual gateway comprar” e precisam operar risco em produção: quando exigir humano, quando negar por padrão, e como matar uma sessão sem depender do próprio modelo.
Foco: chat assistido vs tool-use, HITL por irreversibilidade e kill-switch fail-closed. Não é rehash de control plane/gateway da Semana 1 nem playbook genérico de governança.
Em uma frase
Chat erra no que diz. Tool-use erra no que faz. HITL e kill-switch só funcionam se forem infraestrutura (credencial, gateway, handoff), não pedido educado ao LLM.
Matriz: chat assistido vs tool-use
| Dimensão | Chat assistido (sem side-effect) | Tool-use / agente com ação |
|---|---|---|
| Superfície de risco | Conteúdo: confabulação, vazamento em prompt, bias (NIST AI 600-1: Human-AI Configuration / Confabulation) | Side-effects: API, escrita, pagamento, egress, privilege (OWASP ASI02 tool misuse, ASI03 identity/privilege, ASI10 rogue agents) |
| HITL obrigatório | Exceções: só quando o humano executa a ação com base no texto (cuidado com ASI09: rubber-stamp) | Sim para writes de baixo risco (1 reviewer); mais estrito (multi-review / out-of-band) para financeiro, delete, mensagem externa (AWS AGENTSEC04-BP02) |
| Quando NÃO forçar HITL em tudo | Leitura/consulta com DLP + logging de sessão | Read-only com allowlist + rate limit (fadiga de aprovação se tudo for HITL — mesmo BP AWS) |
| Kill-switch | Desativar app/canal; revogar API key do usuário | Infraestrutura: revogar credencial/sessão do agente, deny no gateway, terminate + handoff/compensação |
| Fail mode | Content filter / recusa de resposta | Fail-closed: crash, timeout ou verdict malformado = deny |
| Evidência mínima | user_id, prompt hash/redacted, model, flags de policy de output | Quem aprovou + tool + hash dos args + policy version + allow/deny + modelo/versão + eventos de kill |
Reclassificação obrigatória: chat com plugins/MCP/shadow tools embutidos deixa de ser chat. Trate como tool-use: inventário, identidade first-class e os controles abaixo.
HITL: por irreversibilidade, não por mensagem
HITL em toda mensagem mata operação e gera governance drift (OWASP ASI09: humano vira carimbo). O desenho certo (AWS Well-Architected Agentic AI Lens, AGENTSEC04-BP02):
Exigir HITL quando a tool
- Altera estado irreversível (delete, overwrite sem undo);
- Tem efeito externo (e-mail/Slack/WhatsApp a terceiros, post público);
- Move dinheiro ou compromisso comercial;
- Toca PII sensível em escrita ou exportação ampla;
- Muda IAM / privilégios / secrets.
Não exigir HITL (com compensações) quando
- Tool é read-only sob allowlist;
- Há rate limit, DLP e audit;
- O classificador de risco (abaixo) coloca o call em tier baixo.
Aprovação amarra ao conteúdo, não à sessão
Referência útil: Agent Hooks (Microsoft Responsible AI, AGENT-HOOKS-0.1, ago/2026): approval ligado a identidade do conteúdo (hash do call), InterceptionRecord exportável, deny normativo. “Aprovar a sessão” e deixar o agente mudar args depois é falha de desenho.
Timeout com default deny: stall infinito não é segurança. Sem resposta humana no prazo, deny e escalone (AGENTSEC04-BP02).
Classificador de risco: determinístico
O tier de HITL não deve ser decidido pelo mesmo LLM que processa input não confiável.
Padrão WA Lens (AGENTSEC04-BP02): classificador determinístico (regras, Cedar, Rego, policy engine) com inputs como: tipo de tool, destino (interno/externo), volume, tags de dados, irreversibilidade.
Fluxo mínimo:
- Interceptar pre_tool;
- Classificar tier (L0 leitura → L3 financeiro/externo/IAM);
- L0–L1: allow com audit; L2: 1 reviewer; L3: multi-review / out-of-band;
- Verdict allow/deny/transform com
reason_code; - Crash/timeout/malformed = deny (fail-closed).
Kill-switch fail-closed (o que conta de verdade)
O que NÃO é kill-switch
- Prompt do tipo “pare agora” / “ignore previous”;
- Flag no processo do agente que o próprio agente pode limpar;
- “Hardware kill” de marketing sem attestation e runbook;
- Quarentena marcada como not implemented vendida como GA.
O que é kill-switch em produção tool-use
Pacote mínimo (síntese Agent Governance Toolkit / Hypervisor Execution Control + Agent Hooks + prática de IAM):
- Revogar credencial e sessão do agente (e tokens de tools);
- Deny no gateway / policy path (novas calls bloqueadas);
- Terminate execução em curso conforme o runtime permitir;
- Handoff humano + compensação (rollback, mensagem ao cliente, ticket);
- Agente não reentra sem reset humano explícito;
- Log:
kill_id, actor, reason,agent_id, timestamp.
Papel e SLA de contenção devem estar no RACI. Pesquisa Okta Global CISO Insights 2026 (n=306 CISOs; campo junho/2026) aponta maturidade ligada a inventário/controle/autorização de agentes e a revogação rápida em organizações “advanced”. Use como contexto de compra de IAM de agentes, não como verdade universal nem como percentual para headline.
Âncoras de referência (RFP/ops)
| Âncora | Uso neste playbook | Caveat |
|---|---|---|
| Agent Hooks (0.1) | Contrato fail-closed, deny normativo, approval por hash, InterceptionRecord | Cooperativo: não é sandbox contra host hostil |
| Agent Governance Toolkit + spec Hypervisor | Rings, kill-switch, handoff, audit hash-chain | Partes em Draft; quarantine pode estar “not implemented” — não vender como GA completo |
| OWASP Top 10 Agentic 2026 | ASI02 tool misuse · ASI03 identity/privilege · ASI09 human–agent trust · ASI10 rogue agents | Taxonomia de risco, não produto |
| AWS WA Agentic Lens AGENTSEC04-BP02 | HITL por tier, timeout fail-safe, classificador determinístico | Padrão de arquitetura, não feature de um SKU |
| Okta CISO Insights 2026 | Pressão de budget para identidade/revogação de agentes | Survey n=306; não extrapolar % |
Outros sinais da pauta Semana 2 (AgentCore Guardrails-in-policy, Foundry Observability, NIST Agent Standards Initiative) entram com mais peso na peça de audit trail; aqui bastam como contexto: policy fora do código do agente, identidade first-class, traces no plano SRE.
Regras práticas para RFP e runbook
- Separe inventário chat-only vs tool-use (MCP/plugins reclassificam).
- HITL só nos tiers L2–L3; meça fila de aprovação (fadiga = risco ASI09).
- Approval com
approval_context_identity(hash), não “OK na thread”. - Kill-switch testado em drill trimestral: revogar + deny + handoff em minutos, não horas.
- Fail-closed em crash/timeout/malformed verdict.
- Evidência mínima de tool-use na mesma linha do evento (campos detalhados na peça 2 da série).
- Não aceite “guardrail só no prompt” como controle de side-effect.
Erros clássicos
- HITL em toda mensagem de FAQ;
- Kill-switch = system prompt;
- Aprovar sessão e deixar args mudarem;
- Classificador de risco = “pergunte ao modelo se é perigoso”;
- Chat com MCP tratado como baixo risco;
- Drill de kill nunca feito porque “não queremos derrubar o piloto”.
FAQ
Todo agente em produção precisa de HITL?
Não. Read-only allowlisted com audit pode rodar sem humano por turno. Writes irreversíveis, externos, financeiros ou com PII sensível sim.
Kill-switch no gateway basta?
Deny no path é necessário, não suficiente. Sem revogação de credencial/sessão o agente pode tentar outro caminho. Sem handoff, o incidente vira silêncio.
Agent Hooks resolve sozinho?
É contrato de interceptação fail-closed entre frameworks. Não substitui IAM, sandbox hostil nem SIEM. Exija conformance e export de InterceptionRecord no RFP.
Por que citar OWASP ASI09?
Porque HITL mal desenhado vira carimbo. Timeout deny + aprovação por conteúdo + métrica de fila combatem isso.
Okta prova que meu setor está atrasado?
Não. É survey (n=306). Serve para argumentar investimento em identidade e revogação de agentes, não para KPI público inventado.
Fontes
- Microsoft Responsible AI — Agent Hooks (27/08/2026)
- Microsoft Open Source — Agent Governance Toolkit (02/04/2026); spec Hypervisor Execution Control
- OWASP GenAI — Top 10 for Agentic Applications 2026
- AWS Well-Architected — Agentic AI Lens AGENTSEC04-BP02 (HITL)
- Okta — Global CISO Insights 2026 (n=306)
- NIST AI 600-1 (confabulation / human-AI configuration); NIST AI Agent Standards Initiative (contexto de identidade)
- Metodologia de comparativos iab2b.site v1
Disclaimer editorial
Playbook informativo da iab2b.site. Não é ranking, endosso de vendor nem aconselhamento jurídico/segurança. Specs OSS e surveys mudam; confirme status GA/Draft e números na fonte antes de RFP ou board. Sem preços, sem Market Guides sob paywall, sem métricas inventadas.