Omnigent: policy per agenti che ricordano cosa è successo prima nella sessione

Databricks ha introdotto le contextual policies in Omnigent, il meta-harness open source per agenti AI. L’idea è semplice e la si può riassumere così: una policy non valuta la singola azione, valuta l’azione alla luce di ciò che è già successo nella sessione. Il post è firmato tra gli altri da Matei Zaharia.

Perché le allow-list non bastano

Gli agent framework di oggi offrono controlli semplici: consenti, nega, chiedi all’utente. Il problema è che la sicurezza di un’azione dipende dal contesto. Un coding agent che fa push su GitHub è innocuo se ha appena lavorato a una feature; lo stesso push è rischioso se prima ha scaricato una pagina web non fidata che potrebbe contenere una prompt injection.

Con le allow-list si dovrebbe bloccare del tutto almeno una delle due azioni, il che rende l’agent inutile per molti casi legittimi. E chiedere approvazione a ogni azione non funziona: gli utenti si stancano dei prompt e approvano in automatico. Il post richiama esplicitamente la “lethal trifecta” di Simon Willison — leggere contenuti non fidati, accedere a dati sensibili, comunicare verso l’esterno — e l’”Agents Rule of Two” di Meta.

Come funziona

Una policy di Omnigent ascolta gli eventi dell’agent (tool call, risposte, input e output del modello) e decide se allow, deny, trasformare il messaggio o chiedere all’utente. La novità è che può aggiornare uno stato di sessione: variabili arbitrarie visibili solo a quella policy. Il server Omnigent conserva lo stato per coppia policy/sessione e lo ripassa all’handler alla chiamata successiva. Scrivere una contextual policy significa scrivere una funzione che riceve stato precedente ed evento, e restituisce aggiornamenti di stato più una decisione.

Essendo un meta-harness, Omnigent applica le stesse policy agli agent che avvolge: Claude Code, Codex, Antigravity, Pi, OpenCode, Hermes, e agent custom su OpenAI Agents SDK o Claude Agents SDK.

Le quattro policy di esempio

La policy Google Drive limita le scritture ai documenti creati dall’agent nella sessione corrente. Se l’agent apre un documento marcato come confidenziale, le scritture si restringono a quell’insieme: è la regola “no write-down” del modello Bell-LaPadula. La risk score policy mantiene un punteggio cumulativo per la sessione; superata una soglia, azioni come inviare un’email passano da ALLOW ad ASK. La cost policy traccia la spesa in model call, chiede conferma a una soglia soft e a quella hard blocca il modello costoso costringendo l’agent a passare a uno più economico invece di fermarsi. La intent-based authorization ricorda il prompt iniziale dell’utente e confronta ogni tool call con quell’obiettivo: se hai chiesto di aggiornare una presentazione, l’accesso a GitHub viene bloccato.

Omnigent è open source in alpha. Il pattern, però, è riusabile a prescindere: la sicurezza contestuale per gli utenti umani esiste da anni, e non c’è ragione perché gli agent debbano essere valutati un’azione alla volta.

In sintesi

• Le contextual policies decidono in base allo stato di sessione: cosa l’agent ha letto, quanto rischio ha accumulato, quanto ha speso.
• Permettono pattern che le allow-list non esprimono: least privilege per sessione, budget cap, restrizione dopo l’accesso a dati confidenziali.
• Essendo Omnigent un meta-harness, le policy si applicano trasversalmente a Claude Code, Codex e agent custom.

Fonte: Contextual Policies in Omnigent: Using session state to better govern AI agents