La sicurezza email AgentCore di Abnormal AI scala gli agenti limitandone il raggio d'azione

Abnormal AI ha implementato Amazon Bedrock AgentCore Code Interpreter all'interno di un sistema di rilevamento che elabora miliardi di messaggi email ogni giorno. Il design della sicurezza email Abnormal AI AgentCore fornisce agli agenti autonomi risorse di calcolo temporanee, ma nega a quell'ambiente un accesso illimitato a internet. Questa restrizione è l'idea centrale, non una scelta di configurazione secondaria.

Gli agenti gestiscono solo decine di migliaia dei casi quotidiani più difficili della pipeline. Classificatori leggeri elaborano prima miliardi di messaggi, mentre modelli di machine learning più grandi esaminano milioni di risultati incerti. Abnormal riserva l'analisi guidata dagli agenti ai casi che le fasi precedenti non riescono a classificare con sicurezza.

Questa architettura mette in discussione l'idea più semplice secondo cui una migliore sicurezza email derivi dall'invio di ogni messaggio al modello più grande disponibile. Si differenzia inoltre dai sistemi incentrati sugli analisti, come Microsoft Security Copilot, che possono spiegare le classificazioni di phishing per la revisione umana. Abnormal colloca gli agenti direttamente in una pipeline di rilevamento inline, dove latenza, isolamento e confini di errore prevedibili contano immediatamente.

L'implementazione è significativa perché i suoi agenti possono scrivere ed eseguire script mentre analizzano dati sulle minacce comportamentali. Questa capacità offre maggiore flessibilità rispetto a un classificatore fisso, ma crea anche una nuova superficie d'attacco. Un'email è al tempo stesso una prova e un input potenzialmente ostile, quindi qualsiasi agente che la esamini deve essere considerato capace di prendere una decisione non sicura.

La risposta di Abnormal è un sistema a più livelli costruito attorno all'escalation selettiva e all'esecuzione vincolata. Il modello riceve spazio per calcolare, aggregare e verificare all'interno di una sandbox temporanea. L'architettura circostante decide cosa entra, cosa può uscire e quali azioni restano indisponibili.

La sicurezza email AgentCore di Abnormal AI punta ai casi più difficili

Il cambiamento principale non è che Abnormal abbia aggiunto un agente AI. Ha inserito agenti in grado di scrivere codice in una pipeline di rilevamento live senza affidare loro l'intero carico di lavoro.

Secondo il case study sull'implementazione, Abnormal utilizza tre livelli di elaborazione. Il primo livello applica piccoli modelli, regole euristiche e classificatori di regressione logistica a miliardi di messaggi quotidiani. Questi metodi gestiscono i casi che non richiedono analisi costose.

I messaggi che restano incerti passano al secondo livello. Il deep learning e altri modelli di machine learning ispezionano milioni di messaggi ogni giorno usando segnali comportamentali più ampi. Solo i casi irrisolti più difficili raggiungono il terzo livello.

Quest'ultimo livello elabora decine di migliaia di messaggi al giorno con agenti inline e Code Interpreter. Gli agenti ricevono dati di threat intelligence, scrivono script dinamicamente e analizzano come ciascun caso si inserisca nel modello comportamentale di Abnormal. Contribuiscono quindi a una decisione di rilevamento prima che l'email raggiunga la casella di posta.

Questo imbuto conta sia per l'economia sia per l'affidabilità. Eseguire un agente generico su ogni messaggio consumerebbe la maggior parte delle risorse di calcolo dove spesso apporta il minor valore aggiuntivo. Esporrebbe inoltre una parte più ampia della pipeline di produzione a comportamenti non deterministici.

L'escalation selettiva trasforma l'agente in un gestore delle eccezioni. Le fasi precedenti assorbono il volume prevedibile, mentre gli agenti indagano sui casi che assomigliano al lavoro tradizionalmente assegnato a un analista umano. Il design utilizza la complessità del modello in base all'incertezza, non al posizionamento del prodotto.

L'architettura limita inoltre le conseguenze operative di un errore dell'agente. Un errore nel terzo livello resta importante, ma l'agente non controlla la classificazione di ogni messaggio ordinario. Un sistema separato gestisce le classificazioni errate e le usa per migliorare il sistema di rilevamento più ampio.

