La sicurezza runtime degli agenti Arcjet porta il controllo nel ciclo d'azione dell'AI

Arcjet ha lanciato la sicurezza runtime degli agenti il 17 settembre, aggiungendo controlli in tempo reale per gli agenti AI dopo il loro ingresso in produzione. Il prodotto mira a colmare il divario tra il monitoraggio di un agente e l'interruzione della sua prossima azione. Questa distinzione conta quando gli agenti possono inviare messaggi, aggiornare database, emettere rimborsi o chiamare strumenti interni.

Il rilascio della sicurezza runtime degli agenti di Arcjet arriva mentre i fornitori di sicurezza competono per controllare questo nuovo livello di esecuzione. I gateway ispezionano il traffico, i sistemi di identità autenticano gli attori e le piattaforme di osservabilità registrano l'attività. Arcjet, invece, punta a inserire i controlli delle policy nel percorso applicativo, dove l'azione proposta da un agente può ancora essere bloccata.

Questa architettura offre agli sviluppatori più contesto per ogni decisione. Richiede però anche di collocare il codice di enforcement attorno alle azioni rilevanti. La scommessa centrale di Arcjet è che le organizzazioni accetteranno questo lavoro di integrazione, perché i controlli esterni non possono vedere abbastanza dettagli dell'applicazione.

Il prodotto combina rilevamento degli agenti, enforcement a livello di azione e registri di audit. Arcjet afferma che i team possono osservare gli agenti tramite la telemetria esistente, quindi aggiungere controlli preventivi attraverso software development kit e integrazioni con framework.

Il lancio non è quindi un'altra promessa generica di rendere i modelli più sicuri. È un tentativo di definire dove inizia la responsabilità quando l'output di un modello diventa un'operazione concreta.

La sicurezza runtime degli agenti Arcjet aggiunge tre livelli di controllo

Arcjet combina visibilità, prevenzione e prove all'interno di un unico flusso di lavoro di produzione.

Il primo livello è l'osservazione. Arcjet afferma che le organizzazioni possono inviare l'attività degli agenti tramite OpenTelemetry, uno standard aperto per la raccolta di tracce, metriche e log. I team che utilizzano Claude possono inoltre connettersi tramite la Compliance API di Anthropic.

Questo processo di acquisizione crea un inventario di agenti e applicazioni. Arcjet associa quindi le singole sessioni all'agente che le ha prodotte. Gli investigatori della sicurezza possono esaminare un flusso di lavoro più ampio invece di cercare tra prompt e chiamate di strumenti scollegati.

L'approccio dipende in parte dal crescente utilizzo della telemetria standardizzata. Il progetto OpenTelemetry sta sviluppando convenzioni di agent observability per segnalare attività degli agenti, attività dei framework e interazioni con i modelli.

Questa standardizzazione può ridurre il lavoro necessario per individuare gli agenti attraverso framework diversi. Tuttavia, la sola osservazione non impedisce un'operazione non sicura. Registra ciò che è accaduto e fornisce contesto per analisi successive.

Il secondo livello è l'enforcement. Arcjet colloca una decisione di policy prima che un agente chiami uno strumento, un database, un'interfaccia di programmazione delle applicazioni o un modello. L'applicazione riceve una risposta tipizzata, come consenti, blocca, oscura o sospendi per revisione.

Una risposta tipizzata è un risultato strutturato che il codice applicativo può elaborare in modo coerente. Consente al flusso di lavoro di fermare un'azione, richiedere l'approvazione umana o restituire una spiegazione all'agente.

Arcjet supporta anche controlli dopo una chiamata. Tali controlli possono ispezionare un risultato prima che venga utilizzato da un'altra fase del flusso di lavoro. Questo crea controlli sia attorno all'azione proposta sia alle informazioni restituite.

