F5 Workforce AI Security porta la governance dell'AI nel percorso di rete

F5 Workforce AI Security aggiungerà controlli senza agent per l'uso dell'AI da parte dei dipendenti e per le azioni degli agenti, nonostante la maggior parte della governance sul posto di lavoro continui a concentrarsi sui prompt nelle chat. Annunciato il 9 settembre 2026, il prodotto dovrebbe essere disponibile al pubblico a ottobre. Rappresenta il tentativo più esplicito di F5 di governare sia ciò che i lavoratori inviano all'AI sia ciò che l'AI fa con la loro autorità.

Il problema non è più limitato ai dipendenti che incollano testo riservato in un chatbot non approvato. Gli agenti di coding e gli assistenti AI possono richiamare strumenti, accedere a sistemi interni, modificare record e agire tramite le credenziali degli utenti. F5 vuole che i team di sicurezza ispezionino tali interazioni nel percorso di rete prima che venga eseguita una richiesta o un'azione non sicura.

Questo approccio mette F5 in competizione con fornitori di sicurezza affermati come Check Point e Netskope, che presentano anch'essi i controlli di rete come la risposta allo shadow AI. Il test più difficile riguarda visibilità e contesto. Un prodotto di rete deve riconoscere identità, intenzioni e chiamate agli strumenti senza diventare un'ulteriore fonte di attrito, sorveglianza o falsi allarmi.

F5 Workforce AI Security estende il controllo alle azioni degli agenti

Il cambiamento significativo è la decisione di F5 di trattare le azioni degli agenti come attività di rete soggette a governance, non semplicemente come comportamento applicativo.

Secondo l'annuncio del prodotto, F5 Workforce AI Security scoprirà i servizi AI utilizzati tramite browser e strumenti per sviluppatori. Gli amministratori potranno applicare policy basate sul servizio, sul tipo di licenza, sui file caricati e sulle regole relative ai dati.

Il prodotto è inoltre progettato per attribuire le interazioni a utenti e agenti. Registrerà contesto come l'intento, il rischio valutato e la decisione di policy applicata a ciascuna interazione. Questi record sono pensati per supportare applicazione delle policy, indagini e audit di conformità.

La funzionalità più rilevante riguarda le chiamate agli strumenti. F5 afferma che il prodotto ispezionerà le chiamate attraverso server Model Context Protocol e strumenti per agenti supportati prima dell'esecuzione. MCP è un protocollo che consente alle applicazioni AI di connettersi a strumenti, sistemi e dati attraverso un'interfaccia comune.

Una policy potrebbe consentire, bloccare o modificare un'azione in base all'identità, al rischio associato ai permessi o all'esposizione di dati sensibili. Questo va oltre il rilevamento della visita di un dipendente a un sito web AI. Introduce un punto di controllo tra la richiesta di un agente e il sistema che eseguirebbe l'azione richiesta.

F5 afferma che i controlli copriranno browser, interfacce a riga di comando, agenti di coding, client MCP, harness per agenti e strumenti sviluppati internamente che utilizzano API pubbliche dei modelli. L'azienda prevede di integrare l'applicazione delle policy con gli ambienti secure access service edge esistenti, comunemente chiamati SASE.

Il deployment proposto non richiede un altro client endpoint. F5 colloca invece l'applicazione delle policy dove le interazioni di rete pertinenti transitano attraverso la propria infrastruttura. La scoperta passiva può analizzare il traffico mirrorato al di fuori del percorso di produzione, mentre le policy attive operano inline quando è richiesto un intervento.

Questa distinzione è importante per i team di sicurezza che già gestiscono ambienti endpoint affollati. Installare un'altra estensione del browser o un agente locale può creare lavoro di compatibilità, ritardi nel rollout e copertura disomogenea. Un livello basato sulla rete promette una distribuzione più ampia attraverso un'infrastruttura che un'organizzazione già controlla.

