La rivalità tra Anthropic e Google arriva al SOC, ma Claude non è una piattaforma di sicurezza

Anthropic e Google stanno spingendo l'AI più in profondità nelle operazioni di sicurezza, nonostante resti irrisolto il conflitto su quanta autorità debbano ricevere questi sistemi. La competizione tra Anthropic e Google raggiunge ora un ambiente di lavoro particolarmente spietato: il security operations center, o SOC, dove un errore espresso con sicurezza può trasformarsi in un incidente.

Il fattore scatenante immediato è il crescente interesse per piattaforme di AI generalista come Claude, accanto a prodotti integrati come Google Security Operations. I responsabili della sicurezza vedono potenziali vantaggi nell'indagine sugli avvisi, nella detection engineering, nei riepiloghi degli incidenti e nelle attività amministrative ripetitive. Devono inoltre affrontare la pressione ad adottarli prima che i concorrenti sembrino ottenere un vantaggio.

Questa pressione porta a porsi la domanda sbagliata. La scelta non riguarda se Claude, Gemini o un altro modello sia in grado di produrre un'analisi di sicurezza impressionante. Riguarda invece se un'organizzazione possa inserire tale analisi in un flusso di lavoro controllato, con evidenze affidabili, permessi limitati e decisioni umane responsabili.

Google ha scelto la strada della piattaforma integrata. Anthropic ha posto l'accento sulle capacità di ragionamento e cybersecurity di Claude, incluso il lavoro con fornitori di sicurezza e partner enterprise. La competizione principale è quindi più ampia di un modello contro un altro. È una competizione tra un livello di ragionamento generalista e una piattaforma di sicurezza che già gestisce telemetria, workflow, policy e controlli di risposta.

Cosa è cambiato quando Claude è entrato nella conversazione sul SOC

Claude è passato dall'essere un esperimento non ufficiale per gli analisti a una componente seria dei workflow di sicurezza enterprise.

I team di sicurezza utilizzano informalmente i modelli linguistici da anni. Gli analisti incollano script sanificati nelle interfacce chat, chiedono spiegazioni di comandi poco familiari e chiedono ai modelli di riassumere report pubblici sulle minacce. Queste attività richiedono poca integrazione e non conferiscono al modello alcuna autorità operativa.

I casi d'uso più recenti si avvicinano molto di più alla produzione. Anthropic presenta Claude come uno strumento per analizzare vulnerabilità, interpretare dati di sicurezza, supportare il rilevamento delle minacce e aiutare i team a indagare sugli incidenti. La sua offerta per la cybersecurity descrive workflow che collegano Claude agli strumenti di sicurezza e al contesto organizzativo.

Anthropic ha inoltre annunciato partnership che collocano Claude all'interno di servizi gestiti. La sua collaborazione con DXC include un subagente di security engineering sempre attivo, pensato per l'implementazione nei security operations center di DXC. Si tratta di un livello di impegno diverso rispetto al chiedere a un chatbot di spiegare una voce di log.

Nel frattempo, Google promuove un SOC agentico basato su Gemini e Google Security Operations. Un sistema agentico può pianificare ed eseguire più attività connesse, invece di rispondere a un prompt alla volta. Google afferma che i suoi agenti supportano il triage degli avvisi, il threat hunting, le indagini e la detection engineering.

Google sostiene che il suo agente di triage e indagine possa ridurre una tipica analisi manuale di 30 minuti a 60 secondi. Questa cifra proviene da Google, non da una sperimentazione comparativa indipendente. Tuttavia, la dichiarazione spiega perché la rivalità tra Anthropic e Google interessi gli acquirenti di soluzioni di sicurezza alle prese con code elevate e personale limitato.

Questo cambiamento crea la tensione centrale. Un modello può essere utile senza essere un prodotto di sicurezza completo. Claude può ragionare su diversi artefatti, redigere query e organizzare le evidenze. Non fornisce automaticamente telemetria affidabile, controlli di identità, gestione dei casi, passaggi di approvazione o una traccia di audit difendibile.

La distinzione è facile da trascurare durante una dimostrazione ben curata. Un modello può analizzare con notevole velocità le evidenze che riceve. Se tali evidenze sono incomplete, normalizzate in modo errato o private del contesto ambientale, la risposta può restare fluida e sbagliata.

L'evento pratico non è quindi il rilascio di un singolo prodotto. È la normalizzazione dei modelli fondazionali nel lavoro operativo di sicurezza. Questo cambiamento costringe i responsabili a definire dove finisca l'assistenza e dove inizi l'autorità delegata.

Perché la competizione tra Anthropic e Google mette sotto pressione i responsabili della sicurezza