Secondo l'azienda, le policy disponibili coprono prompt injection, esposizione di dati sensibili, abuso dell'automazione, limiti di frequenza e quote di risorse. La prompt injection si verifica quando contenuti non attendibili manipolano un modello inducendolo a seguire istruzioni ostili o non intenzionali.

Il terzo livello è l'audit. Arcjet registra la decisione, la versione della policy, l'attore, gli input e il contesto di esecuzione correlato. Questo registro ha lo scopo di mostrare cosa un agente ha tentato di fare e perché il sistema l'ha consentito o rifiutato.

Il comunicato di lancio corretto dell'azienda descrive il prodotto attraverso queste tre funzioni: osservare, applicare e sottoporre ad audit. Il comunicato afferma che le policy possono operare prima e dopo chiamate che coinvolgono modelli, strumenti, database e API.

Questo design affronta uno specifico problema operativo. Un agente di assistenza potrebbe leggere un'email, interrogare un database clienti e preparare una risposta. Ogni passaggio può sembrare innocuo se esaminato isolatamente.

La sequenza combinata può comunque esporre informazioni personali a un indirizzo aggiunto da un aggressore. Arcjet tenta di preservare i passaggi precedenti e valutare il messaggio in uscita nel contesto di quella cronologia.

Il fondatore e amministratore delegato David Mytton ha dichiarato a SiliconANGLE che un esito rischioso può svilupparsi attraverso diverse azioni singolarmente ragionevoli. La copertura originale del lancio ha inoltre riportato integrazioni con diversi importanti framework per agenti.

Queste integrazioni includono Claude Agent SDK, OpenAI Agents SDK, LangChain, Mastra e Agent Framework di Microsoft. La più ampia pagina prodotto di Arcjet dichiara il supporto per 20 SDK e integrazioni con framework.

Questa ampiezza conta perché le distribuzioni di agenti raramente utilizzano un unico runtime comune. Le organizzazioni possono avere agenti web, worker in coda, assistenti di programmazione e flussi di lavoro pianificati che operano attraverso interfacce diverse.

Il prodotto di Arcjet tenta di collegare questi ambienti tramite un modello decisionale condiviso. Il cambiamento più importante non è la schermata dell'inventario. È la capacità di inserire una decisione obbligatoria prima che un'azione venga eseguita.

Il confine di sicurezza si sposta dall'accesso all'azione

Un agente autenticato può comunque compiere l'azione sbagliata con credenziali valide.

Il controllo degli accessi tradizionale chiede se un'identità possa entrare in un sistema. Rimane necessario, ma diventa incompleto quando il software può interpretare obiettivi e selezionare azioni in autonomia.

Un dipendente potrebbe autorizzare un agente a utilizzare una piattaforma di assistenza clienti. Tale autorizzazione non significa automaticamente che l'agente debba rimborsare ogni transazione che incontra. Restano rilevanti l'importo consentito, l'account, il metodo di pagamento e la richiesta circostante.

Lo stesso problema compare nei flussi di lavoro di programmazione. Un agente di coding può disporre di un accesso legittimo al repository pur non avendo l'autorità di esporre segreti, modificare le impostazioni di deployment o eseguire comandi distruttivi.

L'accesso permanente stabilisce un confine esterno. Non conferma che ogni azione entro tale confine rifletta l'intento attuale dell'utente.

Google ha descritto un cambiamento analogo nel suo framework Beyond Zero del 2026. La proposta valuta l'autorizzazione a livello delle singole azioni su risorse specifiche, anziché concedere un ampio accesso all'applicazione.

Arcjet persegue una versione più ristretta e distribuibile di questa direzione. Verifica l'azione utilizzando il contesto disponibile all'interno dell'applicazione. Tale contesto può includere identità, route, nome dello strumento, argomenti tipizzati, passaggi precedenti e utilizzo accumulato.

Si consideri un agente per la contabilità fornitori che può accedere a un sistema di pianificazione delle risorse aziendali. La lettura di una fattura e l'autorizzazione di un pagamento avvengono entrambe nella stessa applicazione. Le loro conseguenze differiscono sostanzialmente.