Tuttavia, la parola “agentless” non significa che il deployment sia privo di requisiti. Le organizzazioni hanno comunque bisogno di visibilità sul traffico, integrazione delle identità, progettazione delle policy, protocolli supportati e punti di applicazione correttamente posizionati. Dispositivi remoti, sessioni crittografate, connessioni private e modelli in esecuzione locale possono complicare tale copertura.

L'annuncio separa inoltre i fatti attuali dalle capacità future. F5 descrive il prodotto come un'offerta in arrivo e il suo elenco di funzionalità usa formulazioni previsionali. Gli acquirenti non possono ancora considerare il rilascio di ottobre come una prova indipendente di copertura, qualità del rilevamento o affidabilità in produzione.

Questo divario definisce la tensione centrale dell'articolo. Il posizionamento nella rete offre a F5 un punto di controllo interessante, ma il valore dipende dalla precisione con cui interpreta interazioni AI in rapida evoluzione.

Perché l'AI dei dipendenti è diventata un problema di identità

La sicurezza dell'AI per la forza lavoro riguarda ora l'autorità delegata, perché un agente può agire attraverso l'accesso di una persona anziché limitarsi a rispondere alla sua domanda.

I controlli tradizionali sullo shadow AI chiedono a quali applicazioni accedono i dipendenti e quali informazioni caricano. Queste domande restano importanti. Non sono più sufficienti quando un assistente può aprire repository, interrogare database, aggiornare ticket o attivare workflow.

F5 descrive questa condizione come AI che opera con autorità presa in prestito. Un agente può utilizzare permessi originariamente concessi a un dipendente, anche quando l'agente non dispone di un'identità distinta e governabile. I team di sicurezza devono quindi stabilire se l'azione rifletta l'intento del dipendente e il suo ruolo autorizzato.

La preoccupazione è già visibile nel lavoro di standardizzazione. Un documento concettuale del NIST del 2026 esamina come le imprese possano identificare gli agenti software e applicare pratiche di autorizzazione consolidate. Il progetto considera inoltre come le organizzazioni dovrebbero collegare le azioni di un agente a persone responsabili.

Questo collegamento diventa difficile quando un utente avvia diversi agenti su più sistemi. Ogni agente potrebbe ereditare credenziali diverse, richiamare strumenti annidati o delegare il lavoro a un altro servizio. Un record di login convenzionale può identificare l'account senza spiegare la catena di azioni risultante.

F5 vuole arricchire quel record con l'intento dell'interazione. Per esempio, la piattaforma potrebbe distinguere la generazione di codice dalla sintesi di documenti o dalle modifiche amministrative. Questo contesto potrebbe aiutare un team di sicurezza a separare una richiesta ordinaria da un uso inatteso di strumenti privilegiati.

La classificazione dell'intento resta un'inferenza, non una garanzia. La stessa richiesta può produrre azioni diverse a seconda del modello, della descrizione dello strumento, del contesto recuperato e dello stato del sistema. Un prompt dall'aspetto innocuo può anche indirizzare un agente verso un'operazione sensibile diversi passaggi più tardi.

Le linee guida OWASP per MCP descrivono rischi che includono tool poisoning, indirect prompt injection e permessi eccessivi. Il tool poisoning nasconde istruzioni dannose nelle descrizioni, nelle definizioni dei parametri o nei contenuti restituiti. Un agente può seguire tali istruzioni anche quando l'utente non ha mai richiesto il comportamento dannoso.

I permessi eccessivi creano un altro problema. Un server MCP potrebbe richiedere un accesso ampio quando sarebbe sufficiente un permesso ristretto di sola lettura. Un agente compromesso può quindi diventare un confused deputy, utilizzando un'autorità legittima per uno scopo non previsto.

Questi rischi spiegano perché i controlli prima dell'esecuzione siano importanti. Bloccare un segreto divulgato dopo che uno strumento ha già modificato un record di produzione offre una protezione limitata. La decisione deve essere presa prima che il sistema accetti l'azione.