Abnormal afferma che i sistemi di monitoraggio verificano anche la pipeline live. Il case study AWS non pubblica misurazioni indipendenti di accuratezza, falsi positivi o latenza. Documenta pertanto un'architettura operativa, non una prova comparativa che gli agenti superino ogni metodo di rilevamento convenzionale.

L'azienda esegue inoltre un agente analista al di fuori del percorso inline. Questo sistema batch acquisisce classificazioni errate e segnali di ottimizzazione, quindi cerca modelli in insiemi di messaggi più ampi. Redige euristiche candidate per il primo livello e contribuisce a miglioramenti per il secondo.

AWS afferma che questo agente analista esegue circa 100 job batch ogni settimana. I singoli job possono rimanere attivi per oltre 30 minuti. Alcuni workflow si estendono per un'intera giornata perché l'addestramento del modello avviene al di fuori della sessione Code Interpreter.

Questo ciclo di feedback assegna all'agente un secondo ruolo. Non si limita a giudicare i messaggi difficili. Estrae anche regole dagli esiti complessi che classificatori meno costosi possono applicare in seguito.

Il risultato è una pratica divisione del lavoro. Le regole fisse garantiscono throughput, i modelli addestrati offrono un riconoscimento più ampio dei pattern e gli agenti forniscono indagini flessibili. Il ragionamento più costoso è riservato ai casi in cui tale flessibilità ha uno scopo chiaro.

Lo spazio di lavoro temporaneo è calcolo, non più contesto per il modello

Code Interpreter è importante perché consente all'agente di calcolare e testare affermazioni, invece di trattare la generazione del linguaggio come calcolo.

Un modello linguistico di grandi dimensioni può descrivere un calcolo producendo comunque un risultato sbagliato. Può inoltre proporre uno script utile senza sapere se quello script venga eseguito correttamente. Gli agenti di Abnormal necessitano di uno spazio di lavoro in cui il codice generato possa essere eseguito sui dati consentiti.

Amazon Bedrock AgentCore Code Interpreter fornisce questo spazio di lavoro tramite un'API. Il servizio offre agli agenti un ambiente isolato per eseguire comandi, caricare file e restituire risultati. Non impone uno specifico ciclo di ragionamento o framework per agenti.

AWS descrive questa capacità come un runtime di esecuzione completamente gestito e serverless. Le sessioni vengono eseguite in MicroVM effimere, ovvero macchine virtuali leggere con risorse di calcolo, memoria e filesystem isolati. Una sessione dura 15 minuti per impostazione predefinita e può essere configurata fino a otto ore.

L'ambiente include runtime Python e Node.js con comuni librerie per elaborazione dati, statistica e visualizzazione. I file fino a 100 MB possono passare direttamente tramite l'API. Dataset più grandi possono utilizzare Amazon S3 o configurazioni di filesystem gestite dal cliente.

La distinzione tra contesto e calcolo è importante. Aggiungere threat intelligence al prompt di un modello fornisce più materiale da interpretare. Fornirgli Code Interpreter consente all'agente di trasformare, contare, confrontare e testare quel materiale in modo programmatico.

Il dirigente di Abnormal AI Shrivu Shankar descrive questo ambiente come uno spazio di calcolo temporaneo necessario a quasi ogni agente. Questa impostazione porta l'esecuzione del codice oltre gli assistenti per lo sviluppo software. Un agente di sicurezza può utilizzare script per aggregazione, confronti comportamentali, validazione dei dati o punteggi ripetibili.

L'agente può anche eseguire verificatori programmatici. Test, linter e controlli di integrazione forniscono feedback leggibile dalle macchine prima che un output raggiunga un altro componente di produzione. Non garantiscono la correttezza, ma offrono all'agente evidenze che vanno oltre la propria spiegazione generata.

Questo approccio richiama un modello più ampio nella progettazione degli agenti. Gli sviluppatori separano sempre più il modello che propone il lavoro dal runtime che lo esegue. Il modello resta probabilistico, mentre l'ambiente di esecuzione fornisce risultati deterministici per operazioni specifiche.

