The Pulse
AWS rilascia Dogwood Local Engine per le chiamate agli strumenti degli agenti
AWS ha rilasciato Dogwood Local Engine, una libreria con licenza Apache 2.0 che valuta le chiamate agli strumenti degli agenti di IA in base a policy che tengono conto delle azioni precedenti. Il motore restituisce decisioni di autorizzazio
AI.info Team · Scritto con l’IA ·
Il nuovo motore per le policy di AWS può indicare all’infrastruttura di un agente di IA di bloccare una chiamata a uno strumento, ma non può fermarla da solo. Dogwood Local Engine, rilasciato il 30 settembre con licenza Apache 2.0, valuta le azioni in base a policy che tengono conto di ciò che un agente ha già fatto; un livello separato deve intercettare la chiamata e applicare la decisione.
Questa divisione lascia parte della responsabilità per la sicurezza al di fuori del motore. L’infrastruttura deve fornirgli registrazioni accurate degli eventi pertinenti, impedire all’agente di alterarne lo stato e assicurarsi che un’azione negata non venga mai eseguita. AWS offre agli sviluppatori un valutatore locale delle policy, non un sistema di protezione autonomo attorno a un agente.
Dogwood verifica i passaggi precedenti a una chiamata a uno strumento
Le policy di Dogwood possono definire condizioni basate sulla sequenza, sui tempi e sugli esiti delle azioni precedenti. L’esempio di AWS è un agente di programmazione che può inviare modifiche a Git solo se la sua esecuzione più recente dei test ha avuto esito positivo nei 15 minuti precedenti e nessuna esecuzione successiva dei test ha avuto esito negativo. Un test fallito blocca l’invio; un’esecuzione con esito positivo lo consente soltanto finché non scade quell’intervallo di tempo.
Il motore registra sia gli eventi di richiesta, quando un agente chiama uno strumento, sia gli eventi di risposta, che riportano ciò che lo strumento ha restituito. Emette decisioni sulle richieste, usando risposte come il risultato di un test per valutare le azioni successive. AWS afferma che gli sviluppatori possono aggiornare le policy durante una sessione senza fermare il motore, anche se la cronologia relativa a una regola temporale appena aggiornata parte dagli eventi ricevuti dopo l’aggiornamento.
«Il suo unico compito è emettere decisioni corrette di autorizzazione o diniego in base agli eventi che gli vengono mostrati e all’insieme delle policy».
Jatin Arora, Joseph Tassarotti e Jean-Baptiste Tristan, AWS Open Source Blog
L’infrastruttura resta il punto in cui si applicano le decisioni
Perché il motore funzioni come previsto, l’infrastruttura deve inviargli ogni evento pertinente, eseguire uno strumento solo dopo una decisione di autorizzazione e comunicare successivamente la risposta dello strumento. AWS afferma che l’infrastruttura deve inoltre riservare a sé l’accesso all’interfaccia per gli eventi e ricorrere, dove necessario, all’isolamento a livello di sistema operativo o al sandboxing per impedire che le chiamate agli strumenti alterino lo stato del motore.
Il repository del progetto precisa ulteriormente i limiti del motore: l’applicazione che integra la libreria deve autenticare la provenienza degli eventi, proteggere l’accesso agli aggiornamenti delle policy e ai file di stato e mantenere un registro di audit separato. I registri persistenti del motore vengono periodicamente salvati in checkpoint e sfoltiti; conservano informazioni sufficienti per il ripristino e per prendere decisioni future, ma non una cronologia completa a fini di audit.
Anche la gestione del tempo è una dipendenza. Il motore assegna agli eventi marcature temporali usando l’orologio del sistema host e garantisce che aumentino in modo monotono, ma il repository avverte che uno sfasamento dell’orologio o altre modifiche possono comunque influire sugli esiti delle policy. Una policy può tenere conto soltanto degli eventi che l’infrastruttura le invia effettivamente.
La persistenza aggiunge lavoro a ogni decisione
Per ordinare gli eventi concorrenti, il motore accetta un invio alla volta sotto un lock, gli assegna una marcatura temporale e lo aggiunge a un log. Sincronizza ogni aggiunta su disco prima di valutare la policy. Dopo un arresto anomalo, il motore ricostruisce il proprio stato di valutazione in memoria a partire da uno snapshot salvato e dalle voci più recenti del log; AWS afferma che il log usa redb, un archivio chiave-valore incorporato scritto in Rust.
La scrittura su disco aggiunge latenza prima che uno strumento possa procedere, e il tempo di valutazione varia in base alla struttura delle policy. AWS ha testato sessioni simulate della durata da cinque minuti a 12 ore, che producevano 360 eventi all’ora. Con una finestra temporale della policy di 24 ore, al traguardo delle 12 ore una decisione richiedeva sei millisecondi, un tempo 300 volte superiore rispetto a una finestra di 15 minuti. L’azienda ha inoltre rilevato che, nel suo test con 100 policy, suddividere le operazioni Git in cinque azioni distinte, ciascuna con un ambito specifico, rendeva le valutazioni degli invii circa cinque volte più veloci rispetto all’uso di un’unica azione Git dall’ambito ampio.
Open source, ma l’integrazione spetta agli sviluppatori
Dogwood Local Engine è una libreria Rust che può essere incorporata nell’infrastruttura di un agente o usata in un servizio locale dimostrativo. Il suo rilascio estende Dogwood, il linguaggio open source per le policy introdotto da AWS ad agosto, oltre l’ambiente gestito di AgentCore, mettendo a disposizione degli sviluppatori un motore locale da integrare nei propri sistemi.
Il compromesso è esplicito: i team ottengono un modo per valutare localmente regole che tengono conto della sequenza delle azioni, ma restano responsabili dei controlli che danno efficacia a quelle decisioni. Il motore può negare un invio a Git dopo un test fallito solo se l’infrastruttura registra il risultato del test, invia la richiesta di invio e blocca lo strumento quando la decisione è negativa.