F5 cita la propria ricerca State of Application Strategy del 2026 per mostrare quanto rapidamente stia emergendo questo requisito. Il sondaggio F5 riporta che il 66% delle organizzazioni consente all'AI di modificare automaticamente policy o configurazioni.

Questa cifra proviene dalla ricerca interna di F5 e va letta in tale contesto. Non mostra quante organizzazioni concedano un'autonomia ampia né quanto siano maturi i loro controlli. Indica tuttavia che le modifiche avviate dalle macchine sono andate oltre gli esperimenti isolati.

Per gli acquirenti aziendali, l'obiettivo di sicurezza passa quindi dal blocco delle applicazioni alla governance delle azioni delegate. I team di sicurezza hanno bisogno di record che colleghino l'utente, l'agente, lo strumento richiesto, il permesso concesso, la decisione di policy e l'azione risultante.

Questo è rilevante anche per i team che stanno creando una base di conoscenza ricercabile. I sistemi AI possono recuperare un contesto interno utile, pur richiedendo confini rigorosi attorno a credenziali, file riservati e strumenti operativi.

La pressione ricade contemporaneamente sui team di identità, sicurezza e infrastruttura. Nessuno può risolvere il problema da solo quando gli agenti combinano permessi umani, ragionamento del modello, accesso alla rete e strumenti esterni.

Il percorso di rete è il principale vantaggio di F5 e la sua scommessa più grande

F5 scommette che la rete rimanga il punto di applicazione delle policy più coerente, anche mentre l'attività AI si diffonde tra applicazioni, modelli, agenti e strumenti.

Questa tesi deriva dalla posizione consolidata di F5 nella delivery applicativa, nella sicurezza delle API e nella gestione del traffico. Anziché proteggere un singolo chatbot o fornitore di modelli, l'azienda vuole applicare policy nel punto in cui prompt, risposte e richieste di strumenti si muovono tra i sistemi.

La strategia ha iniziato ad assumere una forma più chiara nel 2025. F5 ha completato l'acquisizione di CalypsoAI e ha introdotto AI Guardrails per la protezione runtime e AI Red Team per i test di sicurezza. Questi prodotti affrontano minacce rivolte ai modelli, incluse prompt injection e tentativi di jailbreak.

Nel giugno 2026, F5 ha lanciato la più ampia AI Security Platform e acquisito SurePath AI. SurePath ha contribuito con scoperta basata sulla rete, classificazione dell'intento, rilevamento dello shadow AI e visibilità sulle chiamate agli strumenti degli agenti. F5 ha posizionato tali capacità come livello di scoperta per un ciclo di sicurezza continuo.

Il lancio della piattaforma ha descritto quattro funzioni connesse: governance, scoperta, test di sicurezza e protezione runtime. La scoperta identifica servizi e comportamenti AI attivi. I test individuano le debolezze, mentre i guardrail applicano policy contro tali rischi.

Ad agosto, F5 ha aggiunto un AI Gateway che combina routing dei modelli, controlli MCP e guardrail runtime. Il gateway governa i sistemi che le organizzazioni scelgono intenzionalmente di collocare dietro di esso. Workforce AI Security estende la strategia verso l'attività dei dipendenti che può iniziare al di fuori dei percorsi di sviluppo approvati.

Insieme, questi componenti creano una divisione del lavoro logica. La scoperta per la forza lavoro individua l'uso autorizzato e non autorizzato. Il gateway governa il traffico approvato dei modelli e degli strumenti. I test red-team sondano i sistemi, mentre i guardrail applicano protezioni runtime.

L'argomento principale di F5 è la coerenza architetturale. I controlli operano indipendentemente da uno specifico fornitore di modelli o da una specifica applicazione usata dai dipendenti. Un'organizzazione potrebbe cambiare modelli senza dover ricostruire ogni policy nella console amministrativa di un altro fornitore.