AWS ha introdotto per la prima volta Code Interpreter come infrastruttura per eseguire in sicurezza codice generato dagli agenti. Il suo valore nella pipeline di Abnormal deriva da questa separazione. Abnormal può mantenere il proprio harness di agenti esistente, trattando il calcolo isolato come un servizio esterno.

Un harness leggero offre inoltre flessibilità all'agente. Abnormal afferma che workflow rigidi e sequenziali possono avere prestazioni peggiori rispetto a principi di alto livello abbinati a strumenti generici. L'agente sceglie un metodo, ma deve operare entro i confini fissati dal sistema circostante.

Questo equilibrio è difficile. Troppa poca libertà riduce l'agente a un costoso workflow fisso. Troppa libertà consente a input non affidabili di influenzare codice, richieste di rete, file e credenziali.

Il modello dello spazio di lavoro temporaneo trova una posizione intermedia. Fornisce all'agente libertà locale per creare script e artefatti temporanei. Non concede automaticamente autorità sull'ambiente di produzione che circonda quello spazio di lavoro.

Per chi sviluppa sistemi, questo design suggerisce una domanda chiara prima di aggiungere un altro modello o una finestra di contesto più ampia. L'agente ha bisogno di più conoscenza oppure di un luogo controllato in cui calcolare? Questi problemi richiedono infrastrutture diverse.

I team che costruiscono agenti interni necessitano anche di registri durevoli al di fuori del prompt del modello. Una base di conoscenza ricercabile può conservare specifiche e risultati operativi. La sandbox di esecuzione dovrebbe rimanere temporanea, mentre la conoscenza approvata persiste attraverso sistemi governati.

Le sandbox senza uscita di rete trasformano il rischio degli agenti in un problema circoscritto

La scelta di design più solida di Abnormal è negare alla sandbox di analisi un accesso di rete illimitato, anche quando l'agente si comporta in modo imprevisto.

Un agente di sicurezza email elabora contenuti creati da soggetti esterni. Gli attaccanti possono inserire istruzioni, link, materiale codificato o testo avversario in tali contenuti. Un modello potrebbe interpretare questi elementi come prove, ma potrebbe anche considerarli istruzioni.

Questo problema è noto come prompt injection, in cui contenuti non affidabili cercano di reindirizzare un agente dal compito previsto. Le difese a livello di modello possono riconoscere alcuni attacchi. Non possono fornire una garanzia deterministica contro ogni manipolazione.

Abnormal ha quindi selezionato la configurazione di rete della sandbox per Code Interpreter. Nella sua implementazione, l'ambiente di esecuzione non dispone di egress pubblico verso internet. La threat intelligence può entrare per l'analisi, ma il codice generato non può trasmettere liberamente tali informazioni a un endpoint esterno.

La restrizione serve a due obiettivi. In primo luogo, migliora la riproducibilità perché siti web o servizi esterni non possono modificare il comportamento di una sessione durante l'esecuzione. In secondo luogo, limita l'esfiltrazione di dati se un modello segue istruzioni malevole o genera codice non sicuro.

Questa è la tensione principale dell'articolo: flessibilità dell'agente contro esecuzione circoscritta. Il sistema offre al modello libertà di scegliere calcoli e scrivere script. L'infrastruttura limita i luoghi che tali script possono raggiungere.

AWS supporta diverse modalità di rete per Code Interpreter. La modalità sandbox offre un accesso esterno limitato, incluse le operazioni Amazon S3 supportate. La modalità pubblica consente risorse internet, mentre la modalità VPC collega l'ambiente a risorse private approvate.

Queste opzioni non dovrebbero essere considerate impostazioni di comodità intercambiabili. L'accesso pubblico amplia ciò che un agente può fare, ma amplia anche i possibili rischi di esfiltrazione e dipendenza. L'accesso VPC può raggiungere sistemi interni di valore, quindi i ruoli di esecuzione e le policy di rete diventano critici.

Abnormal aggiunge il sandbox gestito al proprio harness già isolato dalla rete. Questo approccio di difesa in profondità evita di considerare sufficiente un singolo confine di isolamento. L’azienda controlla inoltre quali dati entrano in Code Interpreter e quali azioni di scrittura l’agente può compiere.

