Exaforce AI Security debutta con un kill switch per gli agenti fuori controllo
Il 15 settembre Exaforce ha lanciato Exaforce AI Security con una promessa diretta: individuare gli agenti fuori controllo e fermarli prima che le loro azioni si trasformino in una violazione. Il rilascio aggiunge rilevamento agentless, analisi del rischio, rilevamento in fase di esecuzione e un kill switch per gli agenti all'attuale piattaforma di security operations di Exaforce.
Il cambiamento più significativo non è un'altra dashboard per monitorare l'uso dell'AI. Exaforce vuole consentire ai team di sicurezza di collegare le azioni di un agente al dipendente, al dispositivo, alle credenziali, ai file e alle risorse cloud che ne sono alla base. Questa correlazione è importante perché un agente può compiere azioni singolarmente legittime che, insieme, formano una sequenza pericolosa.
Exaforce entra in un mercato in cui Microsoft, Cisco e Palo Alto Networks offrono già approcci concorrenti alla scoperta degli agenti e al controllo in fase di esecuzione. Il suo elemento distintivo è un modello agentless che utilizza integrazioni esistenti e telemetria degli endpoint. La domanda centrale è se questo modello riesca a identificare l'intento malevolo con un'accuratezza sufficiente da giustificare un intervento automatizzato.
Exaforce AI Security collega le azioni degli agenti in un unico incidente
Il lancio considera il comportamento di un agente AI come una sequenza connessa, anziché come un insieme di voci di log isolate.
Exaforce AI Security è diventato generalmente disponibile tramite la piattaforma gestita direttamente dall'azienda e il suo servizio di managed detection and response. I dettagli del lancio dell'azienda descrivono tre funzioni principali: scoprire l'attività AI, identificare configurazioni rischiose e rilevare minacce mentre gli agenti operano.
La scoperta copre applicazioni AI, agenti desktop, uso dei modelli, server Model Context Protocol, skill, plugin e credenziali correlate. Model Context Protocol, generalmente abbreviato in MCP, è uno standard che consente ai sistemi AI di connettersi a strumenti esterni e fonti di dati.
Secondo quanto riportato, la piattaforma utilizza API di provider di modelli, servizi SaaS, suite di produttività e sistemi di identità. Analizza inoltre i dati di endpoint detection and response già raccolti da Exaforce. Questo design significa che i clienti non devono installare un ulteriore agente endpoint esclusivamente per le nuove funzionalità.
Exaforce afferma di poter distinguere un agente AI dagli altri processi su un dispositivo. Quindi associa quel processo all'identità di un dipendente, al dispositivo utilizzato e alle autorizzazioni disponibili per quella persona.
La piattaforma può seguire l'attività successiva, inclusa una shell aperta da un agente, un file letto dall'agente o un indirizzo esterno contattato. Monitora inoltre i log dei provider di modelli e le sessioni di chat AI alla ricerca di informazioni sensibili, intenti sospetti, prompt injection e utilizzi insoliti.
Questo contesto alimenta un grafo degli agenti. Il grafo collega dipendenti, agenti, applicazioni AI, autorizzazioni OAuth, credenziali, server MCP, file e risorse raggiungibili. Le autorizzazioni OAuth sono permessi delegati che consentono a un'applicazione di accedere a un altro servizio senza ricevere la password dell'utente.
Questo approccio affronta un problema pratico di logging. Un agente agisce spesso attraverso le credenziali della persona che lo ha avviato. Un log di audit cloud potrebbe quindi mostrare un dipendente autorizzato che legge un file, ruota una chiave o aggiorna del codice.
Ogni azione può apparire accettabile se esaminata singolarmente. Il pericolo diventa visibile solo quando il sistema collega le azioni e identifica una progressione insolita.
Un agente potrebbe leggere i cookie del browser, utilizzare una sessione memorizzata per raggiungere un servizio cloud e inviare dati a un dominio sconosciuto. Gli strumenti tradizionali possono registrare ogni passaggio senza riconoscere che questi costituiscono un unico incidente.
Exaforce afferma che il suo knowledge graph combina informazioni su identità, endpoint, cloud, SaaS, codice e provider AI. I suoi modelli di rilevamento possono quindi valutare l'intera sequenza rispetto al comportamento normale dell'identità.
L'azienda offre inoltre ai team di sicurezza una scelta sul grado di autonomia della risposta. Un'azione può richiedere l'approvazione di un analista, essere eseguita automaticamente oppure collocarsi tra queste due modalità secondo la policy organizzativa.
Il report indipendente sul lancio afferma che le opzioni di risposta includono la revoca delle sessioni, la disattivazione delle chiavi dei provider di modelli, l'isolamento dei dispositivi e la terminazione dei processi degli agenti. Exaforce raggruppa queste azioni sotto il termine “agent kill switch”.
Questa definizione fa pensare a un unico pulsante universale di spegnimento. In pratica, si tratta di una raccolta di azioni di contenimento applicate alle risorse che supportano un agente.
Un processo può essere terminato, ma lo stesso workflow potrebbe conservare le credenziali o riavviarsi altrove. Un contenimento efficace richiede quindi un controllo coordinato di processi, sessioni, chiavi, dispositivi e servizi connessi.
Il rilevamento degli agenti fuori controllo sta diventando un problema di identità
La sfida di sicurezza inizia quando un software autonomo eredita un accesso umano fidato, ma opera più rapidamente e in modo meno prevedibile del suo proprietario.
Un agente aziendale raramente lavora in isolamento. Può ricevere un'attività, leggere documenti interni, chiamare API, invocare strumenti locali, creare codice e comunicare con altri servizi.
Queste capacità conferiscono agli agenti valore operativo. Trasformano però anche un'istruzione errata, un'integrazione compromessa o un prompt malevolo in una catena di azioni autenticate.
Ecco perché il rilevamento degli agenti fuori controllo di Exaforce si concentra in gran parte sull'identità. Il sistema deve rispondere a chi ha avviato l'agente, quale identità rappresenta, quali credenziali può utilizzare e quali risorse tali credenziali possono raggiungere.
L'identità di un dipendente convenzionale presenta un modello relativamente comprensibile. I team di sicurezza conoscono il ruolo della persona, i dispositivi abituali, le applicazioni normalmente utilizzate e l'orario di lavoro previsto.
Un agente complica questo modello. Può operare ininterrottamente, completare molte azioni rapidamente e selezionare strumenti senza chiedere approvazione a ogni passaggio. Potrebbe anche generare processi locali o usare autorizzazioni concesse per un workflow umano più ampio.
Il risultato è un divario di attribuzione. Il log identifica il dipendente, ma il dipendente non ha avviato manualmente ogni azione registrata. Gli investigatori devono separare l'intento umano dall'esecuzione dell'agente.
Exaforce sostiene che gli strumenti esistenti per endpoint e SaaS non siano stati progettati per questa distinzione. L'amministratore delegato Ankur Singla ha dichiarato che i team di sicurezza necessitano dell'attività degli agenti combinata con le informazioni su identità, cloud ed endpoint che già raccolgono.
L'azienda illustra il problema con un agente AI desktop in esecuzione con i prompt di sicurezza disabilitati. Secondo Exaforce, l'agente ha aperto una shell, copiato un database di cookie del browser e cercato al suo interno cookie di sessione aziendali.
L'endpoint non ha bloccato l'attività. Exaforce afferma che la sua piattaforma ha seguito l'albero dei processi, associato l'attività a un indirizzo esterno e collegato il tutto a 15 rilevamenti precedenti che coinvolgevano lo stesso utente e indirizzo.
L'azienda ha classificato l'incidente come rilevamento di priorità uno e afferma che sia stato sottoposto a triage in 11 minuti. Questi dettagli provengono dall'ambiente di Exaforce o dalla telemetria dei clienti e non sono stati sottoposti a benchmark indipendenti.
Tuttavia, lo scenario dimostra perché l'analisi delle sequenze in fase di esecuzione sia importante. Leggere un database del browser può essere sospetto, ma sono il comportamento circostante dell'identità e della rete a determinare il livello di rischio effettivo.
Un secondo esempio riguarda autorizzazioni OAuth eccessive. Exaforce afferma di aver trovato un'applicazione OpenAI autorizzata a scrivere, modificare, inviare o eliminare dati in tutto un ambiente Google Workspace.
Ha inoltre identificato un'integrazione di calendario Claude con autorizzazioni di scrittura e invio più ampie di quanto richiesto dalla sua attività prevista. Questi rilevamenti rappresentano rischi di postura, non attacchi confermati.
Questa distinzione è importante. Un'autorizzazione ampia crea un potenziale raggio d'impatto, mentre un comportamento malevolo in fase di esecuzione indica che il rischio viene sfruttato.
Exaforce AI Security tenta di collegare entrambi gli aspetti. Il suo livello di rischio identifica configurazioni vulnerabili prima di un incidente, mentre il rilevamento in fase di esecuzione cerca abusi attivi.
Per i team di sicurezza, questo crea un nuovo requisito di inventario. Devono comprendere non solo a quali modelli accedono i dipendenti, ma anche quali agenti, skill, plugin e server MCP possono trasformare l'output del modello in azione.
L'inventario deve rimanere aggiornato. I dipendenti possono installare un'estensione di coding AI o connettere un nuovo assistente SaaS senza un progetto di distribuzione centralizzato.
I responsabili della sicurezza affrontano da anni problemi simili di shadow IT. Il software agentico alza la posta in gioco perché l'applicazione non approvata può agire, non limitarsi a memorizzare o visualizzare informazioni.
Il design agentless è la principale scommessa di Exaforce
Exaforce scommette che la telemetria esistente possa rivelare il comportamento degli agenti senza aggiungere un ulteriore componente di monitoraggio a ogni endpoint.
L'affermazione agentless richiede un'interpretazione attenta. Exaforce non opera senza raccolta dati o integrazioni. Dipende da informazioni provenienti da prodotti di sicurezza endpoint esistenti, provider di modelli, sistemi di identità, servizi cloud e piattaforme di produttività.
“Agentless” significa che i clienti non installano un componente Exaforce aggiuntivo specificamente per monitorare gli agenti AI. La piattaforma analizza i dati che Exaforce già acquisisce o può ottenere tramite API dei provider.
Questa architettura offre un evidente vantaggio operativo. I team di sicurezza aziendali gestiscono già stack endpoint affollati, e ogni agente aggiuntivo introduce problemi di distribuzione, manutenzione, compatibilità e prestazioni.
Riutilizzare la telemetria consolidata può ridurre i tempi di implementazione. Può inoltre collocare l'attività AI nella stessa coda di indagine utilizzata per incidenti relativi a identità, cloud, endpoint e SaaS.
Questa visione unificata è il meccanismo centrale alla base di Exaforce AI Security. La piattaforma non giudica un agente esclusivamente in base al prompt inviato a un modello o alla risposta restituita.
Esamina invece l'attività circostante. Ciò include processi del dispositivo, connessioni di rete, accesso ai file, autenticazione degli account, chiamate cloud, contesto del codice e utilizzo del provider.
Un assistente di coding che apre una shell non è automaticamente malevolo. Aprire una shell, leggere file di credenziali, contattare un dominio sconosciuto e tentare un accesso cloud forma un modello più significativo.
Lo stesso principio si applica alle applicazioni aziendali. Un assistente di calendario che accede agli eventi è coerente con il suo scopo. Lo stesso assistente che riceve ampia autorità per inviare email o modificare dati non correlati dello spazio di lavoro merita un esame più approfondito.
Il livello di rischio di Exaforce valuta inoltre skill e plugin prima dell'esecuzione. L'azienda ha descritto il rilevamento di una skill legata alla cucina la cui funzione di analisi cercava ed esfiltrava variabili d'ambiente sensibili.
La discrepanza tra lo scopo dichiarato della skill e il comportamento del suo codice ha aumentato il rischio. Si tratta di un problema di supply chain software espresso attraverso un'estensione AI.
Le skill e i server MCP possono ampliare rapidamente le capacità di un agente. Possono anche introdurre codice non esaminato, dipendenze remote e percorsi di accesso che gli utenti non comprendono.
Exaforce afferma che la sua piattaforma assegna punteggi di rischio e raccomandazioni a questi componenti. Tale valutazione può contribuire a dare priorità alle revisioni, ma la sua utilità dipende dalla qualità del rilevamento e dal contesto disponibile.
Il modello agentless crea anche il suo limite più importante. Exaforce può analizzare solo l'attività rappresentata nella telemetria che riceve.
Un prodotto endpoint potrebbe mostrare che un processo ha letto un file, ma non rivelare il ragionamento completo dell'agente o il prompt che ha innescato l'azione. Un provider di modelli potrebbe esporre log di utilizzo senza registrare ogni chiamata a strumenti locali.
Le API dei provider differiscono anche per copertura e tempistiche. Alcune offrono audit trail completi, mentre altre espongono informazioni amministrative limitate. I modelli ospitati localmente o gli agenti personalizzati possono generare registrazioni ancora diverse.
Il traffico crittografato, gli strumenti non supportati, i dispositivi disconnessi e i processi di breve durata possono creare punti ciechi. Un sistema assemblato a partire dai log esistenti deve identificare e comunicare chiaramente queste lacune.
Questo non invalida l'architettura. Significa che “agentless” descrive la comodità di distribuzione, non un'osservabilità completa.
Un acquirente che valuta il prodotto dovrebbe chiedere quali segnali siano disponibili per ciascun tipo di agente. La risposta varierà tra ChatGPT, Gemini, Copilot, Claude, agenti di coding locali, workflow personalizzati e modelli self-hosted.
Le implementazioni più solide probabilmente combineranno registrazioni dei provider con telemetria di endpoint, rete, identità e cloud. L'assenza di uno di questi livelli può indebolire l'attribuzione o ritardare il contenimento.
Per i team che già inviano tali segnali a Exaforce, l'integrazione potrebbe essere relativamente diretta. Le organizzazioni che utilizzano prodotti endpoint o di identità non supportati potrebbero avere un'esperienza diversa.
Microsoft, Cisco e Palo Alto controllano già livelli fondamentali
Exaforce non sta creando la categoria della sicurezza degli agenti; sta sfidando vendor più grandi su dove dovrebbe risiedere il controllo.
Microsoft ha posizionato Agent 365 come un control plane per osservare, governare e proteggere gli agenti. Copre gli agenti che utilizzano accesso delegato dei dipendenti e quelli che operano con le proprie credenziali.
Il control plane per gli agenti dell'azienda combina Microsoft Defender, Intune, Entra e l'amministrazione di Microsoft 365. Può individuare agenti locali e cloud, mappare identità e risorse e applicare policy agli agenti supportati.
Microsoft afferma inoltre che Defender può associare un agente al suo dispositivo, all'identità correlata, ai server MCP configurati e alle risorse cloud raggiungibili. Questo appare vicino al contesto basato su grafi promosso da Exaforce.
La differenza strategica è la distribuzione. Microsoft controlla già identità, produttività, gestione dei dispositivi e sicurezza degli endpoint all'interno di molte aziende.
Agent 365 può quindi rendere il governo degli agenti una funzionalità di un ambiente di amministrazione Microsoft esistente. Exaforce deve dimostrare perché un livello di sicurezza indipendente offra un contesto più ampio o più utile.
Il vantaggio di Microsoft può anche essere un limite. Le aziende utilizzano agenti e servizi in più cloud, presso diversi provider di modelli, su endpoint e piattaforme SaaS differenti. Un team di sicurezza potrebbe preferire un vendor non incentrato su un singolo ecosistema software.
Palo Alto Networks affronta il problema tramite Prisma AIRS, la sua piattaforma di sicurezza AI. Prisma AIRS 3.0 include individuazione degli agenti, scansione degli artefatti, red teaming, controlli delle identità e applicazione delle policy in runtime.
Il suo AI Agent Gateway è concepito come punto centrale per governance e controllo in runtime. Palo Alto Networks collega inoltre la sicurezza AI con prodotti di rete, cloud, browser ed endpoint.
Cisco segue un'altra strada attraverso AI Defense. La sua protezione in runtime copre prompt, risposte, flussi di dati, interazioni MCP e workflow degli agenti.
Cisco può contare sulla visibilità di rete e sull'intelligence sulle minacce. Questa posizione la aiuta a ispezionare il traffico tra agenti, modelli, utenti e servizi esterni.
Questi concorrenti mostrano che il mercato sta convergendo attorno a diverse funzioni comuni:
Individuare agenti autorizzati e non autorizzati.
Associare gli agenti a proprietari e identità.
Mappare strumenti, autorizzazioni, dati e risorse raggiungibili.
Valutare skill, modelli, prompt e integrazioni.
Monitorare il comportamento mentre gli agenti operano.
Bloccare azioni pericolose o revocare l'accesso.
Conservare le prove per le indagini.
La distinzione di Exaforce consiste nel collocare queste funzioni all'interno della sua piattaforma agentica per le operazioni di sicurezza. Sostiene che l'attività degli agenti dovrebbe comparire nello stesso contesto investigativo di ogni altro segnale aziendale.
Questo design potrebbe attrarre i provider di sicurezza gestita e i team di sicurezza snelli. Potrebbero preferire un'unica coda operativa anziché un'altra console specializzata per la sicurezza AI.
Tuttavia, i vendor di piattaforme più grandi possono sostenere lo stesso argomento di consolidamento. Microsoft può consolidare attorno al proprio control plane amministrativo. Palo Alto Networks può consolidare attorno al proprio portafoglio di sicurezza. Cisco può consolidare attorno all'applicazione delle policy di rete e in runtime.
La questione competitiva non è quindi chi offra per primo un inventario degli agenti o un kill switch. È chi riesca a raccogliere il contesto più rilevante e a trasformarlo in decisioni accurate.
Exaforce gestisce anche i propri agenti di sicurezza AI, chiamati Exabots, per rilevamento, triage, indagine, hunting e risposta. La sua piattaforma utilizza ora agenti AI per contribuire a proteggere altri agenti AI.
Questa simmetria crea valore e rischio. L'analisi automatizzata può elaborare attività complesse più rapidamente di un team umano, ma una valutazione errata del modello può attivare un'azione di contenimento non necessaria.
Le impostazioni di approvazione umana offrono ai clienti un modo per gestire questo rischio. Tuttavia, richiedere l'approvazione per ogni risposta può ridurre il vantaggio di velocità promesso dall'automazione.
Il mercato si sta infine muovendo verso un'autonomia graduata. Le azioni a basso rischio possono essere eseguite automaticamente, mentre le risposte disruptive richiedono prove più solide o una conferma umana.
Un kill switch per gli agenti non può risolvere un rilevamento debole
Un controllo di risposta è affidabile solo quanto le prove utilizzate per attivarlo.
L'espressione “agent kill switch” implica certezza. Un sistema rileva un agente malevolo, un operatore preme un pulsante e la minaccia termina.
Gli ambienti aziendali sono meno ordinati. Gli agenti dipendono da processi, credenziali, account presso provider di modelli, integrazioni, sessioni del browser e risorse cloud. Terminare un componente non elimina sempre gli altri.
Un attaccante può conservare un token OAuth dopo la fine di un processo dell'agente. Un workflow pianificato può riavviare il processo. Un'identità compromessa può avviare le stesse azioni attraverso un altro strumento.
Per questo le opzioni di risposta di Exaforce vanno oltre la terminazione dei processi. Revoca delle sessioni, disattivazione delle chiavi, isolamento dei dispositivi e controlli delle identità possono rimuovere più percorsi contemporaneamente.
Queste azioni possono anche interrompere il lavoro legittimo. Isolare il dispositivo di uno sviluppatore o revocare una credenziale di produzione genera conseguenze operative, in particolare quando la confidenza del rilevamento è incerta.
I falsi positivi contano quindi quanto gli attacchi mancati. Una piattaforma che generi avvisi per ogni invocazione della shell, lettura di file di grandi dimensioni o dominio non familiare sommergerà gli analisti e scoraggerà la risposta automatica.
Exaforce afferma che i suoi modelli contestuali riducono questo problema collegando comportamenti correlati. L'affermazione è plausibile, ma i materiali di lancio non forniscono misurazioni indipendenti dei tassi di rilevamento.
Non divulgano neppure i tassi di falsi positivi per le nuove funzionalità di sicurezza degli agenti. Nessun benchmark pubblico confronta il rilevamento di agenti malevoli di Exaforce con quello di Microsoft, Cisco, Palo Alto Networks o vendor specializzati.
La copertura rappresenta un'altra incertezza. Exaforce cita i principali provider, tra cui OpenAI, Google, Microsoft e Anthropic. Le aziende utilizzano anche agenti personalizzati, modelli open source, estensioni del browser e sistemi di orchestrazione interni.
L'efficacia del prodotto dipenderà da quanto coerentemente riconosca queste diverse implementazioni. Un agente eseguito all'interno di uno strumento non supportato potrebbe apparire come un normale processo.
Il contesto comportamentale può aiutare, ma il contesto non equivale all'intento. Un agente di test della sicurezza potrebbe raccogliere cookie o sondare i confini di accesso nell'ambito di un'esercitazione autorizzata.
Un agente compromesso può anche imitare il lavoro normale. Potrebbe esfiltrare piccole quantità di dati attraverso un servizio approvato o rimanere entro gli schemi di accesso già esistenti dell'utente.
Le risposte automatizzate aggiungono una questione di governance. I clienti devono decidere quali azioni la piattaforma possa eseguire senza conferma e chi sia responsabile quando tali azioni causano interruzioni.
Una policy matura dovrebbe collegare l'autorità di risposta a confidenza, sensibilità dell'asset e impatto sul business. Terminare un processo sperimentale di scarso valore è diverso dal disabilitare una credenziale utilizzata dai sistemi di produzione.
I team di sicurezza dovrebbero anche testare le modalità di guasto prima di abilitare la piena autonomia. Le esercitazioni possono misurare se un endpoint isolato resti raggiungibile per l'indagine e se la revoca di una chiave influenzi servizi non correlati.
Le prove più credibili proverranno da deployment documentati presso i clienti. Gli acquirenti devono sapere quanto tempo richieda l'individuazione, quali agenti rimangano invisibili e quante segnalazioni richiedano correzioni degli analisti.
Hanno inoltre bisogno di esempi che coinvolgano attività avversarie reali, non solo autorizzazioni rischiose o configurazioni di test intenzionalmente non sicure. Le evidenze sulla postura e i rilevamenti delle minacce risolvono problemi diversi.
Gli esempi riportati da Exaforce su tenant attivi offrono una prima visione. Non stabiliscono prestazioni generali in ambienti aziendali eterogenei.
Questo è il principale compromesso alla base di Exaforce AI Security. Il deployment agentless può ridurre l'attrito nell'implementazione, ma la dipendenza dalla telemetria esistente può produrre una visibilità disomogenea.
Il prodotto potrebbe funzionare bene dove Exaforce riceve già dati completi da endpoint, identità, cloud e provider. Le sue conclusioni saranno meno certe ovunque tali segnali siano incompleti.
Cosa dimostrerà che Exaforce AI Security funziona
Il prossimo test non è un altro annuncio di funzionalità; sono prove misurabili che la piattaforma individui sequenze pericolose senza interrompere gli agenti legittimi.
Il primo segnale da osservare è la validazione indipendente dei clienti. Exaforce necessita di report di deployment che mostrino quali agenti abbia individuato, quali rischi abbia inizialmente mancato e come gli analisti abbiano gestito le sue segnalazioni.
Prove utili separerebbero copertura dell'inventario, analisi della postura, rilevamento attivo delle minacce e risposta. Combinare questi risultati in un'unica dichiarazione di successo renderebbe difficile la valutazione.
I risultati dei clienti dovrebbero inoltre indicare la telemetria disponibile in ciascun ambiente. Le prestazioni di rilevamento basate su un'ampia copertura di endpoint e identità non dovrebbero essere generalizzate a organizzazioni con meno integrazioni.
Solidi risultati sul campo rafforzerebbero l'affermazione di Exaforce secondo cui i dati esistenti possono supportare la sicurezza in runtime agentless. Punti ciechi persistenti indebolirebbero l'argomento centrale del design.
Il secondo segnale è una copertura di integrazione più ampia. Il lancio attuale si collega ai principali provider di modelli e utilizza dati endpoint e aziendali esistenti.
L'adozione aziendale degli agenti non rimarrà concentrata in pochi prodotti. I team interni possono assemblare agenti da modelli aperti, framework di codice, server MCP, strumenti a riga di comando e API personalizzate.
Exaforce deve continuare a riconoscere nuove forme di agenti senza richiedere un sensore dedicato per ciascuna. Gli annunci di integrazione sono rilevanti solo quando espongono dati sufficienti per attribuzione e risposta.
Il supporto alla sola individuazione è insufficiente. I team di sicurezza necessitano di relazioni tra processi, chiamate agli strumenti, autorizzazioni, credenziali, destinazioni di rete e controlli di risposta.
Il terzo segnale è come risponderanno i concorrenti. Microsoft, Palo Alto Networks e Cisco occupano già preziosi punti di applicazione delle policy tra identità, endpoint, reti e cloud.
Se questi vendor renderanno il contesto degli agenti multipiattaforma una parte standard dei loro prodotti esistenti, Exaforce subirà una maggiore pressione distributiva. Se i loro strumenti resteranno legati a ecosistemi ristretti, un livello di correlazione indipendente diventerà più attraente.
Il prezzo non è l'unico fattore d'acquisto. I team di sicurezza confronteranno impegno di deployment, qualità delle indagini, profondità delle integrazioni, opzioni di servizi gestiti e conseguenze di azioni automatizzate errate.
La posizione di Exaforce è più chiara per le organizzazioni che utilizzano già la sua piattaforma per le operazioni di sicurezza o il servizio MDR. Le nuove funzionalità possono integrare l’attività degli agenti AI in un flusso di lavoro consolidato.
I nuovi clienti devono invece prendere una decisione più ampia sulla piattaforma. Devono confrontare Exaforce con i controlli già inclusi nel proprio stack di identità, endpoint, cloud o rete.
Il lancio evidenzia inoltre una crescente necessità di memoria istituzionale sulle attività degli agenti. Gli investigatori devono poter accedere a decisioni, approvazioni, prove relative agli incidenti e lezioni apprese dalle implementazioni precedenti.
Una base di conoscenza AI ricercabile può aiutare i team a preservare questo contesto, anche se non sostituisce i controlli di sicurezza in fase di esecuzione.
Per gli acquirenti enterprise, l’azione immediata consiste nel censire gli agenti e i loro accessi prima di selezionare una piattaforma di sicurezza. Occorre identificare chi è responsabile di ciascun agente, quali credenziali utilizza e quali sistemi può modificare.
Successivamente, testate Exaforce AI Security o una piattaforma concorrente rispetto a scenari realistici. Includete prompt injection, autorizzazioni OAuth eccessive, catene di strumenti sospette, accesso alle credenziali, spostamento dei dati e flussi di lavoro legittimi che assomigliano ad attacchi.
Misurate sia il rilevamento sia l’interruzione. La piattaforma vincente non sarà quella con il linguaggio più eclatante sui kill switch. Sarà quella che distingue con coerenza l’autonomia pericolosa dall’automazione produttiva, per poi rispondere al livello appropriato.
