Pular para conteúdo

Capítulo 3.7 — Prompt não é política, tool description não é segurança, depreciação não é só metadata

🎯 Objetivo

Consolidar três anti-padrões que merecem destaque explícito, pois são fonte recorrente de incidentes em agentes corporativos.

🔐 3.7.1 - Prompt não é política

Escrever "não faça X" no prompt pode ajudar, mas não garante comportamento. Políticas críticas precisam estar em:

  • código;
  • autorização;
  • sandbox;
  • validação;
  • runtime.

Exemplos:

  • Em vez de "não envie e-mail para domínios externos no prompt", remova a permissão na credencial e bloqueie egress na rede.
  • Em vez de "não acesse dados sensíveis no prompt", aplique RBAC/ABAC no retriever e filtros obrigatórios por tenant.

🔧 3.7.2 - Tool description não é segurança

A descrição de uma tool ajuda o modelo a escolher, não impede uso indevido. Segurança real exige:

  • tool registry com permissões;
  • allowlist;
  • policy engine;
  • autorização explícita;
  • validação de argumentos;
  • HITL;
  • logs e auditoria;
  • rate limits e circuit breakers.

🗑️ 3.7.3 - Depreciação não é só metadata

Marcar uma tool como deprecated no metadata não impede o modelo de tentar usá-la. Prompts dizendo "não use esta tool" também não garantem comportamento - são instruções probabilísticas em texto livre. A descrição da tool, igualmente, não é mecanismo de segurança: é metadado de descoberta.

O enforcement real precisa acontecer em camadas determinísticas e independentes do modelo:

Camada Responsabilidade
Tool registry Marca tool como deprecated, retorna substituta sugerida, registra owner e janela. Visualização.
Discovery / lazy loading Não expõe tool deprecated a novos agentes; existing agents recebem warning
Harness / executor Bloqueia chamadas a tools com status removed ou blocked. Permite com warning para deprecated.
Policy engine Recusa via Rego/Cedar quando policy explícita exige not deprecated
Credenciais / IAM Revoga acesso a backend da tool removida
Allowlist no executor Lista explícita de tools permitidas para aquele agente
Audit log Toda tentativa de uso de tool deprecated é registrada
Alerta operacional Monitor de uso de deprecated dispara revisão de migração

Fluxo recomendado de janela de migração:

  1. Anunciar depreciação com data alvo de remoção.
  2. Marcar deprecated: true no registry.
  3. Medir uso atual (tool, agente, tenant).
  4. Criar substituta com schema + testes de paridade.
  5. Comunicar consumidores e owners.
  6. Bloquear novos agentes/tenants via registry + policy.
  7. Mover consumidores existentes em ondas; cada onda exige eval comparativo.
  8. Após corte, mover status para removed; bloqueio fica no executor.
  9. Manter audit trail por período definido por compliance.

Resumo. Metadata ajuda descoberta. Bloqueio é responsabilidade do caminho de execução. Sem isso, "deprecated" vira sugestão e o modelo continua usando a tool antiga.

🧪 3.7.4 - O que ainda não é consenso em tool lifecycle para agentes

Este sub-capítulo é um convite a pensar criticamente: muitas práticas em torno de tool lifecycle estão se formando agora. Há padrões emergentes, não consenso fechado.

Pontos em aberto:

  • Granularidade do versionamento. Semver para tool API funciona, mas efeitos colaterais (ex.: nova validação) podem quebrar agentes sem mudar o schema. Não há padrão dominante para versionar "comportamento" separado de "interface".
  • Compatibilidade de schemas com prompt caching. Ao mudar uma tool, prompts cacheados podem virar stale e produzir tool calls inválidos. Como invalidar cache de forma fina é problema aberto.
  • Shadow mode para tools. Conceitualmente útil (executa tool nova em paralelo sem efeito), mas tools com efeitos colaterais reais não têm "shadow" verdadeiro sem sandbox completa, que é cara.
  • A2A e versionamento entre agentes. Quando um agente B é consumido por agente A via A2A, breaking changes em B se propagam. Mecanismos de contrato e janela ainda estão sendo padronizados pela própria spec do A2A.
  • MCP servers comunitários e supply chain. Como tratar tool exposta por MCP server de terceiro que muda sem aviso? Padrão emergente: pinning de versão + assinatura + revisão de capabilities.
  • Migração assistida por LLM. Há experimentos com LLMs reescrevendo agent code para nova versão de tool. Útil em prototipagem, perigoso em produção sem eval.
  • Sunset vs hard removal. Quando uma tool é arriscada (ex.: deletion com side effect), basta marcar deprecated ou exige remoção imediata? Política depende do risco, não do calendário.

Posição editorial deste livro:

  • Versione interface E comportamento.
  • Trate cache como artefato com versão; invalide ao mudar tool.
  • Trate MCP servers/A2A peers como dependências de supply chain.
  • Considere shadow mode útil apenas quando há sandbox; caso contrário, é ilusão.
  • Não delegue migração crítica de tool a LLM sem eval e human review.
  • Documente cada janela como ADR.

📌 Checklist

  • [ ] Há separação clara entre instrução probabilística (prompt) e controle determinístico (código)?
  • [ ] Toda tool sensível tem allowlist, policy e autorização?
  • [ ] Depreciação tem etapas determinísticas, não só metadata?
  • [ ] Há janela documentada, métricas de uso e bloqueio progressivo?
  • [ ] Existe rollback definido?
  • [ ] MCP servers e A2A peers usados têm pinning de versão e revisão de capabilities?