Un gateway di rete può riconoscere il traffico diretto verso quell'applicazione. Potrebbe non comprendere se la funzione sottostante legga un record del fornitore o modifichi le coordinate bancarie.

Un controllo nel codice può ispezionare la funzione e i suoi argomenti. Può applicare una policy alla lettura di una fattura e un'altra all'erogazione di fondi.

Questa distinzione spiega il posizionamento di Arcjet rispetto ai piani di controllo esterni. Un gateway può centralizzare instradamento dei modelli, autenticazione, registrazione e controlli dei contenuti. Arcjet sostiene che parte del contesto applicativo vada persa quando l'enforcement viene spostato fuori dal codice che esegue l'azione.

I due approcci non si escludono a vicenda. Un'azienda può utilizzare un gateway per il traffico dei modelli e Arcjet per chiamate specifiche agli strumenti. La domanda importante è quale controllo possieda la decisione finale.

Arcjet afferma che le decisioni locali aggiungono meno di un millisecondo di overhead. Riporta tra 20 e 30 millisecondi quando una decisione richiede il suo servizio cloud.

Questi dati sono affermazioni dell'azienda, non risultati di benchmark indipendenti. Escludono inoltre controlli più onerosi. Arcjet afferma che il suo rilevamento specialistico della prompt injection può aggiungere circa 100 millisecondi prima di una chiamata al provider.

La latenza diventa importante quando una singola esecuzione di un agente contiene decine di azioni. Un piccolo ritardo può accumularsi, soprattutto quando valutazioni remote delle policy o rilevamenti basati su modelli compaiono ripetutamente.

L'architettura crea quindi un problema di collocazione delle policy. I team devono decidere quali azioni richiedano regole locali, controlli remoti, analisi dei contenuti o revisione umana.

Una ricerca in sola lettura può richiedere soltanto autorizzazione e logging. Un rimborso di valore elevato può giustificare diversi controlli e un'approvazione manuale. Applicare il processo più rigoroso a ogni azione rallenterebbe i flussi di lavoro e aumenterebbe l'attrito operativo.

La risposta di Arcjet è un enforcement granulare. I team di ingegneria possono mantenere le regole vicino all'handler protetto, mentre i team di sicurezza possono gestire policy remote senza richiedere un'altra distribuzione dell'applicazione.

Le regole basate sul codice supportano test, revisione e controllo di versione. Le regole remote consentono al personale di sicurezza di adeguare le soglie tra i servizi. La loro combinazione può preservare la titolarità dell'ingegneria offrendo al contempo ai team di sicurezza un intervento più rapido.

Può anche introdurre questioni di governance. Un'applicazione può contenere una policy mentre il servizio remoto ne applica un'altra. I team necessitano di precedenze chiare, cronologia delle modifiche e comportamento in caso di errore.

Se il servizio cloud delle policy non è disponibile, l'applicazione deve decidere se bloccare o proseguire. Questa decisione dipende dalle conseguenze dell'azione e dalla tolleranza dell'organizzazione alle interruzioni.

Il prodotto rende visibile il confine dell'azione, ma non elimina queste scelte progettuali. Offre ai team un punto in cui codificarle.

L'enforcement nel codice sfida gateway e dashboard di sicurezza

La principale competizione è tra controlli in grado di interrompere un'azione e sistemi che osservano soprattutto il traffico attorno a essa.

Le dashboard di sicurezza possono identificare comportamenti insoliti dopo l'arrivo della telemetria. Questo resta utile per indagini, risposta agli incidenti e conformità. Non interrompe necessariamente un rimborso o un aggiornamento del database già completato.

I gateway AI possono agire prima che una richiesta o una risposta del modello li attraversi. Possono rilevare contenuti ostili, limitare i provider o applicare limiti di spesa in un punto centralizzato.