La pressione ricade sui CISO, che devono dimostrare progressi nell'AI senza indebolire i controlli che già difendono.

I responsabili della sicurezza ascoltano due messaggi contrastanti. I fornitori promettono indagini più rapide e una copertura più ampia. I team di governance avvertono che log sensibili, credenziali, codice sorgente e registri degli incidenti non possono essere trasferiti liberamente a un modello esterno.

Aspettare comporta un costo percepito. Un'organizzazione concorrente potrebbe dichiarare tempi di indagine più brevi, una creazione di regole più rapida o una migliore produttività degli analisti. I dirigenti chiedono quindi perché il proprio team di sicurezza non abbia adottato strumenti simili.

Muoversi rapidamente comporta un rischio più concreto. I dati di sicurezza contengono le informazioni esatte che un attaccante desidera, inclusi nomi degli account, indirizzi interni, versioni software, logiche di rilevamento e procedure di risposta. Un assistente mal governato può esporre queste informazioni o agire su contenuti malevoli incorporati al loro interno.

Ecco perché l'aderenza alla piattaforma conta più dell'entusiasmo per il modello. Google Security Operations combina già la gestione delle informazioni e degli eventi di sicurezza con funzioni di orchestrazione e risposta. La sua documentazione di Gemini identifica inoltre considerazioni sul trattamento dei dati e sulla governance che gli acquirenti devono valutare.

Un modello generalista entra da una direzione diversa. Claude può collocarsi sopra gli strumenti esistenti e ragionare sui loro output. Questa flessibilità può aiutare le organizzazioni a evitare la dipendenza da un'unica piattaforma di sicurezza, ma ogni nuova connessione introduce un confine che deve essere autenticato, monitorato e vincolato.

La pressione operativa è più forte per i team con ambienti frammentati. Un gruppo può utilizzare una piattaforma di rilevamento cloud-native, un altro può gestire gli avvisi endpoint e un terzo può occuparsi delle indagini sulle identità. Un modello può creare un livello conversazionale comune tra questi sistemi.

La conversazione non crea una fonte comune di verità. Se due strumenti assegnano timestamp, identità host o etichette di gravità diverse, il modello necessita comunque di una logica deterministica per risolvere il conflitto. Non dovrebbe improvvisare una risposta perché il prompt ne richiede una.

Anche l'argomento relativo al personale merita cautela. L'AI può eliminare attività ripetitive, ma l'automazione modifica le competenze richieste invece di eliminarle. I team hanno bisogno di persone in grado di valutare la qualità delle evidenze, progettare i permessi degli strumenti, testare i prompt contro input avversari e riconoscere conclusioni non supportate.

Gli analisti junior possono ottenere un accesso più rapido alle spiegazioni. Possono anche diventare meno propensi a mettere in discussione output espressi con sicurezza. Gli analisti senior restano responsabili di riconoscere quando le evidenze disponibili non supportano un verdetto.

La risposta necessaria non è quindi un'implementazione autonoma immediata. I responsabili della sicurezza hanno bisogno di sperimentazioni circoscritte legate a attività misurabili. Queste sperimentazioni dovrebbero confrontare il lavoro assistito dal modello con le prestazioni attuali, quindi registrare conclusioni errate, evidenze mancate, tassi di escalation e interventi correttivi degli analisti.

Claude si colloca tra la raccolta delle evidenze e il giudizio umano

Claude è più adatto come livello di ragionamento e redazione dopo la raccolta delle evidenze, ma prima di un'azione con conseguenze.

Il caso d'uso più chiaro è il supporto alle indagini. Una piattaforma di sicurezza raccoglie avvisi, alberi dei processi, eventi di identità, connessioni di rete e threat intelligence. Claude può organizzare questo materiale in una timeline, identificare le evidenze mancanti e suggerire le query successive che un analista dovrebbe eseguire.

Questa collocazione sfrutta il principale punto di forza del modello senza fingere che possieda i fatti sottostanti. Offre inoltre agli analisti un confine visibile. Il modello propone un'interpretazione, mentre il sistema delle evidenze conserva i record originali.

Il riepilogo degli incidenti è un altro impiego sensato. Durante un'indagine attiva, le informazioni si accumulano tra ticket, messaggi chat, query e note di passaggio di consegne. Claude può trasformare questi frammenti in un riepilogo strutturato per il turno successivo.

Il riepilogo deve restare tracciabile alle sue fonti. Una frase priva di un evento collegato, di un risultato di query o di una nota dell'analista dovrebbe essere trattata come un'affermazione, non come un'evidenza. Questa regola protegge il team dai riepiloghi che aggiungono silenziosamente dettagli plausibili.

