Eccessiva agenzia e confused deputy

Un agent che ha più capability di quelle necessarie per il suo compito è una responsabilità in attesa di essere sfruttata. Ruba la sua chiave, ingannalo con un’istruzione iniettata, o comprometti una dipendenza — e tutto ciò che quella chiave può fare è ora nelle mani dell’attaccante. Questo è il problema dell’eccessiva agenzia, e si amplifica con un pattern strettamente correlato chiamato il confused deputy: l’agent non è compromesso direttamente, è convinto. Un payload di prompt injection in una pagina web recuperata, in un documento o nel risultato di un tool dice all’agent di compiere un’azione che è legittimamente autorizzato a eseguire — spostare denaro, eliminare un record, inviare un messaggio — per conto dell’attaccante. Entrambi i problemi condividono una causa radice: la chiave che un agent compromesso possiede è troppo potente per il compito che esegue. La difesa è la minima agenzia — dai a ogni agent esattamente la capability richiesta dal suo compito, e nient’altro.

​

1. Cosa rende un agent eccessivamente capace

Quando ogni agent in un workspace condivide una chiave, o quando una chiave viene emessa una volta e mai riesaminata, la capability deriva verso l’alto:

• Modelli non limitati — l’agent può chiamare qualsiasi modello nel workspace, inclusi quelli costosi o altamente capaci di cui non ha mai bisogno.
• Nessun tetto di spesa — un loop incontrollato, un’injection attivata o un attacco di billing può esaurire il saldo del workspace prima che te ne accorga.
• Nessuna scadenza — una chiave emessa durante uno sprint è ancora valida un anno dopo, molto tempo dopo che l’agent per cui è stata creata è stato ritirato.
• Nessun vincolo IP — la credenziale funziona da qualsiasi posto, quindi una chiave trapelata non ha limiti geografici.
• Nessuna allowlist dei tool — l’agent può invocare qualsiasi tool, anche quelli non correlati alla sua funzione.

Ognuno di questi da solo è un raggio di esplosione allargato. Combinati, un singolo agent compromesso può fare tutto ciò che un amministratore del workspace può fare — chiamare il modello più potente, spendere tutto il saldo, raggiungere ogni tool.

​

2. Il pattern del confused deputy

Il confused deputy è una specializzazione dell’eccessiva agenzia. L’agent non viene dirottato; viene convinto. Un payload di prompt injection in una pagina web recuperata, in un documento o nel risultato di un tool dice all’agent di compiere un’azione che è legittimamente autorizzato a eseguire — spostare denaro, eliminare un record, inviare un messaggio — per conto dell’attaccante. L’agent agisce. Era autorizzato a fare esattamente quello. Il controllo di autorizzazione passa. Il danno è fatto. La difesa richiede due cose che lavorano insieme:

1. Scope ristretto — l’agent non può essere ingannato a fare qualcosa che il suo compito non ha mai inteso, perché non è autorizzato a farlo del tutto.
2. Approvazione umana per le azioni irreversibili — anche all’interno dello scope autorizzato, una chiamata ad alto rischio richiede che un essere umano confirmi prima dell’esecuzione.

​

3. Difesa in profondità: i quattro layer

OrcaRouter applica la minima agenzia attraverso quattro controlli indipendenti che si compongono su una singola chiave API. Nessuno richiede una modifica al codice del tuo agent.

​

Layer 1 — Chiave con scope (identità + limiti rigidi)

Ogni agent dovrebbe avere la propria chiave API. La chiave porta limiti rigidi che il gateway applica indipendentemente da ciò che l’agent richiede: Questi limiti vengono applicati al livello della chiave — prima di qualsiasi policy, prima di qualsiasi chiamata al modello. Sono il confine più esterno del raggio di esplosione.

​

Layer 2 — Policy del firewall (allowlist dei tool)

Collega una policy del firewall alla chiave tramite firewall_policy_id. La policy governa ogni chiamata a tool che quella chiave emette:

• Scrivi regole che consentono i nomi dei tool che l’agent usa legittimamente (i glob del nome del tool sono supportati — es. db.query*).
• Imposta il default_verdict della policy su deny così tutto ciò che non è esplicitamente elencato viene bloccato.
• Aggiungi predicati sugli argomenti per limitare anche i tool consentiti — es. consenti db.query solo quando l’argomento database corrisponde a uno schema specifico.