Tuttavia, l'operazione rilevante di un agente può avvenire dopo l'interazione con il modello. Il modello propone una chiamata a uno strumento e il codice applicativo la esegue su un altro sistema. Un gateway che vede solo il traffico del modello può non rilevare l'operazione finale.

Arcjet colloca la propria protezione all'interno di quel percorso di esecuzione. L'applicazione richiede una decisione di policy immediatamente prima di chiamare la funzione pertinente. Questo consente alla policy di ispezionare argomenti tipizzati anziché dedurre l'intento dal linguaggio naturale.

Un rimborso di importo modesto e uno di importo molto maggiore possono apparire simili a livello di rete. L'handler dell'applicazione conosce l'importo esatto, l'account, la valuta e il contesto dell'utente.

Il compromesso riguarda l'ambito di distribuzione. Un gateway centralizzato può coprire molte applicazioni una volta che il traffico vi viene instradato. I controlli nel codice devono essere inseriti nei confini identificati dagli sviluppatori.

Arcjet tenta di ridurre questo onere tramite SDK, hook e integrazioni con framework. Secondo l'azienda, supporta inoltre l'osservazione tramite OpenTelemetry senza richiedere modifiche all'applicazione.

Eppure, scoperta e applicazione restano aspetti distinti. La telemetria può rivelare un agente sconosciuto senza collocare automaticamente un controllo di blocco davanti a ogni azione intrapresa da quell’agente.

Questa distinzione crea una sequenza di adozione. Un team di piattaforma può prima inventariare l’attività degli agenti. Gli sviluppatori scelgono poi le azioni con conseguenze rilevanti e aggiungono protezioni attorno a esse.

La sequenza è pratica, ma la copertura può restare disomogenea. Un servizio potrebbe proteggere i rimborsi mentre un altro lascia prive di protezione le modifiche agli account. I team di sicurezza hanno bisogno di prove che mostrino quali azioni non dispongono di applicazione dei controlli.

I grandi fornitori stanno puntando a territori sovrapposti. Cisco ha ampliato AI Defense nel febbraio 2026 con protezioni runtime per l’uso di strumenti da parte degli agenti e governance delle interazioni. La sua espansione di AI Defense enfatizza la protezione in ambienti di rete, cloud e on-premises.

L’approccio di Cisco beneficia di una consolidata presenza nella sicurezza enterprise. La proposta di Arcjet è incentrata sull’integrazione nativa nelle applicazioni e sull’adozione da parte degli sviluppatori.

Altri prodotti si concentrano su firewall per modelli, red teaming AI, identità, instradamento tramite gateway o osservabilità. Queste categorie si sovrappongono sempre di più, mentre i fornitori seguono l’attività degli agenti dai prompt fino all’esecuzione degli strumenti.

Arcjet deve quindi dimostrare che il contesto a livello di azione produce decisioni migliori, non semplicemente più log. Gli acquirenti vorranno prove che le policy blocchino attacchi significativi senza interrompere il lavoro legittimo.

Gli esempi attuali dell’azienda sono intuitivi. Includono limiti ai rimborsi, chiamate a strumenti non autorizzate, redazione di dati sensibili, cicli incontrollati e sequenze di azioni pericolose.

I casi più difficili riguardano intenti ambigui. Una policy può facilmente negare uno strumento non disponibile per un ruolo. È più difficile stabilire se una chiamata a uno strumento consentita corrisponda all’obiettivo definito in modo poco preciso da un utente.

Le policy deterministiche aiutano quando le organizzazioni possono esprimere una regola chiara. Una policy deterministica restituisce lo stesso risultato per gli stessi input noti, anziché affidarsi al giudizio aperto di un modello.

Le regole possono limitare la spesa, vincolare le risorse, richiedere approvazioni o bloccare specifiche categorie di dati. Diventano meno decisive quando il contesto dipende da un significato aziendale sfumato.