Questa indipendenza può essere importante in ambienti con più modelli. Reparti diversi possono usare assistenti commerciali, modelli privati, servizi di coding e agenti specializzati. Ogni servizio espone log e controlli amministrativi differenti, mentre alcuni offrono un'integrazione aziendale limitata.

Un livello di rete può normalizzare almeno una parte di questa attività frammentata. Può associare il traffico alle identità aziendali, mantenere record centralizzati e applicare un processo decisionale comune. I team delle operazioni di sicurezza possono quindi esportare gli eventi nei sistemi esistenti di monitoraggio e risposta agli incidenti.

Tuttavia, la normalizzazione può rimuovere un utile contesto applicativo. Il controllo nativo di un provider potrebbe comprendere uno spazio di lavoro, un documento o una transazione con maggiore precisione rispetto a un intermediario che osserva il traffico. F5 deve dimostrare che le sue classificazioni mantengono dettagli sufficienti per decisioni significative.

Il traffico crittografato presenta un'altra tensione progettuale. Le applicazioni moderne proteggono le sessioni proprio per impedire agli intermediari di leggere i contenuti. L'ispezione può richiedere certificati gestiti, reindirizzamento del traffico, integrazioni supportate o altre forme di decrittazione controllata.

L'attività locale crea un ulteriore punto cieco. Un agente in esecuzione sul dispositivo di uno sviluppatore potrebbe chiamare un modello o uno strumento locale senza transitare attraverso un percorso aziendale osservabile. Anche connessioni dirette, hotspot personali e dispositivi non gestiti possono aggirare l'infrastruttura prevista.

L'approccio di F5 è più solido quando le organizzazioni instradano già le attività rilevanti attraverso reti controllate o servizi SASE. Risulta meno chiaramente completo quando il lavoro si sposta tra runtime locali, connessioni non gestite e protocolli proprietari crittografati.

La rete è quindi al tempo stesso il vantaggio e la scommessa di F5. L'azienda ha esperienza nell'operare sul percorso del traffico, ma la sicurezza AI richiede una comprensione semantica che va oltre i normali controlli su pacchetti e applicazioni.

Check Point e Netskope competono per lo stesso punto di controllo

F5 entra in una competizione attiva tra fornitori di sicurezza di rete per diventare il livello di policy tra utenti aziendali, servizi AI e agenti autonomi.

Check Point commercializza già controlli AI per la forza lavoro che identificano le applicazioni, ispezionano i prompt, applicano protezioni dei dati e distinguono i servizi approvati. Il suo più recente AI Network Firewall estende lo stesso concetto all'uso dell'AI da parte dei dipendenti, agli agenti e alle applicazioni AI.

Check Point promuove inoltre un'implementazione senza agenti tramite l'infrastruttura firewall esistente. Il suo AI Network Firewall afferma di poter visualizzare e governare il traffico AI senza un'estensione del browser, un client endpoint o un'installazione separata. Ciò si sovrappone direttamente al posizionamento network-first di F5.

Netskope affronta l'opportunità attraverso il security service edge e i controlli di accesso al cloud. La sua piattaforma copre shadow AI, AI aziendale gestita, AI privata e attività degli agenti. Enfatizza la protezione dei dati, la consapevolezza applicativa e l'ispezione inline del traffico cloud.

Un report di Netskope descrive l'evoluzione del mercato come un passaggio dalla scoperta di applicazioni non autorizzate alla governance di transazioni autonome. Identifica inoltre prompt injection, esecuzione di codice dannoso e violazioni delle policy a valle come preoccupazioni in crescita.

Questi concorrenti esercitano pressione su F5 su due fronti. Innanzitutto, le aziende potrebbero preferire estendere un security service edge o una piattaforma firewall già esistente. In secondo luogo, i fornitori incumbent possono includere i controlli AI in accordi di sicurezza più ampi e flussi operativi consolidati.

