A chave não vai no agente

A pergunta que importa não é se o agente é inteligente o suficiente. É: o que acontece quando o ambiente do agente é comprometido, o prompt vaza ou um registro captura uma credencial?

Se a resposta for “a chave do Omie / Mercado Pago / Asaas do cliente estava no .env do runtime”, o incidente não é só de ferramenta de IA — é de custódia de credencial do cliente.

O padrão errado (ainda comum)

Agente → token do cliente no .env → API do CRM/ERP/pagamentos

Funciona em demonstrações. Em produção, qualquer comprometimento do ambiente, de uma ferramenta ou do registro expõe a credencial completa, sem escopo, limite ou trilha útil de quem pediu o quê.

O padrão certo

Agente → chave agt_* (só Gaten) → política → cofre → API do cliente

O agente nunca recebe o segredo do conector. Recebe uma identidade própria, uma lista de ferramentas permitidas e limites. Quando a política exige, a ação espera uma aprovação humana. Depois, a decisão e o resultado ficam na auditoria.

A chave fica no Gaten. O agente age sob política.

O que isso muda na prática

• Vazamento do runtime do agente ≠ vazamento da API key do cliente.
• Cada ação passa por escopo de ferramenta e regras de valor/risco.
• Auditoria legível: quem, o quê, decisão da política, resultado.
• Rotação e revogação no cofre, sem reconfigurar o agente inteiro.

Se você opera agentes com credenciais de clientes, custódia não é um recurso secundário. É o pré-requisito para o restante da operação.