Questo limite non rende superflua l’applicazione runtime. Definisce il confine tra i controlli deterministici e l’inizio della governance basata sul ragionamento.

Il prodotto di Arcjet attualmente enfatizza una base di applicazione affidabile. Un’analisi delle sequenze più ricca può svilupparsi su questa base, ma necessita comunque di un meccanismo in grado di fermare l’azione risultante.

Questa è la parte più forte dell’argomentazione dell’azienda. Un rilevamento migliore offre una protezione limitata quando l’applicazione non può applicare la decisione prima dell’esecuzione.

La parte più debole è la prova operativa. Arcjet non ha pubblicato dati indipendenti su larga scala che mostrino tassi di falsi positivi, adozione da parte dei clienti o riduzione degli incidenti per questa release.

Finché tali risultati non emergeranno, gli acquirenti devono trattare i dati su prestazioni ed efficacia come affermazioni del fornitore. Le distribuzioni pilota dovrebbero eseguire le policy in modalità osservazione prima di abilitare il comportamento di blocco.

Il prompt injection è solo una parte del problema runtime

Un filtro dei prompt non può sostituire autorizzazione, privilegio minimo, budget o controlli di approvazione.

Il prompt injection riceve attenzione perché un attaccante può nascondere istruzioni in email, documenti, siti web o output degli strumenti. Un agente può trattare quel contenuto non attendibile come una guida e modificare il proprio comportamento.

Il filtraggio può identificare alcuni schemi ostili prima che il contenuto raggiunga un modello. Non può stabilire in modo affidabile se ogni azione aziendale risultante sia autorizzata.

Una richiesta ben formulata può comunque superare l’autorità di un utente. Un account compromesso può inviare istruzioni dall’aspetto innocuo. Un agente può anche commettere un errore senza incontrare un attacco.

La sicurezza runtime deve quindi separare la valutazione dei contenuti dall’autorizzazione delle azioni. Un controllo chiede se l’input sembra ostile. Un altro chiede se questo attore può eseguire questa operazione su questa risorsa.

Le linee guida OWASP sull’eccessiva autonomia raccomandano di ridurre al minimo estensioni, autorizzazioni e autonomia. Raccomandano inoltre l’approvazione umana prima delle azioni ad alto impatto.

Arcjet può fornire il punto di applicazione per alcuni di questi controlli. Non può decidere la tolleranza al rischio di un’organizzazione né riprogettare un agente che dispone di credenziali eccessivamente ampie.

Un agente con autorizzazioni non necessarie al database rimane pericoloso. Le policy di blocco riducono l’esposizione, ma il privilegio minimo dovrebbe impedire all’agente di raggiungere fin dall’inizio molte operazioni sensibili.

Anche l’approvazione umana richiede un’implementazione attenta. Una schermata di conferma dovrebbe mostrare lo strumento effettivo, la destinazione, gli argomenti e la conseguenza. Chiedere agli utenti di approvare un riepilogo scritto dall’agente può nascondere il dettaglio pericoloso.

Secondo i materiali di prodotto, Arcjet restituisce una decisione di sospensione per revisione. L’applicazione circostante controlla comunque come tale revisione viene presentata e chi può approvarla.

I record di audit introducono un’altra serie di problemi. Prompt e parametri degli strumenti possono contenere informazioni personali, credenziali, documenti interni o dati dei clienti.

Arcjet afferma che i controlli sensibili possono essere eseguiti localmente mentre le prove della decisione vengono archiviate separatamente. Offre l’archiviazione tramite il proprio cloud, un ambiente single-tenant, un cloud virtuale privato o un’infrastruttura gestita dal cliente.

Le organizzazioni dovrebbero verificare quali campi lasciano il proprio ambiente. Dovrebbero inoltre definire conservazione, archiviazione regionale, controlli di accesso, procedure di eliminazione e responsabilità di risposta agli incidenti.