La risposta di F5 è un collegamento più esplicito tra scoperta, test, guardrail in runtime, policy del gateway e attività della forza lavoro. L'obiettivo è che un'unica piattaforma copra sia i sistemi AI utilizzati dai dipendenti sia le applicazioni AI sviluppate dalle aziende.

Questa ampiezza può essere utile, ma solleva anche interrogativi sull'integrazione. Una piattaforma estesa deve condividere identità, policy, risultati e registri di audit tra i componenti. I nomi dei prodotti presenti in un'unica console non creano automaticamente un sistema di enforcement coerente.

Le acquisizioni di SurePath e CalypsoAI forniscono tecnologie specializzate per la scoperta e la sicurezza dei modelli. F5 deve ancora dimostrare quanto fluidamente tali tecnologie operino con i suoi prodotti gateway e di application delivery. La qualità dell'integrazione conterà più delle dimensioni del portafoglio.

Un'altra distinzione competitiva riguarda la governance a livello di azione. Rilevare che un dipendente utilizza un servizio AI è ormai una capacità di base. La domanda di maggior valore è se un prodotto sia in grado di identificare e controllare la specifica operazione che un agente intende far eseguire a uno strumento.

MCP rende questa opportunità più concreta perché standardizza alcune parti della connessione tra agenti e strumenti. Un gateway può ispezionare strumenti nominati, parametri, identità e regole di policy. Tuttavia, MCP è solo una delle vie di accesso ai sistemi aziendali.

Gli agenti chiamano anche API convenzionali, eseguono comandi, accedono ai browser o interagiscono con connettori proprietari. Un prodotto che governa MCP in modo completo può comunque non rilevare attività significative altrove. Gli acquirenti dovrebbero esaminare la copertura dei flussi di lavoro reali, non soltanto checklist dei protocolli.

La concorrenza ruoterà quindi attorno alla profondità, anziché alle semplici dichiarazioni di visibilità. I team di sicurezza confronteranno client supportati, fedeltà dell'identità, classificazione dei dati, copertura degli strumenti, latenza delle policy, impegno di implementazione e opzioni di esportazione.

Valuteranno anche il modo in cui ciascun prodotto gestisce le eccezioni. Gli sviluppatori necessitano spesso di capacità che le policy aziendali generali vieterebbero. Un sistema praticabile deve supportare autorizzazioni circoscritte e percorsi di approvazione documentati, senza incoraggiare gli utenti ad aggirare i controlli.

La presenza di F5 nell'application delivery potrebbe aprire porte presso i clienti esistenti. Check Point e Netskope dispongono dei propri vantaggi infrastrutturali. Nessun fornitore ha dimostrato, attraverso evidenze pubbliche, che una singola architettura di rete catturi ogni interazione significativa tra la forza lavoro e l'AI.

Questo rende l'approvvigionamento una questione di aderenza al contesto. Il prodotto più efficace sarà quello che governa i reali percorsi di traffico e i flussi di lavoro degli agenti di un'organizzazione, non quello con il linguaggio di categoria più ampio.

La governance senza agenti presenta ancora interrogativi irrisolti

F5 ha annunciato un ambizioso livello di controllo, ma non ha ancora pubblicato le evidenze di produzione necessarie per convalidare le sue affermazioni centrali.

La prima incertezza riguarda la copertura. F5 elenca browser, strumenti da riga di comando, agenti di coding, client MCP e software personalizzato che utilizza API pubbliche dei modelli. Non ha però fornito pubblicamente una matrice di compatibilità dettagliata che mostri quali prodotti, versioni, protocolli e modelli di implementazione ricevano un'ispezione completa.

La seconda incertezza riguarda la qualità della classificazione. Le policy basate sull'intento dipendono dall'interpretazione accurata di un'interazione prima dell'enforcement. I falsi negativi consentono comportamenti rischiosi, mentre i falsi positivi interrompono il lavoro legittimo e riducono la fiducia nel sistema.