Una chiave senza collegamento al firewall ricade sulla policy di default del workspace. Per gli agent con esigenze di tool ristrette, un collegamento esplicito con una policy restrittiva è sempre preferibile all’affidarsi al default del workspace. Vedi Regole del firewall per il linguaggio di matching completo.

​

Layer 3 — Approvazione umana per le azioni ad alto rischio (pending_approval)

Per le chiamate a tool irreversibili o di alto valore — un dispatch di pagamento, l’eliminazione di un record, l’invio di un’email — aggiungi una regola pending_approval. Il flusso:

1. L’agent emette la chiamata a tool. Il firewall la trattiene e restituisce una risposta “held” che porta un id di approvazione. La chiamata non raggiunge il tool.
2. Un revisore approva o rifiuta fuori banda — dalla console (Developer+) o tramite un webhook firmato con HMAC verso il tuo sistema di approvazione.
3. Il tuo agent fa polling sull’id di approvazione. Una volta approvato, ri-invia la chiamata originale con un header X-OrcaRouter-Firewall-Approval monouso. Il gateway la lascia passare esattamente una volta.

Il confused deputy viene fermato qui anche quando lo scope è valido: un essere umano confirma che l’azione è intenzionale prima dell’esecuzione.

​

Layer 4 — Tetto di costo per esecuzione (cap_cost)

Una regola cap_cost nega qualsiasi chiamata a tool una volta che la spesa accumulata dell’esecuzione dell’agent supera un tetto per regola (in centesimi). Questo è il circuit-breaker per:

• Loop incontrollati attivati dall’injection.
• Attacchi di billing che guidano la spesa prima che qualsiasi essere umano se ne accorga.
• Ricorsione accidentale in piani multi-step.

cap_cost opera al livello dell’esecuzione, non al livello della lifetime della chiave — quindi si azzera per ogni invocazione dell’agent, e una singola esecuzione che si comporta male non può esaurire il tetto credit_limit_usd della chiave.

​

4. Una chiave agent ben configurata — esempio

Un agent che riassume i ticket dei clienti usando gpt-4o-mini e interroga una replica in sola lettura dovrebbe essere configurato così:

• model_limits: ["openai/gpt-4o-mini"] — non può scalare a un modello più capace o costoso.
• allow_ips: il CIDR di egress del worker pool — la chiave è inerte ovunque else.
• credit_limit_usd: un tetto settimanale corrispondente al costo previsto del task, con un po’ di margine — es. 5.00.
• expired_time: la fine dello sprint o del periodo di deployment — la chiave si auto-scade senza pulizia manuale.
• environment: "prod" — appare nei filtri dei log e nelle viste delle anomalie.
• guardrail_id: un guardrail con scope alla sensibilità dei dati di questo agent (masking PII, nessun segreto nell’output).
• firewall_policy_id: una policy che consente solo db.query* e ticket.read*, verdetto di default deny.

Quando questo agent viene ingannato a esfiltrare dati tramite un’istruzione iniettata, il raggio di esplosione è: un modello, un range IP, un namespace di tool, un tetto di costo. Il resto del workspace non è interessato.

​

5. Ruoli richiesti

​

6. Relazione con altre minacce

L’eccessiva agenzia è l’abilitatore per quasi ogni altra minaccia per gli agent:

• Chiamate a tool pericolose — una chiave con una allowlist dei tool restrittiva non può essere forzata a chiamare un tool che non elenca, anche se l’injection ha successo.
• Prompt injection — i limiti di scope limitano il danno che l’injection può fare; le porte di approvazione bloccano le azioni irreversibili che l’injection cerca di attivare.
• Modello di threat — la mappa completa della superficie d’attacco, che mostra dove si trova l’eccessiva agenzia rispetto agli altri vettori.

La minima agenzia non previene l’injection. Riduce ciò che l’injection può ottenere. La minima agenzia — una chiave ristretta per agent, una allowlist dei tool restrittiva, un tetto di spesa e l’approvazione umana per le azioni irreversibili — è la difesa primaria contro gli attacchi LLM di eccessiva agenzia e il pattern del confused deputy.