Policy contestuali in Omnigent: usare lo stato della sessione per governare al meglio gli agenti AI

Di recente abbiamo lanciato Omnigent, un meta-harness open source per agenti AI. Ti consente di continuare a utilizzare gli harness per agenti che già apprezzi, tra cui Claude Code, Codex e agenti personalizzati, aggiungendo al contempo un livello condiviso per la collaborazione, la composizione e le policy.

Per la sicurezza e la gestione dei costi, Omnigent introduce un nuovo potente strumento: le policy contestuali. I framework di agenti odierni dispongono solo di controlli semplici per limitare ciò che un agente può fare, ad esempio regole per consentire, negare o chiedere all'utente l'autorizzazione per varie chiamate a strumenti. Ma questo rende difficile creare policy che siano al contempo sicure e comode per gli utenti. Al contrario, le policy contestuali di Omnigent possono ricordare ciò che è accaduto finora in una sessione (ad esempio, cosa ha letto l'agente o quanti dollari ha speso finora) e utilizzare tale stato per decidere se procedere con l'azione successiva. Ciò consente una vasta gamma di policy avanzate che sono sia più sicure che più comode per gli utenti: dal monitoraggio dinamico del livello di rischio di una sessione, all'implementazione di modelli di sicurezza con privilegi minimi, fino alla possibilità per gli utenti di impostare budget per singole attività per gestire la spesa.

Perché i controlli degli agenti sono migliori con il contesto

Gli agenti AI introducono nuovi tipi di rischi per le aziende. Ad esempio, poiché gli agenti possono subire prompt injection da contenuti non attendibili e ricevere la richiesta di eseguire azioni dannose, è consigliabile evitare che lo stesso agente legga contenuti non attendibili, acceda a dati sensibili e comunichi con il mondo esterno (concetto reso popolare come la "Lethal Trifecta" di Simon Willison e la "Agents Rule of Two" di Meta). Se un'azione sia "sicura" o meno dipende, in parte, da ciò che è accaduto prima: un agente di codifica che esegue un push su GitHub è generalmente accettabile se l'agente ha appena lavorato a una funzionalità per un ingegnere, ma lo stesso push su GitHub è rischioso se l'agente ha precedentemente scaricato una pagina web non attendibile che potrebbe contenere un attacco di tipo injection.

Sfortunatamente, la maggior parte dei software di agenti oggi fornisce solo semplici controlli basati su allow-list o guardrail su singole azioni, ad esempio se consentire i push Git o le ricerche sul web. Per prevenire gli attacchi di injection, dovremmo bloccare completamente almeno una di queste azioni, ma questo risulterebbe restrittivo per molti casi d'uso innocui. Anche chiedere l'approvazione dell'utente per ogni azione non funziona bene, perché gli utenti finiscono per stancarsi delle continue richieste di approvazione.

Lo same vale in altre situazioni. Forse consentire all'agente di un rappresentante commerciale di inviare un'e-mail a un cliente va bene, ma fargli inviare migliaia di e-mail è indice di una compromissione o di un bug. Un agente che modifica un documento che ha creato è OK, ma lo stesso agente che modifica migliaia di documenti interni potrebbe richiedere un controllo accurato. In effetti, molti strumenti di sicurezza per gli utenti umani considerano anche la loro cronologia e non solo l'azione corrente (questa viene definita sicurezza contestuale).

Ecco le policy contestuali

In Omnigent, una policy può ascoltare gli eventi che un agente sta eseguendo (ad esempio, chiamate a strumenti e risposte, e input e output verso l'LLM) e decidere se consentire, negare, trasformare i messaggi o chiedere l'autorizzazione all'utente, in modo simile ai tradizionali guardrail degli agenti. Tuttavia, la policy può anche aggiornare lo stato della sessione: variabili arbitrarie visibili solo a quella policy. Questo può includere il monitoraggio di quante volte un agente ha utilizzato uno strumento specifico, quali documenti ha letto, ecc. Il server Omnigent ricorda lo stato per ciascuna policy e sessione e lo passa al gestore della policy la volta successiva che lo chiama. Per scrivere una policy contestuale, basta scrivere una funzione che accetti il vecchio stato e il nuovo evento che l'agente sta tentando di eseguire, e restituisca gli aggiornamenti di stato e una decisione. Omnigent include già una serie di policy utili pronte all'uso.

Inoltre, poiché Omnigent è un meta-harness, può applicare le tue policy contestuali agli agenti che utilizzano qualsiasi harness nello stesso modo. Omnigent supporta agenti di codifica ampiamente utilizzati come Claude Code, Codex, Antigravity, Pi, OpenCode e Hermes, nonché agenti personalizzati in framework come OpenAI Agents SDK e Claude Agents SDK. Basta avviare gli agenti tramite Omnigent e il server Omnigent intercetterà le loro chiamate a strumenti per applicare le policy.

Esempi di casi d'uso

Ecco i tre esempi di policy integrate fornite oggi con Omnigent. Ciascuna si basa su un tipo diverso di stato della sessione: il contenuto letto finora dall'agente, un punteggio di rischio accumulato della sessione o il costo totale della sessione corrente.

1. Google Drive Policy: limitare l'accesso dell'agente ai soli documenti corretti

La policy di Google Drive regola ciò che l'agente può leggere e modificare in Docs, Sheets e Slides. Per impostazione predefinita, le scritture sono limitate ai documenti creati dall'agente durante questa sessione. Quindi un agente può creare un nuovo documento e modificarlo liberamente, ma non può modificare silenziosamente un file preesistente che non avrebbe mai dovuto toccare. Sarebbe impossibile implementare questo comportamento con semplici allow-list: non vogliamo consentire o negare del tutto lo strumento "scrittura documento", vogliamo consentirlo solo sui documenti che l'agente ha creato nella stessa sessione.

Come secondo esempio di comportamento contestuale in questa policy, puoi contrassegnare un insieme di documenti come riservati: nel momento in cui l'agente ne apre uno, la policy si restringe in modo che le scritture siano limitate a quell'insieme. Anche un documento creato dall'agente un minuto prima diventa inaccessibile, poiché l'aggiunta di materiale riservato al suo interno comporterebbe la fuga di quel contenuto in un file meno protetto. Nella sicurezza classica, questo implementa il modello Bell-LaPadula con la sua regola "no write-down".

2. Policy sul punteggio di rischio: maggiore cautela quando l'agente tocca materiale sensibile

L'attribuzione di un punteggio di rischio è comunemente utilizzata dai team di sicurezza per gestire l'accesso degli utenti umani. In Omnigent, la policy sul punteggio di rischio mantiene un punteggio parziale per la sessione corrente, un singolo numero che traccia il livello di rischio accumulato durante il lavoro dell'agente. Gli utenti possono configurare quali azioni aumenteranno il punteggio e di quanto: una chiamata a uno strumento di routine potrebbe aggiungere un punto o due, mentre la lettura di un documento contrassegnato come altamente riservato aggiungerà molti più punti. Finché il punteggio rimane basso, l'agente lavora senza interruzioni. Una volta superata una determinata soglia, azioni come l'invio di un'e-mail o la condivisione di un file restituiranno ASK anziché ALLOW e chiederanno all'utente di approvare. Quindi, la stessa e-mail che sarebbe stata inviata all'inizio di una sessione potrebbe richiedere l'approvazione umana in un secondo momento, una volta che l'agente ha gestito materiale sensibile a sufficienza da far salire il punteggio.

3. Policy sui costi: tenere sotto controllo la spesa

Una policy di budget tiene traccia di quanto la sessione ha speso finora per le chiamate ai modelli. Dopo aver superato una soglia flessibile (soft threshold), si interrompe per chiedere se continuare. Quando la spesa raggiunge il limite massimo (hard cap), la policy blocca ulteriori chiamate al modello costoso finché l'agente non passa a uno più economico, consentendo alla sessione di continuare anziché interrompersi. La stessa idea si estende oltre la singola sessione. Un team di piattaforma può sovrapporre un limite giornaliero per utente a quello per sessione, in modo che nessuno possa accumulare costi elevati in molte conversazioni separate. In entrambi i casi, il contesto è la spesa cumulativa: la policy non valuta la singola chiamata al modello, ma monitora il totale parziale e interviene quando la sessione o l'utente hanno speso troppo.

4. Autorizzazione basata sull'intento: limitare i privilegi in base allo scopo

L'autorizzazione basata sull'intento imposta i permessi degli agenti in base al prompt iniziale dell'utente, in modo che anche un agente soggetto a prompt injection non possa utilizzare la maggior parte dei suoi strumenti per causare danni. Ad esempio, se avvii una sessione chiedendo a un agente di aggiornare una presentazione di Google Presentazioni, la policy consente a quell'agente di leggere e scrivere su quella presentazione, ma blocca l'accesso se l'agente tenta improvvisamente di utilizzare GitHub. La policy memorizza semplicemente come stato ciò che l'utente ha effettivamente richiesto all'inizio di una sessione, quindi verifica ogni chiamata allo strumento rispetto a quell'obiettivo originale, applicando il principio del privilegio minimo. Si tratta di una policy molto semplice ma potente, resa possibile dallo stato contestuale: puoi configurare gli agenti con molti strumenti per impostazione predefinita, ed essi verranno automaticamente limitati in ogni sessione. La stessa chiamata a uno strumento che va bene in una sessione potrebbe richiedere la tua approvazione in un'altra, a seconda di ciò che hai chiesto di fare all'agente.

Le conclusioni

Man mano che gli agenti svolgono un lavoro sempre più concreto, la parte difficile diventa come controllarli. Gli agenti possono iniziare a causare danni a causa di input dannosi o di semplici bug, e le normali policy basate su liste di elementi consentiti (allow-list) che esaminano le singole azioni non sono abbastanza flessibili da rendere gli agenti sia utilizzabili che sicuri. Le policy contestuali consentono di avere agenti più utilizzabili e più sicuri tracciando dinamicamente lo stato all'interno di una sessione e bloccando le azioni solo quando l'agente ha accumulato un livello di rischio sufficiente. Offrono inoltre uno strumento semplice e potente per gestire i budget a livello di singola sessione, anziché solo per utente al giorno. Omnigent è open source e si integra con i più diffusi agenti di codifica e framework per agenti, consentendoti di iniziare ad applicare queste policy ai tuoi agenti esistenti.

Provalo subito

Omnigent è attualmente open source in versione alpha.

• Inizia con la nostra guida rapida: https://omnigent.ai/quickstart/install
• Aggiungi una stella e clona il repository: https://github.com/omnigent-ai/omnigent
• Segui il tutorial sulle policy: https://omnigent.ai/quickstart/policies
• Leggi la documentazione sulle policy: https://omnigent.ai/docs/policies/overview
• Unisciti a noi su Discord: https://discord.gg/omnigent

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale