Um agente com a chave do utilizador não é delegação — é perda de fronteira

A cadeia de autoridade precisa de quatro identidades visíveis

Uma execução deve distinguir utilizador ou serviço originador, agente/orquestrador, workload técnico e ferramenta chamada. Colapsar tudo num token partilhado impede revogar um agente sem parar todos e torna o log incapaz de provar delegação.

Credenciais em prompts, memória, logs ou respostas de ferramentas podem propagar-se entre tarefas. Segredos estáticos aumentam a janela de abuso; identidade de workload e tokens curtos reduzem exposição, desde que o agente não possa aumentar os próprios scopes.

Modele autorização pela consequência, não pela conveniência da integração

Classifique ferramentas por leitura, escrita reversível, mudança sensível e ação irreversível. Dê ao agente apenas os recursos necessários à tarefa e recuse parâmetros fora do conjunto permitido. A descrição da ferramenta nunca deve ser o único controlo.

Para e-mail, pagamentos, publicação, eliminação ou permissões, use confirmação humana vinculada ao conteúdo final ou políticas pré-aprovadas com limites baixos. Um modelo não deve poder reinterpretar uma aprovação genérica para uma ação diferente.

Comece por eliminar segredos partilhados dos cinco agentes com maior impacto

Mapeie onde a credencial nasce, é armazenada, entra no contexto, é apresentada à ferramenta e é revogada. Substitua segredos longos por identidade de workload ou emissão dinâmica e restrinja a audience.

Teste abuso: tool poisoning, prompt injection, replay, troca de recurso e tentativa de ampliar scope. Após qualquer mudança de modelo, prompt, memória ou ferramenta, execute novamente a matriz porque a superfície de decisão mudou.

• Não colocar segredos no prompt ou memória persistente.
• Não usar o token do utilizador sem registo explícito de delegação.
• Não confiar no modelo para fazer enforcement de autorização.
• Não lançar sem revogação seletiva e kill switch ensaiados.