La detection engineering offre maggiore leva e maggiori rischi. Claude può redigere query di rilevamento, tradurre la logica tra linguaggi, spiegare condizioni rumorose e mappare una regola a comportamenti noti degli attaccanti. Un analista può testare la bozza sui dati storici prima della distribuzione.

Il modello non dovrebbe pubblicare direttamente un rilevamento in produzione. Una regola sintatticamente valida può generare un numero eccessivo di avvisi, non rilevare varianti importanti o incorporare un'ipotesi errata sulla telemetria locale. Test e revisione restano passaggi necessari dell'ingegneria.

Claude può anche aiutare con l'arricchimento ripetitivo. Può classificare indicatori pubblici, estrarre entità dai report e preparare checklist per le indagini. Queste attività fanno risparmiare tempo quando i loro output restano suggerimenti o entrano in una coda di validazione.

Le organizzazioni che stanno già creando basi di conoscenza ricercabili dispongono di un'altra base utile. Runbook approvati, documenti di architettura e decisioni su incidenti precedenti possono fornire un contesto controllato senza concedere al modello accesso illimitato a ogni repository interno.

La collocazione sbagliata inizia con l'azione diretta. Consentire a un modello generalista di disabilitare account, isolare host, ruotare credenziali o modificare regole firewall introduce un raggio d'azione più ampio in caso di errore. Anche azioni corrette possono causare disagi quando mancano tempistiche e contesto aziendale.

Un input compromesso può anche manipolare un agente. La prompt injection si verifica quando contenuti non attendibili contengono istruzioni progettate per reindirizzare il comportamento di un modello. In un SOC, tali contenuti potrebbero comparire in un'email, un documento, un campo di log, una stringa malware o una pagina web raccolta durante un'indagine.

La guida zero trust di Anthropic sostiene che gli agenti vadano trattati come partecipanti non attendibili, con accesso a livelli e permessi limitati. Questo principio è particolarmente importante nelle operazioni di sicurezza perché il modello incontra regolarmente dati controllati dagli attaccanti.

Da questa minaccia derivano confini di implementazione utili. Il modello dovrebbe ricevere i dati minimi necessari per un'attività. Le chiamate agli strumenti dovrebbero utilizzare permessi ristretti. Le azioni ad alto impatto dovrebbero richiedere approvazione e ogni prompt, fase di recupero, invocazione di strumenti e risultato dovrebbe entrare in un record di audit.

Questi controlli trasformano Claude in uno strumento per analisti. Senza di essi, lo stesso modello diventa un'interfaccia imprevedibile verso sistemi privilegiati.

Il vantaggio di piattaforma di Google non elimina il rischio del modello

Google può integrare Gemini più profondamente perché controlla la piattaforma circostante, ma l'integrazione da sola non stabilisce un'autonomia affidabile.

Il principale vantaggio di Google è la vicinanza a dati di sicurezza normalizzati. Google Security Operations può collegare l'output del modello a rilevamenti, casi, threat intelligence e workflow di risposta. Il suo SOC agentico è progettato attorno a questo ambiente operativo condiviso.

Questa architettura riduce parte del lavoro di integrazione. La piattaforma può applicare le policy di identità esistenti, registrare l'attività dei workflow e presentare le evidenze attraverso un'unica interfaccia. Può inoltre collegare le indagini assistite dai modelli ai controlli di sicurezza consolidati.

La flessibilità di Claude comporta il compromesso opposto. Le organizzazioni possono collegarlo a prodotti di diversi fornitori e preservare la propria architettura di sicurezza esistente. Questo approccio può ridurre la dipendenza da un'unica piattaforma, ma richiede che il cliente assembli una porzione maggiore del piano di controllo.

Questo è il confronto significativo tra Anthropic e Google. Claude offre un livello di ragionamento portabile, capace di funzionare in ambienti diversi. Gemini arriva come parte di una piattaforma di sicurezza con accesso nativo a workflow e telemetria.

Nessuna delle due strutture garantisce una conclusione accurata. Un modello profondamente integrato può comunque fraintendere un evento. Un modello portabile può produrre un'analisi solida quando riceve evidenze complete e ben strutturate.

La qualità del sistema circostante conta quanto la capacità del modello. Tale sistema comprende regole di recupero delle informazioni, normalizzazione dei dati, risoluzione delle identità, autorizzazioni degli strumenti, istruzioni del modello, test di convalida e policy di escalation.