Questa architettura è in linea con le linee guida di sicurezza che stanno emergendo altrove nello sviluppo degli agenti. Anthropic sostiene che il contenimento degli agenti richieda confini sia per il filesystem sia per la rete. Senza restrizioni all’egress, un processo compromesso può inviare altrove segreti raggiungibili.

La successiva analisi sul contenimento di Anthropic esplicita il punto di fondo in modo più diretto. La supervisione probabilistica non può sostituire un limite rigido alle risorse accessibili. Il contenimento limita le conseguenze anche quando il modello prende la decisione sbagliata.

La documentazione AWS aggiunge un’altra importante precisazione. Ogni sessione AgentCore riceve risorse isolate di CPU, memoria e filesystem, e la relativa MicroVM viene terminata successivamente. Tuttavia, i clienti restano responsabili di autorizzazioni, associazioni delle sessioni, convalida degli input, credenziali e strumenti connessi.

Le linee guida di sicurezza avvertono inoltre che il codice eseguito all’interno di una MicroVM può accedere alle credenziali assegnate a quell’ambiente. L’isolamento dalle altre sessioni non rende sicure autorizzazioni eccessive nella sessione corrente.

Un sandbox sicuro richiede quindi più del semplice calcolo effimero. Chi lo sviluppa deve definire l’ambito dei ruoli di esecuzione, limitare i percorsi di rete, filtrare gli input degli strumenti ed escludere credenziali non necessarie. Deve anche decidere quali artefatti possano uscire al termine dell’esecuzione.

Il modello senza egress funziona particolarmente bene per attività con input autosufficienti. Un agente può ricevere un pacchetto di prove delimitato, elaborare localmente e restituire un risultato circoscritto. I flussi di lavoro che richiedono siti web arbitrari o API esterne pongono un problema di policy più complesso.

Una risposta è un livello di strumenti intermediato. Invece di concedere connettività di rete generale, l’agente richiama strumenti nominati tramite un proxy controllato. Ogni strumento può applicare autenticazione, convalida degli input, allowlist, logging e schemi di output limitati.

Questo design preserva azioni esterne utili senza trasformare il sandbox in una normale macchina connessa a Internet. Offre inoltre ai team di sicurezza una registrazione di ciò che l’agente ha richiesto e di ciò che lo strumento ha restituito.

L’implementazione di Abnormal non elimina il prompt injection. Riduce ciò che un’iniezione riuscita può ottenere all’interno di un singolo ambiente. È un’affermazione di produzione più difendibile rispetto al dire che il modello riconoscerà sempre i contenuti dannosi.

La pipeline a tre livelli mette sotto pressione sia i fornitori di sicurezza sia gli sviluppatori di agenti

L’architettura di Abnormal alza l’asticella: non basta produrre risposte persuasive degli agenti, occorre produrre decisioni delimitate in condizioni operative reali.

I fornitori di sicurezza email usano già regole, sistemi di reputazione, machine learning e analisi comportamentale. La nuova pressione deriva dall’inserimento di agenti flessibili più in profondità nei flussi di rilevamento. I concorrenti devono decidere se gli agenti debbano affiancare gli analisti o entrare direttamente nel percorso di classificazione.

L’approccio di Microsoft offre un confronto utile senza decretare un vincitore semplice. Il suo Security Copilot Phishing Triage Agent valuta il contenuto delle email, la reputazione del mittente e i segnali comportamentali. Produce una classificazione e una motivazione in linguaggio naturale che gli analisti possono esaminare o ignorare.

Quel modello di triage per il phishing pone l’accento su identità degli agenti governate, trigger definiti, permessi di accesso e diritti di azione. Colloca trasparenza e revisione umana vicino al centro del flusso di lavoro.

L’implementazione descritta da Abnormal utilizza invece agenti inline per un sottoinsieme di messaggi attentamente filtrato. L’output contribuisce a una decisione prima della consegna, sebbene sia circondato da monitoraggio e sistemi di apprendimento separati. La differenza riguarda più il posizionamento nel flusso di lavoro che la capacità di base del modello.

Nessuno dei due approcci rende obsoleti gli analisti umani. I casi più difficili di Abnormal sono quelli che tradizionalmente richiederebbero l’attenzione di un analista. I suoi agenti assorbono parte di quel lavoro investigativo, mentre gli esseri umani continuano a progettare controlli, interpretare i fallimenti e governare le modifiche ai modelli.

