Agência excessiva e confused deputy

Um agente que tem mais capacidade do que sua tarefa precisa é um passivo esperando para ser explorado. Roube sua chave, engane-o com uma instrução injetada ou comprometa uma dependência — e tudo que aquela chave pode fazer está agora nas mãos do atacante. Este é o problema de agência excessiva, e ele se compõe com um padrão intimamente relacionado chamado confused deputy: o agente não é comprometido diretamente, ele é convencido. Um payload de injeção de prompt em uma página web recuperada, documento ou resultado de ferramenta diz ao agente para tomar uma ação que ele está legitimamente autorizado a fazer — mover dinheiro, excluir um registro, enviar uma mensagem — em nome do atacante. Ambos os problemas compartilham uma causa raiz: a chave que um agente comprometido detém é poderosa demais para a tarefa que executa. A defesa é a menor agência — dê a cada agente exatamente a capacidade que sua tarefa exige, e nada mais.

​

1. O que torna um agente excessivamente capaz

Quando todo agente em um workspace compartilha uma chave, ou quando uma chave é emitida uma vez e nunca revisada, a capacidade aumenta gradualmente:

• Modelos sem restrição — o agente pode chamar qualquer modelo no workspace, incluindo os caros ou altamente capazes que nunca precisa.
• Sem teto de gasto — um loop descontrolado, uma injeção acionada ou um ataque de billing pode esgotar o saldo do workspace antes que você perceba.
• Sem expiração — uma chave emitida durante um sprint ainda é válida um ano depois, muito depois que o agente para o qual foi criada está aposentado.
• Sem restrição de IP — a credencial funciona de qualquer lugar, então uma chave vazada não tem limite geográfico.
• Sem lista de permissão de ferramentas — o agente pode invocar qualquer ferramenta, mesmo as não relacionadas à sua função.

Qualquer uma delas sozinha é um raio de explosão alargado. Combinadas, um único agente comprometido pode fazer tudo que um admin do workspace pode fazer — chamar o modelo mais poderoso, gastar o saldo completo, alcançar cada ferramenta.

​

2. O padrão do confused deputy

O confused deputy é uma especialização da agência excessiva. O agente não é sequestrado; ele é convencido. Um payload de injeção de prompt em uma página web recuperada, documento ou resultado de ferramenta diz ao agente para tomar uma ação que ele está legitimamente autorizado a fazer — mover dinheiro, excluir um registro, enviar uma mensagem — em nome do atacante. O agente age. Ele estava autorizado a fazer exatamente isso. A verificação de autorização passa. O dano está feito. A defesa exige duas coisas trabalhando juntas:

1. Escopo restrito — o agente não pode ser enganado a fazer algo que sua tarefa nunca pretendia, porque ele não está autorizado a fazê-lo.
2. Aprovação humana para ações irreversíveis — mesmo dentro do escopo autorizado, uma chamada de alto risco exige confirmação de um humano antes de executar.

​

3. Defesa em profundidade: as quatro camadas

O OrcaRouter aplica a menor agência em quatro controles independentes que se compõem em uma única chave de API. Nenhum exige mudança de código no seu agente.

​

Camada 1 — Chave com escopo (identidade + limites fixos)

Cada agente deve ter sua própria chave de API. A chave carrega limites fixos que o gateway aplica independentemente do que o agente solicita: Esses limites são aplicados no nível da chave — antes de qualquer política, antes de qualquer chamada ao modelo. Eles são o limite externo de raio de explosão.

​

Camada 2 — Política de firewall (lista de permissão de ferramentas)

Conecte uma política de firewall à chave via firewall_policy_id. A política governa cada chamada de ferramenta que essa chave emite:

• Escreva regras que permitam os nomes de ferramenta que o agente usa legitimamente (globs de nome de ferramenta são suportados — ex.: db.query*).
• Defina o default_verdict da política como deny para que qualquer coisa não explicitamente listada seja bloqueada.
• Adicione predicados de argumento para restringir até as ferramentas permitidas — ex.: permite db.query apenas quando o argumento database corresponde a um schema específico.