Il prodotto pubblicizza un report SOC 2 Type II che copre sicurezza, disponibilità e riservatezza. Tale garanzia riguarda i controlli organizzativi, ma non convalida ogni policy o integrazione degli agenti.

Il rilevamento basato sulle sequenze introduce ulteriore incertezza. Collegare le azioni tra sessioni può rivelare rischi graduali che i controlli isolati non rilevano. Può anche produrre cronologie incomplete o errate quando gli identificatori sono incoerenti.

Le convenzioni OpenTelemetry possono aiutare a normalizzare i record. Non garantiscono che ogni framework emetta un contesto equivalente o conservi le stesse informazioni sull’identità.

Gli sviluppatori devono propagare gli identificatori di correlazione attraverso code, job in background e confini di servizio. Il contesto mancante può far apparire un singolo flusso di lavoro come diverse esecuzioni non correlate.

Una raccolta eccessiva crea il problema opposto. Registrare ogni prompt, argomento degli strumenti e output può ampliare la quantità di dati sensibili disponibile per la piattaforma di monitoraggio.

I team di sicurezza devono bilanciare il dettaglio investigativo con la minimizzazione dei dati. Una traccia di audit utile dovrebbe dimostrare la decisione senza copiare automaticamente ogni payload sensibile.

I falsi positivi rappresentano un’altra sfida. Un rilevatore di prompt injection può segnalare discussioni di sicurezza legittime, istruzioni sul malware citate o contenuti dei clienti.

Arcjet raccomanda una distribuzione dry-run, che registra le decisioni senza applicarle. Ciò consente ai team di confrontare i blocchi proposti con il comportamento reale dell’applicazione prima di attivare una regola.

I dry run sono preziosi, ma richiedono una revisione strutturata. I team dovrebbero etichettare i falsi positivi, misurare i casi mancati e testare i percorsi di errore anziché osservare passivamente una dashboard.

Anche una policy può diventare obsoleta. Nuovi strumenti, argomenti, classi di dati e processi aziendali modificano il significato di un’azione. I record delle policy con versionamento aiutano gli investigatori a capire quale regola fosse applicata in un dato momento.

Non garantiscono che la regola sia rimasta appropriata. I responsabili della sicurezza e dell’applicazione devono riesaminare le policy con l’evoluzione del flusso di lavoro.

Questi limiti rafforzano il principale compromesso. Spostare l’applicazione dei controlli nel codice fornisce un contesto utile, ma distribuisce anche la responsabilità tra servizi e team.

Arcjet deve rendere questo modello distribuito più facile da governare rispetto a un mosaico di controlli di autorizzazione personalizzati. Altrimenti, gli acquirenti potrebbero ottenere un ulteriore livello di policy senza raggiungere un controllo coerente.

Il prossimo test è l’evidenza di produzione, non l’ampiezza delle funzionalità

Il lancio di Arcjet sarà rilevante se i clienti potranno dimostrare copertura, bassa interruzione e interventi riusciti nei flussi di lavoro degli agenti reali.

Il primo segnale da osservare è l’adozione oltre gli ambienti dimostrativi. Arcjet dovrebbe mostrare come i team inventariano gli agenti, identificano le azioni rilevanti e trasferiscono policy selezionate dal dry run all’applicazione.

Distribuzioni di produzione nominate chiarirebbero quali flussi di lavoro gli acquirenti ritengono prioritari. Operazioni di supporto, sviluppo software, finanza e accesso ai dati interni presentano rischi e requisiti di latenza diversi.

Le prove più solide includerebbero tempi di distribuzione, copertura delle azioni protette, tassi di falsi positivi e numero di azioni fermate prima dell’esecuzione. Queste misure metterebbero alla prova l’affermazione centrale di Arcjet.