L’architettura esercita pressione anche sui fornitori di piattaforme per agenti generalisti. Un runtime di produzione deve supportare più della sola esecuzione di codice. Servono isolamento delle sessioni, controlli del ciclo di vita, osservabilità, gestione prevedibile dei file e policy di rete comprensibili per gli amministratori.

Il servizio gestito riduce il lavoro necessario per operare risorse di calcolo usa e getta. Tuttavia, non elimina le decisioni di progettazione a livello applicativo. Chi sviluppa sceglie ancora quali input raggiungono il sandbox, come le sessioni vengono associate alle attività e quali risultati possono modificare i sistemi di produzione.

L’imbuto a tre livelli offre un’altra lezione. La scalabilità degli agenti è in parte un problema di instradamento. I team dovrebbero misurare l’incertezza ed effettuare escalation selettive, invece di presumere che ogni richiesta meriti lo stesso modello, contesto, strumenti e budget di calcolo.

Questo principio si applica oltre la sicurezza. I sistemi di assistenza clienti possono instradare le richieste di routine verso flussi deterministici e riservare gli agenti ai casi ambigui. I sistemi dati possono usare prima trasformazioni fisse, poi chiamare gli agenti quando schemi o prove sono in conflitto.

L’analista batch offre un secondo modello riutilizzabile. I fallimenti in produzione possono alimentare un agente offline che cerca cause ricorrenti e propone regole meno costose. Umani o verificatori automatizzati possono valutare tali proposte prima della promozione.

Tuttavia, questo ciclo di feedback introduce questioni di governance. Un’euristica candidata derivata da classificazioni errate passate può codificare un pattern temporaneo o amplificare un campione distorto. Chi sviluppa ha bisogno di set di valutazione, controlli di rollout e percorsi di rollback prima di aggiornare le fasi precedenti della pipeline.

Il case study AWS non fornisce questi dettagli operativi. Afferma che un sistema separato apprende dagli errori e che il monitoraggio verifica il sistema in produzione. Non divulga soglie di approvazione, metodologia di valutazione o la quota di proposte degli agenti che raggiungono la produzione.

Non rivela neppure la latenza end-to-end. Il rilevamento inline delle email opera entro vincoli di consegna e un terzo livello lento può incidere sull’esperienza utente. L’instradamento selettivo riduce questa esposizione, ma chi sviluppa ha comunque bisogno di latenza per percentile e comportamento in caso di timeout.

Anche i costi restano altrettanto poco chiari. L’imbuto quasi certamente evita di eseguire calcolo degli agenti su miliardi di messaggi di routine. Il materiale pubblicato non fornisce costi per messaggio, utilizzo delle sessioni o confronti infrastrutturali con un sandbox autogestito.

Queste omissioni non invalidano l’architettura. Definiscono il confine tra un utile case study di un cliente e prove di prestazioni verificate in modo indipendente. Gli acquirenti aziendali dovrebbero valutare il modello richiedendo al contempo misurazioni specifiche per il proprio carico di lavoro.

Per i responsabili della sicurezza, la domanda più utile non è se un fornitore disponga di rilevamento “agentic”. È dove l’agente entra nel percorso decisionale, quali prove riceve e cosa accade quando fallisce.

Per i team di piattaforma, la domanda è altrettanto concreta. L’agente può completare un lavoro di valore in un ambiente con ambito ristretto, oppure il flusso di lavoro proposto dipende da credenziali ampie e connettività di rete aperta?

Se un lavoro utile richiede accesso illimitato, il design non ha risolto il compromesso centrale. Ha trasferito quel rischio nel runtime.

Cosa non dimostra il case study di Abnormal AI

L’implementazione mostra un modello di contenimento credibile, ma non dimostra miglioramenti indipendenti in accuratezza, velocità o costo operativo totale.

La fonte centrale è un articolo AWS scritto con la partecipazione di Abnormal. AWS fornisce l’infrastruttura e Abnormal è il cliente in evidenza. I lettori dovrebbero trattare i dati di scala e le descrizioni dei flussi di lavoro come affermazioni attribuite all’azienda.

