Il solo 'Read-Only' non basta: Guardrail per gli agenti AI
Gli ingegneri senior spesso dicono una cosa per mantenere sicuri gli agenti AI: dare loro l'accesso in sola lettura (read-only).
Sembra sicuro. L'agente può investigare su query lente o riassumere gli schemi senza rompere nulla.
Ma il 'read-only' non è un modello di sicurezza. È un limite.
Nel momento in cui il tuo agente deve svolgere un lavoro utile, il 'read-only' lo blocca. Se un agente trova un indice errato o una riga corrotta, non può correggerla. Ti ritroverai con un assistente che indica un incendio ma non può prendere una manichetta.
Spesso i team rinunciano e concedono all'agente l'accesso in scrittura (write access). È allora che inizia il vero pericolo.
La vera domanda non è "l'agente dovrebbe scrivere". La vera domanda è "come si governano quelle scritture".
Non cercare di governare le scritture tramite istruzioni. Non inserire regole nel system prompt come "non eliminare mai una tabella".
La prompt injection rende queste regole inutili. Un attaccante può usare una riga di dati o un commento per ingannare l'agente e spingerlo a ignorare le tue regole. Se il guardrail risiede nella stessa finestra dell'agente, l'agente può argomentare per aggirarlo.
Hai bisogno di una distinzione tra scritture non governate e scritture mediate.
• Scritture non governate: l'agente decide di eseguire un comando e il database lo esegue. L'unico controllo è il giudizio dell'agente stesso. • Scritture mediate: il comando passa attraverso un checkpoint esterno all'agente. Questo checkpoint si trova nel percorso dei dati tra l'agente e il database.
Una scrittura mediata funziona così:
- L'agente propone un'istruzione (statement).
- Un proxy o un piano di controllo (control plane) analizza l'istruzione.
- Il proxy classifica il rischio.
- Il proxy decide se consentirla o richiedere l'approvazione di un essere umano.
Questo approccio ti protegge dalla prompt injection. Un'istruzione malevola potrebbe ingannare l'agente portandolo a scrivere un comando DROP TABLE, ma non può ingannare il proxy. Il proxy non legge l'intento dell'agente; guarda solo il comando SQL effettivo.
Usa questa struttura per rimanere al sicuro:
- Consenti automaticamente le letture sicure. Lascia che gli agenti eseguano liberamente query SELECT per mantenere il lavoro veloce.
- Filtra le scritture rischiose. Richiedi l'approvazione umana per DELETE, UPDATE o modifiche allo schema.
- Registra tutto. Mantieni un registro immutabile di chi ha proposto una modifica e di chi l'ha approvata.
Non fare affidamento sulle read replica per la sicurezza. Le repliche aiutano nelle investigazioni, ma non possono applicare correzioni. Per risolvere un problema in produzione, devi scrivere sul database primario.
La mediazione permette all'agente di essere utile mantenendo al sicuro i tuoi dati.
Community di apprendimento opzionale: https://t.me/GyaanSetuAi