AI Agente Guardrails: costruire un cancello d'azione a quattro controlli

Le barrette di protezione dell'agente AI non devono contenere un unico prompt, un unico classificatore o un solo pulsante di approvazione. Per un agente che può modificare lo stato esterno, la default pratica è un cancello d'azione a quattro controlli: decidere se l'azione è consentita, dimostrare che il chiamer ha l'autorità per questa azione esatta, vincolare il tentativo, quindi verificare l'effetto esterno. Ogni controllo risponde a una domanda diversa. Combinandoli in una sola bandiera safe: true nasconde se un agente è bloccato, in attesa di una persona, fuori dal budget di un nuovo tentativo, o semplicemente manca la prova dopo una chiamata agli strumenti. Tenete questi stati separati e il sistema può fallire chiuso senza trattare ogni pausa come un incidente. Mettere la politica al limite dell'azione Inizia riducendo quello che l'agente può chiedere a uno strumento di fare. Un portale politico dovrebbe ricevere dati di azione strutturati, non solo prose: Il risultato della politica dovrebbe essere uno di allow , deny o unknown . Unknown è importante. Una classificazione mancante non è un permesso, e la forza di ambiguità in allow o deny rende il modello inventare certezza per conto dell'operatore. Questo cancello deve anche verificare se lo strumento appartiene al set di capacità dell'agente. La Guida dell'OWASP in materia di agenzia eccessiva identifica l'eccessiva funzionalità, le autorizzazioni e l'autonomia come cause radicali separate. Le sue attenuazioni sono corrispondentemente concrete: espongono solo le estensioni necessarie, preferiscono le funzioni strette rispetto ai comandi aperti, concedono autorizzazioni minime downstream e applicano le autorizzazioni nel sistema downstream. L'ultimo limite conta. Un'istruzione come never delete production data è utile nel contesto, ma non è un controllo di autorizzazione. Un endpoint di cancellazione dovrebbe respingere un'identità non autorizzata anche quando un agente presenta una ragione persuasiva. Allo stesso modo, un flusso di lavoro di sola lettura non dovrebbe ricevere un cliente le cui credenziali possono scrivere. I modelli di barriere hanno ancora un lavoro, ma conosci il loro tempismo. La Documentazione SDK OpenAI Agents distingue le barriere di ingresso/uscita dell'agente dalle barriere di controllo degli strumenti di funzione. Si osserva inoltre che una barriera di protezione di ingresso parallelo può finire dopo che l'agente ha già consumato token o executato strumenti. Per un limite di effetti collaterali, utilizzare un controllo di blocco immediatamente prima dell'esecuzione, supportato da una vera autorizzazione downstream. Il default ragionevole è: rifiutare gli strumenti al di fuori di una lista di autorizzazioni per agente; calcolare gli ambiti richiesti dall'azione strutturata; applicare tali scoppi al di fuori del modello; restituire unknown quando gli input delle politiche sono incompleti; registrare la versione della politica e l'azione con la decisione. I filtri di contenuto non sostituiscono questo cancello. Documentazione della barriera di sicurezza Connect AI di AWS copre argomenti negati, filtri di contenuto, controlli di messa a terra, filtri di parola e controlli di informazioni sensibili, documentando anche i limiti di configurazione e i compromessi di latenza. Queste sono garanzie utili per le entrate e le uscite. Non dimostrano che un rilascio, un pagamento, un messaggio o una mutazione di file siano autorizzati. Legare l'approvazione a un'azione, non a una conversazione Approvato è troppo vago per essere eseguito. Un'approvazione sicura è un brief di breve durata legato all'azione esatta della persona esaminata. Al minimo, insistere: Ricominciare il processo di azione subito prima dell'esecuzione. Se la risorsa, gli argomenti, l'attore, lo strumento, l'impatto o la scadenza differiscono, l'approvazione non corrisponde. Chiedete di nuovo invece di estendere una vecchia decisione sul nuovo lavoro. Questo impedisce una classe silenziosa ma seria di fallimenti. Una persona può approvare un candidato a rilascio per un repository, quindi il contesto dell'agente cambia, un nuovo tentativo ricostruisce argomenti diversi o un'altra esecuzione riutilizza lo stesso stato di conversazione. Un booliano in flotta libera sopravvive a tutti e tre gli errori. Una ricevuta con obbligo di azione non lo fa. L'approvazione ha anche bisogno di un proprietario e di uno stato di ripresa. awaiting approval non è stuck : ha una decisione nominata, un percorso verso la persona giusta e una scadenza. Dopo una decisione, riprendere dalla busta di azione congelata invece di ripartire la pianificazione e sperare che il modello proponga la stessa operazione. Non ogni azione ha bisogno di un essere umano. Utilizzare l' impatto per decidere: le azioni solo leggibili, reversibili e di scope limitato possono procedere in base a politiche permanenti; le modifiche con il ribasso limitato e ben testato possono utilizzare limiti e audit espliciti; le azioni pubbliche, finanziarie, distruttive, che modificano i privilegi o che hanno altrimenti un alto impatto richiedono un'accettazione esatta; ambiguità sulle vie di impatto verso una persona. La revisione umana è quindi un controllo all'interno della pila, non la pila stessa. L'esecuzione limitata anche dopo l'autorizzazione Un'azione consentita e approvata può comunque andare male. L'esecutore ha bisogno di limiti rigorosi che l'agente non possa rinegoziare in silenzio: una scadenza assoluta, verificata prima di ogni tentativo; un numero massimo di tentativi; una chiave di impotenza per gli effetti collaterali; un massimale delle risorse e degli impatti; un percorso di cancellazione; una regola per quello che succede quando il risultato è ambiguo. L'identità dell'operazione deve rimanere stabile in tutti i tentativi di ritorno. Se si verifica un termine di trasporto dopo che la destinazione ha effettuato una modifica, l'emissione di una nuova identità di operazione può duplicare l'effetto. Se la destinazione supporta l'idempotenza, riutilizzare la stessa chiave. Se offre una ricerca autentica, riconciliatevi prima di riprovare. Se nessuno di questi esiste, smettila di usare unverified piuttosto che pensare che un altro tentativo sia sicuro. Mantenete l'esecutore meccanico. Un modello può raccomandare un nuovo tentativo, ma il codice dovrebbe decidere se attempt < maxAttempts , la scadenza è fresca, la risorsa corrisponde ancora, e l'azione ha una chiave idempotency utilizzabile. Questo è uno dei rari posti in cui i condizionali noiosi sono esattamente il design giusto. I limiti non sono solo per contenere i danni. Conservano la diagnosi. Senza di loro, una chiamata ripetuta può sembrare persistenza, un'operazione scaduta può sembrare progresso lento e un effetto duplicato può sembrare recupero. Con limiti espliciti, l'operatore può distinguere tra stato di lavoro, di attesa, di blocco e di incertezza. Verificare l'effetto in modo indipendente Una risposta dello strumento dimostra ciò che lo strumento ha riportato, non necessariamente ciò di cui l'utente aveva bisogno. Il cancello finale confronta una postcondizione osservabile con il risultato promesso. Preferiamo le prove deterministe: ottenere l'oggetto creato con ID stabile; leggere la sezione di destinazione o il registro di rilascio; verificare l'esistenza del file atteso e le sue corrispondenze hash; eseguire le prove pertinenti; confermare che un messaggio appare nella destinazione prevista; confrontare i valori prima e dopo della risorsa esatta. Non usare due volte lo stesso segnale debole. Se il punto finale di scrittura restituisce { "ok": true } , copiare quel campo in un record di completamento non è una verifica indipendente. Leggi dalla destinazione autorizzata o controlla il prodotto promesso. Alcuni risultati non possono essere verificati immediatamente. Una notifica può essere accettata ma non consegnata, un fornitore esterno può non avere un'API di lettura o un canale di osservazione può essere obsoleto. Rappresentare che come unverified , includere le prove mancanti e il prossimo controllo sicuro, ed evitare di segnalare il successo. Qui si incontrano la salute e la sicurezza operative. La politica e l'autorizzazione impediscono azioni proibite; la verifica degli effetti impedisce il completamento falso. Un agente puo' obbedire a tutte le regole di accesso e comunque fallire nel suo compito. Al contrario, un risultato di successo non giustifica un percorso non autorizzato. Riproduci nove casse prima di fidarti del design. L'artefatto che lo accompagna trasforma i quattro controlli in un piccolo test eseguibile. guardrail cases.json contiene nove azioni proposte. evaluate agent guardrails.mjs si applica una priorità fissa: 1. politica; 2. il campo di applicazione e l'autorità di omologazione; 3. limiti di esecuzione; 4. prove di effetto. Fate partire con: Il riassunto riprodotto è il seguente: I casi interessanti non sono il passaggio pulito o l'ovvia negazione. Un'approvazione è scaduta. Un altro è stato rilasciato per un'impronta digitale di azione diversa. Una scrittura ha esaurito il suo bilancio per riprovare. Un comando eseguito senza effetto osservabile. Una politica non può affatto classificare l'azione. Questi casi dimostrano perché la priorità dello Stato deve essere esplicita. Controllare prima le prove degli effetti e un'azione non autorizzata potrebbe essere etichettata semplicemente non verificata. Controlla l'approvazione prima della politica e potresti chiedere a una persona di autorizzare uno strumento che non avrebbe mai dovuto essere disponibile. Collasso sconosciuto in negazione e l'operatore perde un segnale di qualità dei dati riparabile; collasso in consentire e il sistema inventa autorità. Adatta il dispositivo ai tuoi strumenti. Aggiungere casi di sostituzione delle risorse, perdita di portata, non approvazione riutilizzata, versioni di politiche obsolete, scadenza di scadenza, effetti parziali, fallimento del rollback e un canale di verifica che non è d'accordo con la risposta dello strumento. Il cancello è pronto solo quando quei fallimenti producono lo stato e la prossima azione che avete intenzione. Tenete il confine onesto Le barrette di protezione degli agenti AI funzionano quando ciascun controllo può vetare l'azione per la propria ragione e esporre le prove di tale decisione. La regola compatta è: La politica deciderà se l'azione appartiene. L'autorità impone chi può fare esattamente cosa. I limiti limitano il tentativo. La verifica dimostra l'effetto. Ciò costa più di aggiungere un classificatore. Le approvazioni esatte aggiungono tempo di attesa. I controlli di lettura dopo la scrittura aggiungono chiamate. Gli strumenti stretti richiedono l'ingegneria. Gli stati sconosciuti hanno bisogno di una gestione operativa. Il commercio vale la pena per gli effetti collaterali perché l'ambiguità rimane visibile invece di diventare autorità silenziosa o falso successo. Sidewisp è attualmente in anteprima privata. È inteso come uno strato di salute intorno ai tempi di esecuzione degli agenti esistenti, ma la raccolta e il recupero dell'agente di produzione e della salute non vengono inviati nel repository attuale del sito web. La pila di controllo qui è un modello di implementazione che puoi testare ora, non una affermazione che Sidewisp attualmente lo impone. Se si sta valutando Sidewisp per futuri flussi di lavoro in materia di salute degli agenti, partecipare all' anteprima privata. Nel frattempo, mantenete la busta d'azione e le sue prove nel vostro tempo di esecuzione: la barriera di sicurezza più sicura è quella che si tiene ancora quando il modello è confidentemente sbagliato.