I volumi riportati restano comunque informativi. Miliardi di messaggi entrano nel primo livello, milioni raggiungono il secondo e decine di migliaia arrivano ogni giorno agli agenti. Tuttavia, questi conteggi non rivelano quanto spesso gli agenti migliorino il verdetto finale.

Diverse misurazioni mancanti cambierebbero la valutazione. I tassi di falsi positivi mostrerebbero se messaggi legittimi difficili affrontano un rischio aggiuntivo. I tassi di falsi negativi indicherebbero se l’agente intercetta attacchi non rilevati dai modelli precedenti.

Sarebbero utili anche dati sulla revisione degli analisti. Se gli esseri umani ribaltano frequentemente le decisioni degli agenti, il terzo livello potrebbe funzionare come strumento di prioritizzazione anziché come rilevamento autonomo. Se i ribaltamenti sono rari, gli acquirenti avrebbero comunque bisogno di prove che il monitoraggio individui errori silenziosi.

Le distribuzioni della latenza sono importanti perché le medie possono nascondere fallimenti operativi. Un piccolo gruppo di sessioni a lunga esecuzione potrebbe ritardare la posta anche quando le classificazioni tipiche si concludono rapidamente. Timeout e fallback dovrebbero essere testati con la stessa attenzione della qualità del modello.

La stessa cautela vale per le affermazioni di determinismo. Rimuovere l’accesso a Internet pubblico riduce la variabilità esterna, ma gli output del modello possono restare stocastici. Anche librerie software, ordine degli input, versioni del runtime e logica di orchestrazione possono influenzare i risultati.

“No egress” va letto con altrettanta precisione. Limita la comunicazione di rete pubblica dal sandbox. Non convalida automaticamente i dati in ingresso, non impedisce calcoli locali dannosi e non garantisce che gli artefatti restituiti non contengano informazioni sensibili.

Restano quindi necessari controlli sugli output. Un report generato può contenere dati riservati. Uno script può creare un artefatto sovradimensionato, consumare risorse della sessione o produrre un risultato fuorviante senza contattare Internet.

Lo storage persistente introduce ulteriori considerazioni. Abnormal usa file come checkpoint quando il lavoro supera la durata di una sessione. Chi adotta questo modello deve definire conservazione, confini di accesso, crittografia, scritture concorrenti e proprietà degli artefatti.

Il filesystem è un punto di ripristino, non una policy di sicurezza. I dati che escono da una sessione effimera diventano durevoli altrove. Le relative protezioni dipendono quindi dal servizio di storage e dall’applicazione che lo utilizza.

Il lavoro a lunga esecuzione complica anche l’identità. Un processo di una giornata può attraversare più sessioni e job di addestramento esterni. Ogni passaggio richiede un’identità dell’attività autenticata, input espliciti e output verificabili.

L’osservabilità aiuta a ricostruire queste transizioni. AgentCore può inviare log ad Amazon CloudWatch e registrare l’attività tramite AWS CloudTrail. I team devono comunque decidere cosa registrare senza copiare contenuti sensibili dei messaggi in un altro sistema.

Il monitoraggio di un agente richiede sia segnali operativi sia di sicurezza. Errori di esecuzione, timeout e consumo di risorse rivelano problemi di affidabilità. Comandi inattesi, tentativi di rete bloccati e dimensioni di output insolite possono esporre comportamenti ostili o confusi.

Chi sviluppa dovrebbe inoltre testare deliberatamente i percorsi di errore. Cosa accade quando il sandbox non può avviarsi, uno script supera i limiti o il modello produce codice non valido? Il sistema necessita di un fallback sicuro che non classifichi silenziosamente l’incertezza come sicurezza.

Per Abnormal, i livelli di rilevamento precedenti forniscono parte di questa struttura circostante. Il caso pubblicato non specifica il fallback finale per ogni fallimento del terzo livello. È una lacuna che merita di essere esaminata durante la valutazione tecnica.

Il case study supporta quindi una conclusione più circoscritta di quanto la sua sola scala possa suggerire. Il calcolo effimero gestito può inserirsi in una pipeline di sicurezza ad alto volume quando l’instradamento limita nettamente il carico degli agenti. Un forte contenimento può inoltre ridurre le conseguenze del fallimento del modello.