Una dimostrazione di un fornitore spesso nasconde queste dipendenze. Il pubblico vede un avviso sospetto trasformarsi in una narrazione chiara. Raramente vede la preparazione necessaria per rendere disponibile ogni evento pertinente, rimuovere i duplicati, risolvere le identità e verificare ogni conclusione.

L'autonomia modifica anche il carico dei test. Un copilot che redige una query crea un artefatto sottoponibile a revisione. Un agente che esegue diverse query e chiude un caso prende una catena di decisioni il cui tasso di fallimento combinato è rilevante.

I team di sicurezza dovrebbero testare workflow completi, non prompt isolati. Un modello potrebbe interpretare correttamente 19 singoli passaggi, ma fallire al ventesimo, quello che determina se un account viene disabilitato. Il completamento aggregato dell'attività non rivela l'impatto dell'errore finale.

L'integrazione dei prodotti Google può rendere questi test più facili da strumentare. La portabilità del modello di Anthropic può rendere più agevole una valutazione indipendente tra sistemi diversi. Gli acquirenti dovrebbero considerare entrambe come caratteristiche architetturali, non come prova che una delle due strade sia universalmente più sicura.

L'approccio vincente potrebbe combinarle. Una piattaforma di sicurezza può gestire evidenze, accesso e orchestrazione, mentre un modello valutato separatamente svolge specifiche attività di ragionamento. Questa configurazione riduce l'importanza di dichiarare un modello vincitore permanente.

Migliora anche le opzioni di uscita. Le prestazioni dei modelli cambiano rapidamente, mentre i dati di sicurezza e le policy organizzative persistono. Un'architettura SOC dovrebbe consentire ai team di sostituire il componente di ragionamento senza ricostruire anni di rilevamenti, casi e conoscenza istituzionale.

Il Rischio Reale È Confondere la Fluidità con la Profondità Forense

Una narrazione persuasiva non è una conclusione forense, a meno che ogni affermazione sostanziale non resti collegata a evidenze affidabili.

I modelli linguistici di grandi dimensioni producono spiegazioni coerenti anche quando gli input contengono lacune. Questo comportamento è utile per la redazione, ma pericoloso quando un analista interpreta la sicurezza espressa dal modello come certezza. Le indagini di sicurezza dipendono spesso da un singolo evento di processo mancante o da una relazione di identità fraintesa.

La profondità forense significa determinare cosa è stato eseguito, da dove proveniva, cosa è cambiato e quali evidenze supportano quella sequenza. Il testo di un avviso raramente risponde a tali domande. Un'indagine può richiedere analisi della memoria, ispezione dei binari, telemetria degli endpoint, cronologia delle identità ed evidenze di rete.

The Hacker News ha già evidenziato questa lacuna nella sua copertura delle indagini guidate dall'AI. La distinzione centrale è valida anche quando le dichiarazioni dei fornitori sulle prestazioni richiedono una convalida indipendente: riassumere un avviso non equivale a investigare il sistema sottostante.

Un modello può anche ereditare debolezze dal recupero delle informazioni. Se il connettore seleziona soltanto avvisi ad alta gravità, il modello non può identificare una campagna che diventa visibile attraverso vari eventi a bassa gravità. Se le policy di conservazione hanno rimosso un accesso precedente, il modello non può ricostruirlo.

L'accesso a più dati non risolve ogni problema. Un accesso esteso aumenta l'esposizione a rischi per privacy, riservatezza e prompt injection. L'obiettivo corretto è un contesto sufficiente e governato, non un contesto senza restrizioni.

La residenza dei dati introduce un altro vincolo. I registri di sicurezza possono contenere informazioni regolamentate o dettagli soggetti a impegni contrattuali. I team devono capire dove vengono elaborati i prompt e i record recuperati, per quanto tempo i fornitori li conservano e se gli esseri umani possono accedervi.

Gli aggiornamenti dei modelli complicano la convalida. Un workflow testato rispetto a una versione può comportarsi diversamente dopo che un fornitore modifica il modello. I team di sicurezza hanno bisogno di registri delle versioni, casi di test ripetibili e un processo per approvare le modifiche prima che influenzino la produzione.

La competizione tra Anthropic e Google può oscurare queste limitazioni condivise. Il marketing invita gli acquirenti a confrontare risultati di benchmark e dimostrazioni di agenti. La fiducia operativa dipende da test locali che usano la telemetria, gli strumenti, i modelli di attacco e i requisiti di approvazione dell'organizzazione.

Una sperimentazione seria dovrebbe includere attività benigne che somigliano a un attacco. Dovrebbe includere evidenze incomplete, timestamp contraddittori, istruzioni dannose all'interno di contenuti recuperati e strumenti non disponibili. La valutazione dovrebbe premiare l'astensione quando la risposta corretta è sconosciuta.