La classificazione diventa più difficile nei flussi di lavoro lunghi degli agenti. Una richiesta può iniziare come ricerca ordinaria e in seguito invocare uno strumento privilegiato. Il sistema deve conservare contesto sufficiente per valutare ogni passaggio senza trattare il prompt iniziale come l'intento completo.

La terza incertezza riguarda la modifica. F5 afferma che le policy possono consentire, bloccare o modificare le azioni degli agenti. Modificare una richiesta può essere più sicuro che rifiutare un intero flusso di lavoro, ma può anche cambiarne il significato o generare comportamenti inattesi a valle.

Ad esempio, rimuovere un campo sensibile da una chiamata a uno strumento potrebbe proteggere i dati lasciando però incompleta la transazione. Reindirizzare una richiesta verso un modello approvato potrebbe modificare il contesto disponibile o la qualità dell'output. Gli amministratori necessitano di registri chiari di ogni intervento.

Il quarto problema è la latenza. La scoperta passiva può operare al di fuori del percorso di produzione, ma l'enforcement prima dell'esecuzione deve prendere una decisione tempestiva. Assistenti di coding e agenti interattivi diventano frustranti quando ogni chiamata a uno strumento introduce un ritardo percepibile.

F5 non ha pubblicato misurazioni indipendenti della latenza delle decisioni di policy, del throughput o delle prestazioni con carichi di lavoro complessi degli agenti. Gli acquirenti dovrebbero attendere test in produzione invece di presumere che il posizionamento in rete non comporti costi operativi.

La privacy è un'altra preoccupazione. Un'auditabilità dettagliata può richiedere la registrazione di prompt, risposte, informazioni sui file, identità degli utenti, parametri degli strumenti e risultati delle policy. Tali record possono contenere materiale riservato o regolamentato anche quando l'azione originale viene bloccata.

I team di sicurezza devono definire periodi di conservazione, restrizioni di accesso, regole di redazione, archiviazione regionale e procedure di incidente per gli stessi dati di monitoraggio. Un sistema di visibilità può creare un archivio secondario sensibile se tali controlli restano vaghi.

L'implementazione senza agenti sposta inoltre la responsabilità invece di eliminarla. I team di rete devono instradare correttamente il traffico. I team di identità devono mantenere mappature affidabili. I team di sicurezza devono creare policy, mentre i proprietari delle applicazioni verificano che tali policy preservino il comportamento previsto.

Le organizzazioni dovrebbero mettere in discussione qualsiasi promessa di visibilità istantanea e completa. La copertura dipenderà dall'architettura, dall'accesso gestito, dalla crittografia e dall'integrazione. La domanda rilevante è cosa il prodotto non rilevi nel design effettivo del cliente.

Anche le statistiche e le descrizioni delle funzionalità fornite da F5 richiedono un trattamento prudente. Il dato di adozione del 66% riportato sostiene l'urgenza di controlli automatizzati, ma non convalida il prodotto di F5. La disponibilità delle funzionalità non dimostra accuratezza di rilevamento né una riduzione dei tassi di incidente.

La disponibilità generale segnerà l'inizio di una valutazione significativa, non la sua conclusione. Implementazioni di riferimento, test di terze parti, limitazioni documentate ed evidenze dei clienti determineranno se la piattaforma soddisfa le proprie affermazioni.

Un pilota sensato dovrebbe includere applicazioni di chat approvate, account personali, strumenti di coding, API interne e più server MCP. Dovrebbe testare attività ordinarie insieme a prompt injection, autorizzazioni eccessive, caricamenti di dati sensibili e richieste ambigue agli strumenti.

I team dovrebbero misurare separatamente la copertura e le decisioni errate. Un prodotto può rilevare molti servizi fraintendendone al contempo le interazioni. Può anche classificare correttamente i prompt, pur non rilevando traffico locale o diretto.