Non dimostra che ogni decisione di sicurezza tragga beneficio da un agente. Mostra dove Abnormal ritiene che il calcolo flessibile meriti il proprio posto: nella piccola e difficile coda di casi che sistemi più semplici non possono risolvere con sicurezza.

Tre segnali mostreranno se questo modello regge su scala

Il prossimo test sarà verificare se Abnormal e AWS pubblicheranno evidenze operative che colleghino l’architettura di isolamento a risultati di rilevamento misurabili.

Il primo segnale riguarda i dati sulla qualità dei workload. Occorre osservare i tassi di falsi positivi, i tassi di falsi negativi, gli interventi correttivi degli analisti e i miglioramenti misurabili rispetto al precedente processo di terzo livello. Questi risultati rafforzerebbero la tesi secondo cui gli agenti apportano valore al rilevamento, anziché sola complessità architetturale.

L’assenza di tali misurazioni non dimostrerebbe un fallimento. Manterrebbe le affermazioni più ambiziose nella categoria delle esperienze di implementazione riportate dal fornitore. Gli acquirenti dovrebbero condurre valutazioni controllate con il proprio traffico e i propri profili di minaccia.

Il secondo segnale riguarda controlli delle policy più approfonditi nei servizi gestiti di esecuzione del codice. Sviluppi utili includono allowlist di egress più ristrette, autorizzazioni per singolo strumento, scansione degli artefatti, mediazione delle credenziali e una provenienza dettagliata delle sessioni. Questi controlli rafforzerebbero il compromesso, concedendo capacità senza ampliare l’intera sandbox.

Un’evoluzione verso il networking senza restrizioni indebolirebbe questo schema. Potrebbe semplificare le integrazioni, ma aumenterebbe anche la pressione sulle difese probabilistiche dei modelli. L’architettura più sicura mantiene l’autorità al di fuori del modello, ove possibile.

Il terzo segnale è l’adozione del routing selettivo degli agenti da parte di altri fornitori di sicurezza. Microsoft collega già gli agenti al triage del phishing e ai workflow degli analisti. Il prossimo passo importante sarà dimostrare che i fornitori possono collocare gli agenti inline mantenendo fallback trasparenti e percorsi di revisione.

Un’adozione più ampia suggerirebbe che il funnel a tre livelli di Abnormal sta diventando un modello di settore. Un ritorno ai copilot riservati agli analisti indicherebbe che latenza, affidabilità o governance continuano a ostacolare l’autonomia inline.

I builder non devono attendere quel verdetto del mercato. Possono testare l’architettura fin da ora con workload delimitati e criteri di valutazione espliciti. Conviene iniziare dai casi in cui il pacchetto di input è autosufficiente e un verificatore deterministico può giudicare il risultato.

Mantenete le credenziali durevoli al di fuori dell’ambiente di esecuzione. Concedete soltanto i dati e gli strumenti necessari per un singolo compito. Considerate ogni documento, messaggio, sito web e risposta di uno strumento come un input potenzialmente ostile.

Fate in modo che la chiusura della sessione sia parte del progetto, non un dettaglio di pulizia. Persistete solo gli artefatti approvati e collegateli a un’identità del task verificabile. Definite un comportamento sicuro per ogni timeout, risultato malformato e dipendenza non disponibile.

Soprattutto, misurate il funnel. Registrate quanti casi risolve ciascun livello, perché avviene l’escalation e se il livello successivo migliora il risultato. Il calcolo degli agenti dovrebbe guadagnarsi il proprio posto attraverso un valore misurabile.

La vicenda della sicurezza email basata su Abnormal AI AgentCore riguarda, in ultima analisi, una limitazione disciplinata. Gli agenti ricevono libertà sufficiente per indagare casi che i sistemi fissi non riescono a risolvere. Non ricevono una portata illimitata solo perché il loro ragionamento sembra utile.

Questa è la domanda pratica per ogni team che sviluppa agenti in produzione: quale lavoro di valore può completare il vostro agente all’interno di un ambiente usa e getta, osservabile e strettamente delimitato? Costruite prima quel confine, poi decidete quanta autonomia debba esserci al suo interno.