Zapier ridisegna la governance degli agenti IA attorno a regole basate sulle risorse

Zapier ha recentemente pubblicato una retrospettiva tecnica che descrive come ha ridisegnato l'architettura di permessi e approvazioni per Sidekick, il suo agente IA per l'ambiente di lavoro. L'azienda ha abbandonato i prompt fragili basati sugli strumenti a favore di un motore di sicurezza deterministico e basato sulle risorse, progettato per eliminare l'affaticamento da approvazione e prevenire effetti collaterali inattesi nell'esecuzione.

Cosa è successo

Secondo lo Zapier Blog, il sistema di permessi iniziale di Sidekick categorizzava le azioni per tipo di strumento—eseguendo automaticamente le operazioni di sola lettura e fermandosi per richiedere l'approvazione dell'utente per azioni di scrittura, modifica o cancellazione. Tuttavia, questa prima implementazione presentava gravi difetti architetturali. Le richieste di permesso erano legate alle schede del browser aperte, scomparendo se una scheda veniva chiusa o ricaricata, mentre le azioni fallite attivavano ripetutamente prompt ridondanti. Le operazioni di lettura di routine generavano anche schede, facendo sì che i prompt importanti si perdessero nel rumore.

Ancora più critico, Zapier ha scoperto una divisione interna del sistema: le funzionalità integrate di Sidekick e gli script di codice personalizzato scritti per interagire con le app operavano su due motori di permessi separati con regole incoerenti. Inoltre, le regole erano associate agli strumenti anziché agli oggetti—richiedendo il permesso di usare uno "strumento di scrittura" generico invece di proteggere documenti, account o percorsi di directory specifici.

Per risolvere il problema, Zapier ha ricostruito la sicurezza di Sidekick attorno a permessi basati sulle risorse. Le regole ora si collegano direttamente a file, app connesse, siti web o automazioni, mantenendo l'applicazione indipendentemente dal modo in cui l'agente tenta di eseguire un'azione. Zapier ha stabilito una logica di valutazione deterministica rigorosa: le regole esplicite "Never" sovrascrivono tutte le azioni, seguite da prompt "Ask first", consentendo l'esecuzione silenziosa solo quando non esiste una regola di blocco. Inoltre, Zapier ha spostato i prompt di approvazione fuori dalla trascrizione lineare della chat in un pannello di input dedicato e in una casella di posta globale persistente, codificando rigide barriere che impediscono all'agente di proporre concessioni di permessi generiche.

Perché è importante per i costruttori di agenti e i responsabili operativi

Per i piccoli team che costruiscono o distribuiscono agenti IA in produzione, la retrospettiva tecnica di Zapier evidenzia una sfida infrastrutturale fondamentale: la governance human-in-the-loop (HITL) non può essere trattata come un prompt a livello di chat, ma deve essere progettata come un motore di regole backend stato‑aware e consapevole delle risorse. I permessi a livello di strumento offrono confini operativi deboli perché il rischio è definito dalla risorsa di destinazione—ad esempio inviare un messaggio a un canale Slack globale rispetto a un DM a un singolo utente.

Sovraccaricare gli utenti di prompt porta a una convalida riflessa, mentre le architetture senza prompt rischiano la perdita totale di fiducia dopo una singola esecuzione errata. Decouplando lo stato di approvazione dai thread di conversazione attivi e imponendo sovrascritture rigide e deterministiche in cui il rifiuto di un'azione prevale sempre, gli orchestratori possono concedere agli agenti autonomia operativa senza mettere a rischio i dati critici dell'azienda.

Cosa fare questa settimana

1. Spostare la valutazione dei permessi dagli strumenti alle risorse target: Rifattorizzare lo strato di orchestrazione dell'agente affinché i confini di sicurezza valutino l'asset di destinazione (ad esempio una specifica tabella di database o percorso di cartella) anziché la chiamata di funzione stessa.
2. Applicare sovrascritture di policy deterministiche hardcoded: Implementare un motore di regole esplicito al di fuori della finestra di contesto del modello, dove le regole di blocco rifiutano incondizionatamente l'esecuzione prima di qualsiasi chiamata a uno strumento LLM.
3. Separare lo stato human-in-the-loop dall'interfaccia chat: Conservare le richieste di approvazione in una coda server persistente affinché i blocchi di esecuzione pendenti sopravvivano a schede del browser chiuse e a compiti di background a lunga durata.

Fonti

• How much should an AI decide without asking you first? — Zapier Blog