Il risultato dovrebbe essere un confine mappato anziché un verdetto binario. Gli acquirenti devono sapere dove F5 offre un controllo affidabile, dove un altro strumento fornisce contesto e dove restano necessarie salvaguardie procedurali.

Tre segnali mostreranno se la strategia di F5 funziona

Il lancio di ottobre, le evidenze a livello di azione e la risposta competitiva riveleranno se F5 ha costruito un vero livello di governance o un'attraente narrativa di piattaforma.

Il primo segnale è il rilascio in disponibilità generale previsto per ottobre 2026. F5 deve fornire documentazione concreta sull'implementazione, elenchi di servizi supportati, esempi di policy, integrazioni di identità e distinzioni chiare tra osservazione passiva ed enforcement inline.

Una matrice di compatibilità dettagliata rafforzerebbe l'ipotesi che il prodotto copra più di dimostrazioni controllate. Documentazione mancante o flussi di lavoro supportati in modo ristretto indebolirebbero l'affermazione di visibilità estesa all'intera azienda.

Il secondo segnale è costituito dalle evidenze derivanti da azioni reali degli agenti. I clienti dovrebbero cercare risultati misurati su chiamate a strumenti MCP, agenti di coding, assistenti browser, client da riga di comando e API proprietarie. Evidenze utili includeranno tassi di rilevamento, decisioni errate, latenza e condizioni di aggiramento.

I case study dovrebbero spiegare cosa F5 ha osservato e quali controlli hanno fermato un'azione. Le affermazioni generiche sulla visibilità avranno meno peso degli esempi che collegano identità, autorizzazioni degli strumenti, dati sensibili e risultati finali delle policy.

Le valutazioni indipendenti sarebbero particolarmente preziose. Il design di F5 appare tecnicamente plausibile, ma le dimostrazioni dell'azienda non possono riprodurre ogni protocollo crittografato, runtime locale o catena di agenti insolita presente nelle grandi imprese.

Il terzo segnale è come risponderanno Check Point, Netskope e gli altri fornitori di sicurezza. I concorrenti possono ampliare i controlli a livello di azione, approfondire il supporto MCP o combinare telemetria browser e di rete. Una rapida risposta equivalente trasformerebbe l'annuncio di F5 in un riferimento di base per l'intera categoria.

Una risposta più lenta suggerirebbe che F5 ha assemblato una combinazione differenziata grazie a SurePath, CalypsoAI e alla propria piattaforma di rete esistente. Migrazioni dei clienti o implementazioni consolidate fornirebbero evidenze più solide rispetto ai soli confronti tra funzionalità.

Le aziende dovrebbero inoltre verificare se i fornitori convergeranno su standard di identità per gli agenti. Identità degli agenti coerenti e autorizzazioni con ambito definito renderebbero le policy di rete più affidabili. Approcci frammentati costringerebbero le piattaforme di sicurezza a dedurre più contesto dal traffico.

F5 Workforce AI Security risponde a un reale passaggio dalle conversazioni con l’AI alle azioni dell’AI. Il suo posizionamento nella rete offre all’azienda una strada credibile verso un’applicazione centralizzata delle policy, soprattutto per le organizzazioni che utilizzano già l’infrastruttura F5.

La questione irrisolta è se questa strada riesca a cogliere contesto sufficiente nei moderni flussi di lavoro degli agenti. I team di sicurezza dovrebbero testare il prodotto rispetto a permessi effettivi, strumenti privati e casi di errore prima di considerare “agentless” equivalente a una copertura completa.

Con l’avvicinarsi di ottobre, gli acquirenti possono prepararsi catalogando il traffico AI, mappando i permessi degli agenti e identificando le azioni che richiedono un’approvazione prima dell’esecuzione. Quali tre flussi di lavoro causerebbero i danni maggiori se un agente utilizzasse in modo errato un’autorità presa in prestito? Partite da lì, quindi valutate se F5 Workforce AI Security sia in grado di vedere, spiegare e bloccare ciascuno di essi senza ostacolare il lavoro ordinario.