F5 Workforce AI Security porta il controllo degli agenti nel percorso di rete
F5 Workforce AI Security entrerà in disponibilità generale nell'ottobre 2026, estendendo la piattaforma di sicurezza di F5 dalle applicazioni AI alle attività di dipendenti e agenti. Il prodotto affronta un conflitto crescente nelle imprese. I lavoratori vogliono strumenti AI capaci di agire, mentre i team di sicurezza necessitano di controlli prima che tali azioni raggiungano sistemi sensibili.
F5 ha annunciato l'offerta il 9 settembre come livello agentless per rilevare l'uso dell'AI e applicare policy alle interazioni della forza lavoro. Secondo l'annuncio dedicato alla forza lavoro dell'azienda, tali interazioni includono browser, strumenti per sviluppatori, agenti di coding, interfacce a riga di comando e client Model Context Protocol.
Il cambiamento rilevante non è un'altra dashboard che conta le visite a ChatGPT. F5 intende ispezionare ciò che un agente AI si propone di fare, associare la richiesta a un'identità e intervenire prima dell'esecuzione.
Questo approccio contrappone l'applicazione delle policy basata sulla rete ai controlli legati a endpoint, browser o singole applicazioni AI. Solleva inoltre interrogativi complessi su copertura del traffico, sessioni crittografate, privacy dei dipendenti e affidabilità della classificazione automatizzata dell'intento.
Palo Alto Networks, Microsoft, Zscaler, Netskope e altri fornitori di sicurezza offrono già controlli per l'uso dell'AI da parte della forza lavoro. La scommessa di F5 è più circoscritta e più ambiziosa. L'azienda sostiene che il percorso di rete possa diventare un punto di applicazione coerente delle policy, man mano che l'attività AI va oltre i prompt e si sposta verso il lavoro guidato da strumenti.
F5 Workforce AI Security estende il controllo oltre i prompt
F5 considera la chiamata a uno strumento da parte di un agente come un evento di sicurezza, non semplicemente come una conversazione con l'AI.
I tradizionali controlli AI per la forza lavoro iniziano generalmente dalla scoperta delle applicazioni. I team di sicurezza identificano quali servizi di AI generativa vengono utilizzati dai dipendenti, quindi limitano caricamenti, prompt o applicazioni non approvate.
Questi controlli restano importanti. Un dipendente può esporre codice sorgente, dati dei clienti, credenziali o documenti legali inserendoli in un modello pubblico. Le indicazioni di Microsoft sui controlli dei dati sensibili raccomandano di analizzare prompt, output, operazioni di memoria, contesto recuperato e risultati degli strumenti.
Gli agenti ampliano il problema perché possono agire dopo aver ricevuto una risposta. Un agente di coding può modificare un repository, invocare uno strumento di deployment o eseguire comandi. Un assistente potrebbe recuperare documenti, aggiornare un record cliente o inviare un messaggio.
Tali azioni ereditano spesso le autorizzazioni dell'utente umano. F5 descrive questa condizione come autorità presa in prestito. L'agente non necessita di un account completamente indipendente per creare rischi se opera tramite credenziali già concesse a un dipendente.
F5 Workforce AI Security è progettato per identificare sia la persona sia l'agente coinvolti in un'interazione. Può quindi classificare l'intento della richiesta, valutare il rischio di accesso e applicare una policy prima che venga eseguita una chiamata a uno strumento supportato.
L'azienda afferma che le policy possono consentire, bloccare o modificare le azioni. Possono inoltre considerare l'esposizione di dati sensibili e l'identità associata a una richiesta.
Model Context Protocol, o MCP, è un protocollo aperto che connette applicazioni AI a strumenti e fonti di dati. F5 afferma che il suo prodotto può ispezionare e classificare le chiamate agli strumenti tra server MCP e strumenti per agenti supportati.
Questa distinzione porta la sicurezza della forza lavoro oltre il controllo di quale chatbot apra un dipendente. Un agente autorizzato potrebbe comunque tentare un'azione che esula dal compito immediato dell'utente o dalla policy aziendale.
F5 prevede inoltre controlli su scelta del servizio, tipo di licenza, caricamenti di file e policy sui dati. Un'organizzazione potrebbe consentire un account enterprise approvato, limitando al contempo una versione consumer dello stesso servizio.
Il prodotto si colloca nella più ampia F5 AI Security Platform. F5 ha introdotto tale piattaforma nel giugno 2026 per la scoperta, la governance, i test e la protezione runtime dell'AI.
Ad agosto, l'azienda ha aggiunto funzionalità AI Gateway, incluso un MCP Gateway. Workforce AI Security ora estende la piattaforma alle attività dei dipendenti e agli agenti che operano con autorizzazioni dei dipendenti.
La sequenza è rilevante. I test di red teaming possono esporre debolezze prima del deployment, mentre le protezioni runtime tutelano le applicazioni AI in produzione. I controlli della forza lavoro affrontano il rischio separato che si crea quando i dipendenti adottano strumenti esterni o delegano compiti agli agenti.
F5 punta quindi a una sola struttura di policy per sviluppo, deployment e utilizzo dell'AI. Il fatto che i clienti sperimentino effettivamente questa unità dipenderà dalla qualità dell'integrazione e dalla copertura del traffico, non solo dalla mappa dei prodotti.
Il prodotto è previsto in disponibilità generale a ottobre. Finché non inizieranno i deployment, la precisione dell'applicazione delle policy e il carico operativo resteranno affermazioni dell'azienda, anziché risultati convalidati indipendentemente.
Perché le azioni degli agenti creano un problema di sicurezza diverso
Un agente AI può trasformare un prompt imprudente in un'operazione dalle conseguenze concrete sui sistemi reali.
Un dipendente che incolla testo riservato in un chatbot crea un problema di governance dei dati. Un agente che usa credenziali per modificare un'impostazione di produzione crea anche un problema di autorizzazione.
Questa distinzione spiega perché F5 pone l'accento sulle azioni e non solo sui prompt. Il perimetro di sicurezza si sposta ogni volta che un sistema AI può chiamare strumenti, modificare dati o comunicare all'esterno.
Il State of Application Strategy Report 2026 di F5 ha rilevato che il 66 percento delle organizzazioni intervistate consente all'AI di regolare automaticamente policy o configurazioni. F5 ha citato questa percentuale nel suo annuncio, quindi va considerata una ricerca sponsorizzata dall'azienda.
Anche con questa precisazione, la questione di fondo è chiara. Le imprese stanno spostando l'AI da interfacce consultive a workflow con accesso in scrittura.
L'agente potrebbe ricevere un'autorizzazione ampia perché il dipendente la possiede già. Tuttavia, l'autorità di un utente non dimostra che ogni azione generata dall'agente rifletta l'intento informato dell'utente.
Questo crea un divario tra autenticazione e autorizzazione. L'autenticazione stabilisce chi ha avviato una sessione. L'autorizzazione deve decidere se una specifica azione sia appropriata nel contesto attuale.
I team di sicurezza devono inoltre affrontare la prompt injection indiretta. Un attaccante può inserire istruzioni dannose in contenuti che un agente legge successivamente, come email, siti web, documenti o repository di codice.
L'agente può interpretare quel contenuto ostile come un'istruzione e compiere un'azione indesiderata. La ricerca di NIST sulla sicurezza degli agenti descrive il furto di dati e l'esecuzione di codice dannoso come possibili conseguenze.
Un livello di policy di rete può aggiungere un ulteriore punto di controllo prima che l'azione risultante raggiunga uno strumento. Non elimina il ragionamento compromesso all'interno dell'agente, ma può limitarne l'esito.
F5 afferma che i suoi controlli utilizzano contesto quali identità, intento, rischio e dati sensibili. Questa combinazione è necessaria perché né una semplice blocklist delle applicazioni né un elenco statico di autorizzazioni coglie l'intera situazione.
Si consideri uno sviluppatore che utilizza un agente di coding approvato. Leggere un file di dipendenze pubblico potrebbe essere un'attività di routine. Caricare codice proprietario su un modello esterno potrebbe violare la policy.
Aprire una issue interna potrebbe essere accettabile. Modificare un deployment di produzione potrebbe richiedere un'approvazione separata o un'identità di servizio con privilegi più limitati.
La decisione di sicurezza dipende quindi da chi agisce, quali dati sono coinvolti, quale strumento è preso di mira e quale operazione viene richiesta. Può dipendere anche dall'ambiente e dall'orario.
Questo è il valore pratico dell'applicazione delle policy basata sull'intento. Promette più contesto di una regola che blocca un intero servizio o consente ogni interazione.
Tuttavia, anche l'“intento” è un input complesso. Un classificatore deve trasformare richieste ambigue in linguaggio naturale e chiamate tecniche agli strumenti in categorie di policy affidabili.
Un blocco errato può interrompere il lavoro legittimo. Un'approvazione errata può esporre dati o consentire un'operazione dannosa. Gli ambienti ad alto rischio necessiteranno di controlli deterministici sulle azioni più rilevanti.
Il lavoro di NIST sull'identità degli agenti enfatizza identificazione, autorizzazione, auditing e non ripudio. Si chiede inoltre come le organizzazioni possano mitigare la prompt injection.
Questi requisiti vanno oltre l'ispezione del traffico. Le imprese necessitano di identità chiare per gli agenti, autorizzazioni limitate, log persistenti e responsabilità per ogni workflow automatizzato.
F5 Workforce AI Security può diventare un livello di applicazione delle policy in tale sistema. Non dovrebbe diventare l'unica fonte di fiducia.
La competizione principale è tra applicazione delle policy in rete e controllo specifico degli strumenti
F5 scommette che la rete offra un punto di controllo più duraturo rispetto a qualsiasi singolo modello, browser o integrazione endpoint.
I servizi AI cambiano rapidamente. I dipendenti possono passare da un chatbot familiare a un'estensione del browser, un assistente di coding, un client da riga di comando o un modello ospitato privatamente.
Un controllo di sicurezza specifico per un'applicazione deve riconoscere ciascun servizio e comprenderne l'interfaccia. Un prodotto endpoint necessita di deployment, manutenzione e autorizzazioni su ogni dispositivo gestito.
F5 propone di applicare controlli nel punto in cui prompt, risposte e azioni degli agenti attraversano l'infrastruttura aziendale. L'azienda afferma che questo approccio è indipendente da uno specifico fornitore di modelli o applicazioni.
Il prodotto può rilevare servizi AI su browser e strumenti per sviluppatori. F5 afferma inoltre di supportare strumenti sviluppati internamente che accedono ad API di modelli pubblici.
Secondo F5, l'offerta non richiede un ulteriore client endpoint. Questa formulazione è importante. Significa che i clienti potrebbero evitare di aggiungere un nuovo client, non che il prodotto non richieda attività di deployment.
I clienti devono comunque predisporre il posizionamento in rete, l'integrazione delle identità, la configurazione delle policy, il logging e le connessioni con il proprio ambiente di sicurezza esistente. La copertura dipende inoltre da quale traffico l'organizzazione può osservare.
La pagina del prodotto F5 descrive la scoperta passiva tramite traffico di rete speculare. Afferma che l'analisi out-of-band non introduce latenza perché l'ispezione avviene al di fuori del percorso di produzione.
La stessa pagina descrive controlli adattivi che bloccano, reindirizzano o modificano l'attività. L'annuncio afferma inoltre che le policy operano nel percorso di interazione.
Queste funzioni rappresentano modalità operative diverse. La scoperta passiva può osservare senza ritardare il traffico. L'applicazione attiva delle policy deve influenzare la richiesta prima dell'esecuzione.
Le imprese dovrebbero chiedere quali componenti funzionano passivamente e quali sono inseriti inline. Dovrebbero inoltre confermare cosa accade quando i servizi di ispezione non funzionano o non riescono a classificare una richiesta.
I concorrenti occupano già alcune parti di questo mercato. Palo Alto Networks offre controlli di accesso all'AI per rilevare applicazioni di AI generativa e prevenire la perdita di dati sensibili tramite prompt e caricamenti.
Microsoft Purview può rilevare l'attività AI, applicare policy di prevenzione della perdita dei dati e mostrare gli eventi di AI generativa nei log di audit. Zscaler afferma che AI Guard for Users ispeziona prompt e risposte dei dipendenti verso servizi AI pubblici.
Netskope combina scoperta delle applicazioni, controlli sui dati e infrastruttura security service edge. Questi fornitori vendono già ai team aziendali responsabili della rete e della sicurezza dei dati.
F5 deve quindi dimostrare che il controllo delle azioni degli agenti offre un vantaggio operativo significativo. La semplice individuazione della shadow AI non creerà una differenziazione sufficiente.
La sua piattaforma più ampia potrebbe essere d’aiuto. Secondo le capacità di prodotto dell’azienda, i dati di discovery possono alimentare i test F5 AI Red Team e le policy runtime di F5 AI Guardrails.
Questo ciclo di feedback è interessante in teoria. Il comportamento osservato della forza lavoro può identificare casi d’uso rischiosi, che i team di sicurezza possono testare e governare in modo più consapevole.
Tuttavia, i clienti raramente standardizzano ogni funzione di sicurezza su un’unica piattaforma. Molti utilizzeranno F5 accanto a provider di identità, strumenti endpoint, cloud access broker, prodotti per la sicurezza dei dati e controlli nativi dei modelli.
L’interoperabilità conterà più di una console unica. I team di sicurezza hanno bisogno che eventi e decisioni di policy transitino senza attriti tra i sistemi esistenti.
L’approccio di rete presenta anche punti ciechi naturali. Connessioni dirette dei dispositivi, reti non gestite, crittografia end-to-end, modelli locali e strumenti non supportati possono limitare il contesto osservabile.
F5 non ha stabilito pubblicamente che ogni percorso di questo tipo sia coperto. Prima di accettare un’affermazione di visibilità completa, gli acquirenti dovrebbero mappare i flussi di lavoro reali dei dipendenti.
La versione più solida dell’argomentazione di F5 non è che la rete vede tutto. È che un punto di controllo di rete può offrire un’applicazione coerente delle policy su molti strumenti altrimenti frammentati.
Questa proposta è verificabile. I clienti possono confrontare l’attività rilevata con la telemetria endpoint, i log SaaS, i record di identità e le distribuzioni di agenti note.
Se i record coincidono, l’applicazione delle policy di rete diventa un utile livello comune. Se permangono lacune sostanziali, la piattaforma richiederà controlli complementari.
L’ampia visibilità comporta compromessi tra privacy e accuratezza
L’ispezione dell’attività AI può ridurre il rischio per la sicurezza, creando al contempo una registrazione sensibile di idee, errori e abitudini di lavoro dei dipendenti.
F5 afferma che la sua piattaforma può registrare le interazioni AI e classificare l’intento aziendale. I suoi materiali di prodotto citano esempi quali la sintesi e la generazione di codice.
Queste informazioni possono aiutare i team di sicurezza a identificare schemi rischiosi. Possono anche esporre conversazioni riservate, strategie in bozza, questioni relative al personale, domande di ricerca e segnali sulle prestazioni individuali.
Un prompt raramente è solo un altro evento di rete. Può contenere il ragionamento dell’utente, le sue incertezze o un contesto dettagliato tratto dal lavoro interno.
Le risposte possono essere altrettanto sensibili. Un sistema AI può combinare l’input dell’utente con dati aziendali recuperati, memoria privata o contenuti provenienti da strumenti connessi.
Le organizzazioni hanno quindi bisogno di controlli per il sistema di sicurezza stesso. L’accesso ai log di prompt e risposte dovrebbe seguire ruoli rigorosi, limiti di conservazione e requisiti di audit.
I team legali, privacy, sicurezza e relazioni con i dipendenti dovrebbero definire un monitoraggio accettabile prima di un’implementazione su larga scala. Anche le normative regionali sul lavoro e sulla privacy possono influire sulle modalità di introduzione del monitoraggio.
F5 afferma che le tracce di audit possono catturare il percorso di una richiesta AI, della risposta e dell’intento dell’utente. Le aziende dovrebbero determinare quali campi vengono conservati e se i contenuti sensibili possano essere ridotti al minimo.
Dovrebbero inoltre chiedere se la redazione avviene prima della registrazione o solo prima che i dati raggiungano un modello esterno. L’ordine cambia l’esposizione creata dalla piattaforma di sicurezza.
L’accuratezza della classificazione presenta un ulteriore compromesso. Una richiesta etichettata come “sintesi” potrebbe contenere record regolamentati. Un’azione di coding potrebbe in realtà modificare l’infrastruttura tramite uno script generato.
L’intento in linguaggio naturale può integrare fatti tecnici espliciti, ma non dovrebbe sostituirli. Destinazione, tipo di operazione, identità, sensibilità della risorsa e ambito delle autorizzazioni forniscono segnali più solidi.
Le azioni ad alto impatto meritano policy fail-closed o requisiti di approvazione diretta. Le azioni a basso rischio possono tollerare classificazioni più flessibili e orientamento.
Il sistema deve anche distinguere gli utenti dagli agenti che agiscono per loro conto. Token condivisi o sessioni browser ereditate possono rendere difficile l’attribuzione.
NIST ha avvertito che gli agenti ricevono spesso accesso a nuovi strumenti e dati attraverso le credenziali umane. Le sue linee guida sull’identità dell’agosto 2026 evidenziano inoltre l’affaticamento da consenso dovuto a ripetute richieste di approvazione.
Troppi prompt possono addestrare gli utenti ad approvare azioni in modo riflessivo. Troppi pochi prompt possono consentire a un agente di oltrepassare confini importanti senza una revisione significativa.
Il motore di policy di F5 deve aiutare i clienti a scegliere dove collocare l’attrito. La risposta varierà in base all’azione, alla risorsa e alla funzione aziendale.
Un assistente commerciale che redige un’email comporta un rischio diverso da un agente di coding che modifica l’infrastruttura di produzione. Un riepilogo locale ha implicazioni diverse da un caricamento esterno.
I team necessitano inoltre di un processo per contestare decisioni di policy errate. Senza motivazioni trasparenti, gli sviluppatori potrebbero aggirare i controlli o tornare a strumenti non gestiti.
È qui che una base di conoscenza AI ricercabile può supportare la governance. I dipendenti hanno bisogno di registri chiari degli strumenti approvati, delle regole sui dati e dei percorsi di escalation.
La documentazione da sola non può applicare le policy. Tuttavia, l’applicazione delle policy senza indicazioni comprensibili spesso spinge l’adozione verso canali meno visibili.
Il posizionamento agentless di F5 riduce una fonte di attrito nell’implementazione. Non elimina il lavoro organizzativo necessario per classificare i dati, assegnare responsabilità e definire azioni consentite.
Il rilascio di ottobre dovrà mostrare come questi controlli si comportano sotto la normale pressione operativa. Una valutazione utile dovrebbe includere falsi positivi, azioni mancate, latenza delle policy e carico di lavoro degli amministratori.
I team di sicurezza dovrebbero anche testare prompt avversari, non soltanto flussi di lavoro normali. Un prodotto di controllo degli agenti deve gestire i tentativi di mascherare l’intento o distribuire attività rischiose su più chiamate.
Nessun guardrail fisso può garantire una protezione permanente contro aggressori adattivi. L’applicazione delle policy di rete dovrebbe partecipare a test continui, monitoraggio e aggiornamenti delle policy.
Tre segnali mostreranno se la scommessa di F5 funziona
Il valore del prodotto sarà determinato da una copertura misurata, controlli sugli agenti applicabili e integrazioni che resistono alla reale complessità aziendale.
Il primo segnale è la prova dell’implementazione dopo ottobre 2026. F5 dovrebbe pubblicare dettagli precisi sui browser supportati, strumenti a riga di comando, framework di agenti, client MCP e configurazioni di rete.
Un lungo elenco di compatibilità non sarà sufficiente. I clienti devono sapere quali flussi di lavoro supportano solo la discovery e quali consentono l’applicazione delle policy prima dell’esecuzione.
Dovrebbero confrontare l’inventario di F5 con la telemetria endpoint, i log di identità, i record API e i sondaggi tra i dipendenti. Differenze non spiegate riveleranno punti ciechi.
Questa evidenza rafforzerà la tesi di F5 se una singola implementazione basata sulla rete identifica attività su molti strumenti con un basso sovraccarico operativo. Grandi lacune di copertura la indeboliranno.
Il secondo segnale è la prova che i controlli sulle azioni degli agenti funzionano in condizioni avverse. Ciò significa testare più delle richieste evidenti di eliminare file o esportare record.
Le valutazioni dovrebbero includere prompt injection indiretta, richieste ambigue, chiamate a strumenti annidate, credenziali riutilizzate e azioni distribuite su più passaggi.
I clienti dovrebbero misurare sia le azioni dannose bloccate sia le azioni legittime interrotte. Un prodotto che blocca tutto è sicuro solo nel senso più ristretto.
F5 offre già funzionalità di AI red teaming, quindi gli acquirenti dovrebbero chiedere se le policy Workforce AI Security possano essere testate rispetto a scenari di attacco riproducibili. I risultati dovrebbero orientare le modifiche alle policy.
Una validazione indipendente avrebbe più peso degli script dimostrativi. La documentazione tecnica dovrebbe spiegare i limiti della classificazione e il comportamento in caso di errore senza esporre logiche di rilevamento sensibili.
Il terzo segnale è la risposta competitiva. Palo Alto Networks, Microsoft, Zscaler, Netskope e i fornitori di identità dispongono di punti di controllo adiacenti e relazioni consolidate con i clienti.
Se queste aziende estenderanno l’applicazione delle policy sulle chiamate agli strumenti e le funzionalità di identità degli agenti, la differenziazione di F5 si ridurrà. Ciò confermerebbe anche che la sicurezza AI della forza lavoro sta andando oltre la governance dei chatbot.
Se invece i clienti consolideranno attorno a permessi nativi dei modelli o controlli incentrati sull’identità, l’ispezione di rete potrebbe rimanere un livello di supporto. F5 competerebbe allora sull’integrazione e sulla praticità operativa.
L’esito più probabile è una sicurezza a livelli. I fornitori di modelli limiteranno l’uso degli strumenti, i sistemi di identità limiteranno l’autorità e i prodotti endpoint osserveranno l’attività dei dispositivi.
I controlli di rete possono valutare flussi di dati e operazioni tra diversi fornitori. I guardrail runtime possono monitorare le applicazioni sviluppate internamente dalle aziende.
La domanda centrale non è quale livello vinca. È se la policy rimanga coerente mentre un’azione passa tra questi livelli.
Per gli acquirenti aziendali, il passo immediato è inventariare i flussi di lavoro AI reali prima di scegliere un prodotto di controllo. Includete servizi approvati, strumenti shadow, agenti di coding, modelli privati e connessioni MCP.
Quindi identificate quali flussi di lavoro possono leggere dati sensibili, comunicare esternamente o modificare lo stato dei sistemi. Queste capacità meritano le identità e i controlli di policy più rigorosi.
F5 Workforce AI Security arriva in un momento utile perché l’adozione degli agenti sta rivelando i limiti delle blocklist applicative. La sua strategia di rete offre un plausibile punto di controllo comune.
La strategia resta non dimostrata su scala. F5 deve mostrare di poter osservare un contesto sufficiente, classificare accuratamente le azioni e applicare le policy senza rendere intollerabile un uso produttivo dell’AI.
I responsabili della sicurezza dovrebbero usare il lancio di ottobre come inizio di una valutazione, non come sua conclusione. Quali azioni degli agenti la piattaforma può effettivamente vedere, spiegare e fermare nel vostro ambiente?