Uma chave sem vinculação de firewall cai de volta para a política padrão do workspace. Para agentes com necessidades restritas de ferramentas, uma vinculação explícita com uma política restrita é sempre preferível a depender do padrão do workspace. Veja Regras de Firewall para a linguagem completa de correspondência.

​

Camada 3 — Aprovação humana para ações de alto risco (pending_approval)

Para chamadas de ferramenta irreversíveis ou de alto valor — um dispatch de pagamento, uma exclusão de registro, um envio de email — adicione uma regra pending_approval. O fluxo:

1. O agente emite a chamada de ferramenta. O firewall a retém e retorna uma resposta “held” carregando um id de aprovação. A chamada não alcança a ferramenta.
2. Um revisor aprova ou rejeita fora de banda — pelo console (Developer+) ou via um webhook assinado por HMAC para o seu próprio sistema de aprovação.
3. Seu agente consulta o id de aprovação. Uma vez aprovado, ele reenvia a chamada original com um header X-OrcaRouter-Firewall-Approval de uso único. O gateway a deixa passar exatamente uma vez.

O confused deputy é parado aqui mesmo quando o escopo é válido: um humano confirma que a ação é intencional antes de executar.

​

Camada 4 — Limite de custo por run (cap_cost)

Uma regra cap_cost nega qualquer chamada de ferramenta assim que o gasto acumulado da run do agente excede um teto por regra (em centavos). Este é o disjuntor para:

• Loops descontrolados acionados por injeção.
• Ataques de billing que geram gasto antes que qualquer humano perceba.
• Recursão acidental em planos de múltiplos passos.

cap_cost opera no nível de run, não no nível vitalício da chave — então ele reinicia por invocação de agente, e uma única run com mau comportamento não pode esgotar o teto credit_limit_usd da chave.

​

4. Uma chave de agente bem escopada — exemplo

Um agente que resume tickets de cliente usando gpt-4o-mini e consulta uma réplica somente leitura deve parecer com:

• model_limits: ["openai/gpt-4o-mini"] — não pode escalar para um modelo mais capaz ou caro.
• allow_ips: o CIDR de egress do pool de workers — a chave é inerte em qualquer outro lugar.
• credit_limit_usd: um teto semanal correspondendo ao custo esperado da tarefa, com alguma margem — ex.: 5.00.
• expired_time: o fim do sprint ou período de deployment — a chave expira automaticamente sem limpeza manual.
• environment: "prod" — aparece em filtros de log e visões de anomalia.
• guardrail_id: um guardrail escopado para a sensibilidade de dados deste agente (mascaramento de PII, sem segredos na saída).
• firewall_policy_id: uma política que lista apenas db.query* e ticket.read*, veredito padrão deny.

Quando este agente é enganado a exfiltrar dados via uma instrução injetada, o raio de explosão é: um modelo, um intervalo de IPs, um namespace de ferramenta, um teto de custo. O restante do workspace não é afetado.

​

5. Papéis necessários

​

6. Relação com outras ameaças

A agência excessiva é o habilitador de quase toda outra ameaça de agente:

• Chamadas de ferramenta perigosas — uma chave com uma lista de permissão de ferramentas restrita não pode ser forçada a chamar uma ferramenta que não lista, mesmo que a injeção tenha sucesso.
• Injeção de prompt — os limites de escopo limitam o dano que a injeção pode causar; portões de aprovação bloqueiam as ações irreversíveis que a injeção tenta acionar.
• Modelo de ameaças — o mapa completo de superfície de ataque, mostrando onde a agência excessiva se situa em relação a outros vetores.

A menor agência não previne a injeção. Ela reduz o que a injeção pode alcançar. A menor agência — uma chave restrita por agente, uma lista de permissão de ferramentas restrita, um limite de gasto e aprovação humana para ações irreversíveis — é a principal defesa contra ataques de agência excessiva em LLM e o padrão do confused deputy.