Anche la revisione umana deve essere significativa. Chiedere a un analista sovraccarico di approvare una lunga narrazione generata dall'AI può trasformarsi in un rituale di automazione. Il revisore ha bisogno di evidenze concise, incertezze evidenziate e un registro chiaro di ogni azione proposta.

Le organizzazioni dovrebbero misurare la qualità delle correzioni, non solo la frequenza delle correzioni. Un basso tasso di correzione potrebbe riflettere un'elevata accuratezza. Potrebbe anche significare che gli analisti si fidano troppo facilmente del sistema o non hanno tempo per esaminarne il ragionamento.

Nessun fornitore può risolvere tali questioni con un benchmark generale. Ogni SOC ha una diversa qualità dei dati, diverse priorità aziendali e una diversa tolleranza alle interruzioni. La fiducia deve essere conquistata all'interno dell'esatto workflow in cui il modello opererà.

Cosa Dovrebbero Osservare Ora i Team di Sicurezza

La prossima fase sarà decisa da evidenze operative verificabili, dalla progettazione delle autorizzazioni e dalla capacità di cambiare modelli senza perdere conoscenza della sicurezza.

Il primo segnale è se i fornitori pubblicano risultati di valutazione a livello di workflow. Gli acquirenti hanno bisogno di più che dichiarazioni su un triage più rapido o un ragionamento migliore. Hanno bisogno di definizioni delle attività, requisiti di evidenza, categorie di errore, tassi di astensione e dati sulle correzioni umane.

Valutazioni indipendenti rafforzerebbero la tesi per un'adozione più ampia. I risultati dovrebbero coprire indagini realistiche e includere input avversariali. Se i fornitori continuano a enfatizzare le dimostrazioni senza divulgare i modelli di fallimento, l'argomento a favore dell'uso autonomo si indebolisce.

Il secondo segnale è la progettazione delle autorizzazioni alle azioni. Osservate se i partner di Anthropic e Google espongono controlli granulari per ogni strumento, fonte di dati e azione di risposta. I sistemi solidi separeranno lettura, proposta, approvazione ed esecuzione.

L'approvazione dovrebbe dipendere dalla conseguenza. Redigere una query e isolare un server di produzione non dovrebbero mai condividere lo stesso percorso di autorizzazione. I fornitori che rendono visibili questi confini offriranno ai team di sicurezza una base migliore per un'adozione controllata.

Il terzo segnale è la portabilità dei modelli. Le organizzazioni di sicurezza dovrebbero verificare se le piattaforme preservano rilevamenti, evidenze, cronologia dei casi, prompt e valutazioni in formati che sopravvivono a un cambio di modello. Un modello di ragionamento non dovrebbe diventare l'unico archivio della conoscenza operativa.

La portabilità determinerà se la competizione tra Anthropic e Google favorirà gli acquirenti o creerà un'altra forma di lock-in. Se i team possono testare Claude e Gemini sugli stessi casi, la concorrenza può migliorare prestazioni e responsabilità. Se ogni modello richiede uno stack isolato di dati e workflow, i costi di passaggio aumenteranno.

I responsabili della sicurezza non devono rifiutare l'AI nell'attesa di garanzie perfette. Possono iniziare con attività ristrette che producono output sottoponibili a revisione, come riepiloghi degli incidenti, bozze di query, cronologie delle evidenze e suggerimenti di rilevamento. Ogni workflow dovrebbe avere un responsabile definito, un set di test, un confine di autorizzazione e un percorso di rollback.

La domanda più difficile è se un assistente efficace debba ricevere maggiore autonomia. Tale decisione dovrebbe seguire evidenze misurate, non l'entusiasmo dei dirigenti o l'urgenza dei fornitori. Un modello che fa risparmiare tempo agli analisti ha dimostrato utilità. Non ha dimostrato automaticamente autorità.

Claude ha posto nel SOC quando aiuta gli analisti a ragionare su evidenze governate. L'approccio integrato di Google ha posto quando i suoi agenti restano vincolati da controlli trasparenti e registri sottoponibili a revisione. Nessuno dei due dovrebbe essere messo al comando solo perché l'interfaccia sembra sicura.

La prossima mossa per i team di sicurezza è concreta: scegliere un workflow ad alto volume e basse conseguenze e testarlo rispetto a casi storici. Registrare affermazioni non supportate, evidenze mancate, correzioni degli analisti e tempo risparmiato. Poi chiedersi se il risultato migliora l'indagine senza nascondere come si è giunti alla conclusione.