Il secondo segnale è l’interoperabilità. Arcjet elenca attualmente integrazioni con importanti framework per agenti e assistenti di programmazione. Il mercato giudicherà se tali integrazioni preservino un contesto utile in ambienti misti.

Le organizzazioni raramente standardizzano ogni agente su un solo framework. Un flusso di lavoro può iniziare in un’interfaccia chat, proseguire tramite una coda e concludersi all’interno di un servizio personalizzato.

Arcjet deve collegare questi passaggi senza costringere ogni team a un unico sistema di orchestrazione. Il supporto OpenTelemetry offre un plausibile livello di scoperta, mentre le protezioni SDK forniscono l’applicazione.

Il divario tra questi livelli richiederà attenzione. Gli acquirenti hanno bisogno di una visione chiara degli agenti scoperti le cui azioni rilevanti restano prive di protezione.

Il reporting sulla copertura potrebbe diventare una delle funzionalità più preziose del prodotto. Consentirebbe ai team di sicurezza di distinguere la visibilità dal controllo preventivo effettivo.

Il terzo segnale è la risposta competitiva. Cisco e altri fornitori enterprise stanno già aggiungendo governance delle interazioni degli agenti e protezione runtime.

Se queste aziende si spingeranno più in profondità nei gestori delle applicazioni, la distinzione architetturale di Arcjet si ridurrà. Se resteranno concentrate sull’ispezione centralizzata, Arcjet potrà sostenere che il suo contesto a livello di codice colma una lacuna persistente.

Anche i fornitori di framework per agenti potrebbero aggiungere hook nativi per le policy. Questo sviluppo potrebbe aiutare Arcjet creando punti di applicazione comuni oppure ridurre la domanda di una piattaforma separata.

È probabile che il mercato supporti controlli stratificati. Identità, ispezione tramite gateway, autorizzazione delle azioni, telemetria e revisione umana affrontano modalità di guasto differenti.

La sfida per l’acquirente è evitare che la sovrapposizione diventi complessità. Ogni servizio decisionale aggiuntivo crea requisiti di configurazione, latenza, logging e disponibilità.

L’opportunità immediata di Arcjet è diventare l’ultimo checkpoint delle policy prima che venga eseguita una funzione rilevante. Il suo rischio è diventare un’altra dashboard che i team distribuiscono ampiamente ma applicano in modo limitato.

Gli sviluppatori che valutano la sicurezza runtime degli agenti Arcjet dovrebbero iniziare con un flusso di lavoro delimitato. Dovrebbero mappare input, identità, strumenti, accesso ai dati, passaggi di approvazione e azioni irreversibili.

Successivamente, possono proteggere la chiamata più rilevante e utilizzare la regola in modalità dry-run. I revisori dovrebbero esaminare sia i casi legittimi sia quelli avversariali prima di abilitare un blocco.

I team di sicurezza dovrebbero inoltre testare il comportamento in caso di indisponibilità del servizio. Un servizio di rimborsi, un writer del database di produzione e uno strumento di ricerca documentale non dovrebbero condividere una sola policy di errore predefinita.

Infine, i team dovrebbero verificare le prove di audit risultanti. Un investigatore deve poter ricostruire la decisione senza esporre dati sensibili non necessari.

Il lancio identifica un cambiamento reale nella sicurezza dell’AI. Gli agenti creano rischi attraverso le azioni, non solo attraverso gli output dei modelli. I controlli devono quindi seguire il flusso di lavoro fino al punto in cui il software modifica un altro sistema.

Arcjet ha offerto un’implementazione concreta di questa idea. I prossimi mesi dovrebbero mostrare se il suo approccio nel codice fornisce un controllo coerente nelle organizzazioni reali.

Per chi sviluppa, la domanda pratica è ora precisa: quale azione di un agente causerebbe i danni maggiori se venisse eseguita in modo errato oggi? Partite da lì, verificate l’identità e il contesto circostanti, quindi applicate una decisione vincolante prima della chiamata.