La sicurezza ERP fatica a tenere il passo con gli agenti IA

BankInfoSecurity ha portato su Google News un conflitto scomodo: i controlli di sicurezza ERP faticano a tenere il passo mentre gli agenti IA acquisiscono autorità operativa.

La questione non è se un assistente possa riassumere una fattura o rispondere a una domanda sugli acquisti. Il rischio inizia quando un agente può recuperare record, invocare strumenti, modificare transazioni e coordinare azioni tra più sistemi aziendali.

SAP, Oracle, Microsoft e Workday stanno orientando il software ERP verso questo modello. I loro agenti promettono di ridurre il lavoro ripetitivo in finanza, acquisti, risorse umane e catene di fornitura. Tuttavia, i controlli che li circondano ereditano ancora presupposti progettati per dipendenti umani e applicazioni prevedibili.

Questa discrepanza crea il problema di sicurezza centrale. La governance ERP tradizionale chiede quale persona possieda un ruolo e quali transazioni tale ruolo consenta. I sistemi agentici introducono obiettivi delegati, contesto variabile, selezione degli strumenti e passaggi da macchina a macchina.

Un agente può disporre di credenziali valide e compiere comunque un'azione non sicura. Può anche combinare più passaggi singolarmente consentiti in un risultato che nessun amministratore aveva previsto.

I fornitori ERP stanno aggiungendo controlli dell'identità, soglie di approvazione e funzionalità di audit. Queste misure sono importanti, ma non eliminano il conflitto più profondo tra autonomia degli agenti e controlli aziendali deterministici.

L'avvertimento di Google News riguarda l'autorità, non i chatbot

Il cambiamento importante è che gli agenti IA ERP stanno passando dalla lettura dei dati aziendali all'azione su di essi.

Il report sulla sicurezza ERP emerso tramite Google News presenta il problema come una corsa tra l'espansione delle capacità degli agenti e un adeguamento della sicurezza più lento.

Questa impostazione conta perché i sistemi ERP contengono la verità operativa di un'azienda. Conservano istruzioni di pagamento, record dei dipendenti, condizioni dei fornitori, posizioni di magazzino, saldi dei clienti e approvazioni finanziarie.

Un chatbot convenzionale può fornire una risposta errata. Un agente ERP con diritti di esecuzione può trasformare una risposta errata in una scrittura contabile registrata o in una modifica a un fornitore approvata.

L'IA agentica si riferisce a software in grado di interpretare un obiettivo, creare un piano, scegliere strumenti ed eseguire più passaggi con una supervisione limitata. Si differenzia dall'automazione fissa, che segue un percorso predefinito.

Un flusso di lavoro tradizionale potrebbe rifiutare una fattura ogni volta che manca un ordine di acquisto. Un agente può invece indagare sulla discrepanza, recuperare la corrispondenza, confrontare i record di consegna e raccomandare un'eccezione.

Questa flessibilità crea valore perché i processi aziendali reali contengono ambiguità. Tuttavia, indebolisce la prevedibilità da cui dipendono molti controlli di sicurezza esistenti.

I team di sicurezza possono esaminare un flusso di lavoro fisso prima della distribuzione. Sanno quali campi legge, quali chiamate di sistema effettua e quali condizioni attivano un'approvazione.

Un agente può scegliere ogni volta una sequenza diversa. Il suo comportamento può cambiare in base al prompt, agli strumenti disponibili, ai documenti recuperati, alla versione del modello o alla conversazione circostante.

Ciò significa che l'autorizzazione non può fermarsi al login. La sicurezza deve valutare l'identità dell'agente, lo scopo delegato, il contesto attuale, lo strumento selezionato, i dati richiesti e l'effetto previsto.

Il problema diventa più difficile quando un agente attraversa i confini tra applicazioni. Un agente finanziario può consultare email, record degli acquisti, dati dei clienti e un sistema di pagamento prima di completare un'attività.

Ogni connessione amplia la superficie di attacco. Rende inoltre più difficile attribuire la responsabilità quando più componenti contribuiscono a un risultato non sicuro.

I lettori di Google News potrebbero inizialmente interpretare la storia come un altro avvertimento sull'accuratezza dell'IA generativa. Il problema sottostante è più rilevante.

I team di sicurezza ERP devono governare software che si comporta meno come un'applicazione passiva e più come un lavoratore altamente connesso. Tale lavoratore può operare ininterrottamente, alla velocità delle macchine e oltre i confini organizzativi.

Il cambiamento mette sotto pressione i responsabili della sicurezza informatica, gli amministratori ERP, i team di gestione delle identità, i revisori interni e i responsabili dei processi aziendali. Nessuno di questi gruppi può gestire il rischio da solo.

I team di sicurezza comprendono il controllo degli accessi, ma possono non disporre di un contesto di processo dettagliato. I responsabili finanziari comprendono le conseguenze materiali, ma potrebbero non vedere ogni dipendenza tecnica.

Gli amministratori ERP comprendono ruoli e transazioni. Potrebbero non controllare modelli esterni, framework per agenti o strumenti di terze parti collegati al flusso di lavoro.

La sfida immediata è quindi organizzativa oltre che tecnica. Le aziende hanno bisogno di un unico modello di controllo che segua un agente dall'istruzione iniziale a ogni azione risultante.

Gli agenti IA ERP infrangono il modello di identità umana

Un'identità valida non dimostra più che un'azione sia appropriata quando il software può reinterpretare gli obiettivi e selezionare il proprio percorso di esecuzione.

I controlli ERP si sono tradizionalmente concentrati su utenti nominativi, ruoli assegnati e separazione dei compiti. La separazione dei compiti impedisce a una persona di controllare fasi incompatibili di un processo sensibile.

Ad esempio, il dipendente che crea un fornitore non dovrebbe approvare autonomamente i pagamenti a tale fornitore. La regola limita le frodi e riduce l'impatto di credenziali compromesse.

Gli agenti complicano questo modello perché l'autorità può passare attraverso più livelli. Una persona istruisce un agente, l'agente chiama un altro agente e quest'ultimo invoca un'applicazione aziendale.

Il sistema finale può vedere soltanto un'identità di servizio autenticata. Potrebbe non ricevere l'utente originario, lo scopo, le prove o i limiti associati alla richiesta.

Questo crea un problema di catena di delega. Ogni sistema riconosce il proprio chiamante immediato, mentre la fonte completa e l'intenzione dell'azione diventano più difficili da ricostruire.

Le credenziali condivise degli agenti aggravano il problema. Se più flussi di lavoro utilizzano un unico account di servizio, gli investigatori potrebbero faticare a distinguere l'automazione legittima dall'uso improprio.

Le credenziali persistenti consentono inoltre all'autorità di sopravvivere al suo scopo originario. Un agente creato per un progetto temporaneo di riconciliazione potrebbe mantenere l'accesso dopo la conclusione di quel lavoro.

Le revisioni degli accessi umani operano in genere in base a eventi occupazionali e ruoli fissi. Gli agenti possono comparire, cambiare, duplicarsi e scomparire molto più rapidamente dei dipendenti.

Possono inoltre essere assemblati al di fuori dei processi formali di sviluppo. Un team aziendale può collegare un modello a uno strumento approvato senza riconoscere che la combinazione crea una nuova identità privilegiata.

Il framework di sicurezza agentica di OWASP identifica l'abuso di identità e privilegi tra i suoi rischi principali. Evidenzia inoltre il dirottamento degli obiettivi, l'uso improprio degli strumenti e le debolezze della catena di fornitura agentica.

Il dirottamento degli obiettivi si verifica quando contenuti dannosi o non attendibili modificano ciò che un agente cerca di realizzare. L'istruzione dannosa può trovarsi all'interno di un documento, messaggio, pagina web o risposta di uno strumento.

Questo è più pericoloso all'interno dell'ERP che in un assistente autonomo. L'agente può già disporre dell'accesso a record riservati e funzioni transazionali.

Si consideri un agente per gli acquisti che legge le email dei fornitori. Un messaggio compromesso potrebbe istruire il modello a dare priorità a un conto bancario controllato da un attaccante o a divulgare dati interni sugli acquisti.

La richiesta potrebbe entrare in conflitto con l'obiettivo originale dell'utente. Tuttavia, l'agente potrebbe trattare il testo incorporato come contesto operativo pertinente, a meno che le salvaguardie non separino i dati dalle istruzioni.

Il principio del privilegio minimo resta necessario, ma la sua implementazione deve diventare più precisa. Un agente dovrebbe ricevere solo i permessi richiesti per uno scopo e un periodo limitato.

Le linee guida di Oracle per operazioni sicure rendono esplicita questa distinzione. Un agente di analisi non necessita di diritti di approvazione degli acquisti solo perché entrambi partecipano a un unico flusso di lavoro.

Il principio suona familiare, ma gli agenti rendono l'applicazione più difficile. I loro piani possono evolvere dopo l'avvio di un'attività e possono richiedere strumenti aggiuntivi durante l'esecuzione.

I ruoli statici non possono esprimere pienamente condizioni quali scopo, valore della transazione, sensibilità dei dati, livello di confidenza o il fatto che un altro agente abbia avviato la richiesta.

Le aziende necessitano quindi di controlli delle policy nel momento dell'azione. Tali controlli dovrebbero valutare sia l'operazione richiesta sia il contesto che la circonda.

Le azioni ad alto impatto richiedono anche una prova più solida dell'intento umano. Un pulsante di conferma non è sufficiente se il revisore vede soltanto un riepilogo rifinito prodotto dallo stesso agente.

Il revisore ha bisogno delle prove originali, delle modifiche proposte, delle eccezioni alle policy e dell'effetto aziendale atteso. Altrimenti, la supervisione umana diventa cerimoniale.

Il vero compromesso è tra autonomia e controllo

Ogni aumento dell'autonomia degli agenti accresce l'onere su identità, applicazione delle policy, osservabilità e ripristino.

Gli agenti IA ERP diventano utili quando possono gestire le eccezioni. Tuttavia, le eccezioni sono proprio il punto in cui i controlli deterministici offrono la minore copertura.

Un'automazione fissa segue percorsi definiti in anticipo dagli sviluppatori. Un agente interpreta informazioni incomplete e decide quale percorso sembri appropriato.

Questa distinzione crea un compromesso di sicurezza. Limitare troppo rigidamente un agente lo trasforma in un'interfaccia costosa per flussi di lavoro esistenti. Concedergli un'autorità più ampia attribuisce conseguenze operative ai suoi errori.

Il conflitto non scompare quando un agente rimane all'interno del cloud di un fornitore. Un ambiente controllato può ridurre l'esposizione, ma la logica aziendale determina comunque se un'azione sia accettabile.

Un agente può avere il permesso di aggiornare i record dei fornitori. Tale permesso non significa che ogni aggiornamento di un fornitore serva a uno scopo legittimo.

Un agente può inoltre combinare capacità a basso rischio in una sequenza ad alto rischio. Leggere fatture, creare fornitori e preparare pagamenti sembrano azioni gestibili se valutate separatamente.

Insieme, queste capacità possono riprodurre un intero percorso di frode. Talvolta si parla di rischio compositivo, in cui componenti apparentemente sicuri producono un risultato combinato non sicuro.

Gli strumenti di sicurezza spesso ispezionano singole chiamate API. Possono approvare ogni passaggio senza cogliere il piano più ampio che li collega.

La memoria dell'agente crea un'altra difficoltà. La memoria consente al software di conservare il contesto dell'attività, le preferenze o le osservazioni precedenti tra interazioni diverse.

Questa continuità può migliorare le prestazioni. Può anche conservare istruzioni dannose, dati sensibili o ipotesi errate oltre la sessione in cui sono entrati nel sistema.

La generazione aumentata dal recupero, o RAG, fornisce a un modello informazioni aziendali selezionate durante le risposte o le azioni. La sua sicurezza dipende dalla fonte, dai permessi, dalla qualità e dall'aggiornamento del materiale recuperato.

Una fonte di conoscenza avvelenata può distorcere decisioni successive senza compromettere direttamente il modello sottostante. Un documento di policy obsoleto può produrre un risultato simile attraverso un normale fallimento operativo.

Questo rende la governance delle informazioni parte della sicurezza degli agenti IA. I team devono sapere quali fonti utilizza un agente, chi può modificarle e in che modo le prove recuperate influenzano le decisioni.

I dipendenti che sviluppano flussi di lavoro interni hanno bisogno anche di documentazione affidabile. Una base di conoscenza consultabile può aiutare i team a preservare decisioni progettuali, modelli di minaccia e requisiti di approvazione relativi alle distribuzioni di agenti.

La documentazione non può sostituire i controlli tecnici. Può ridurre la probabilità che presupposti critici vadano persi quando un agente cambia responsabile o passa dalla fase pilota alla produzione.

L'accesso agli strumenti crea un rischio parallelo. Gli strumenti traducono l'output del modello in azioni, come interrogare un database, inviare un messaggio o modificare un record aziendale.

Il modello non necessita di credenziali dirette per il database se uno strumento connesso le possiede già. Lo strumento diventa quindi parte del perimetro effettivo delle autorizzazioni dell'agente.

Le revisioni di sicurezza devono esaminare gli schemi degli strumenti, la convalida degli input, l'archiviazione delle credenziali, il filtraggio degli output e il comportamento in caso di errore. Esaminare solo il modello trascura la maggior parte del percorso di esecuzione.

I sistemi multi-agente aumentano ulteriormente l'incertezza. Un agente può delegare la ricerca, un altro può interpretare le policy e un terzo può eseguire la transazione.

A ogni passaggio di consegne si può perdere contesto o introdurre output non attendibili. Può anche diventare poco chiaro quale componente abbia preso la decisione che ha causato un danno.

La security architecture pubblicata da SAP traccia le richieste degli agenti attraverso la verifica dell'identità, l'elaborazione AI, l'esecuzione aziendale e la registrazione forense.

Questa visione end-to-end va nella giusta direzione. Tuttavia, i diagrammi architetturali non dimostrano che ogni implementazione cliente applichi i controlli in modo coerente.

Gli ambienti ERP contengono codice personalizzato, integrazioni legacy, sistemi acquisiti, partner esterni ed eccezioni di lunga durata. Queste differenze possono indebolire il modello di sicurezza predefinito di un fornitore.

Le implementazioni più difficili riguarderanno ambienti ibridi. Un agente può iniziare in un moderno servizio cloud ma agire tramite applicazioni più vecchie con autorizzazioni poco granulari e telemetria limitata.

In questi ambienti, il componente più recente può ereditare il controllo più debole della catena. L'autonomia dell'agente amplifica quindi il debito tecnico che le organizzazioni già faticavano a gestire.

I log di audit non possono spiegare ogni decisione di un agente

La sicurezza ERP necessita di prove che colleghino l'intento dell'utente al ragionamento dell'agente, alle chiamate agli strumenti, alle modifiche dei dati e ai risultati aziendali.

I log di audit tradizionali rispondono a domande familiari. Mostrano quale account ha avuto accesso a un sistema, quando si è verificata una transazione e quale campo è cambiato.

I flussi di lavoro agentici richiedono una catena di prove più lunga. Gli investigatori necessitano dell'utente iniziale, dell'obiettivo delegato, della versione del modello, del contesto recuperato, delle decisioni di policy, delle chiamate agli strumenti e del risultato finale.

Potrebbero anche dover sapere cosa l'agente ha rifiutato di fare. Richieste ripetutamente negate possono rivelare tentativi di esplorazione, configurazioni errate o una fonte compromessa.

Registrare ogni prompt e risposta non è una soluzione semplice. I prompt possono contenere record retributivi, contratti, dati personali, credenziali e altre informazioni soggette a restrizioni.

Un log completo può quindi creare un altro archivio sensibile. Le regole di conservazione, accesso, crittografia e redazione devono corrispondere ai dati aziendali sottostanti.

Il ragionamento del modello presenta un'ulteriore complicazione. Una spiegazione generata può sembrare coerente senza rappresentare accuratamente il modo in cui il sistema è giunto al proprio output.

I team di sicurezza non dovrebbero considerare una spiegazione narrativa come prova. Hanno bisogno di registrazioni verificabili di input, richieste agli strumenti, valutazioni delle policy e conseguenti cambiamenti di stato.

Questo cambia il significato di osservabilità. Il monitoraggio deve acquisire il comportamento lungo l'intero flusso di lavoro, non semplicemente la disponibilità del modello o gli errori API.

Segnali utili includono una selezione inattesa degli strumenti, un volume insolito di transazioni, accessi al di fuori del normale ambito operativo, ripetuti dinieghi delle policy e modifiche a record sensibili.

Anche le baseline devono riflettere lo scopo assegnato a un agente. Un agente per la riconciliazione delle buste paga e un agente per gli approvvigionamenti non dovrebbero condividere lo stesso profilo di comportamento normale.

I limiti di frequenza possono ridurre il raggio d'azione degli errori. Non possono stabilire se un numero ridotto di azioni di alto valore sia legittimo.

Le soglie di transazione forniscono un ulteriore livello. Tuttavia, gli aggressori possono suddividere l'attività in azioni più piccole o sfruttare processi in cui una modifica di basso valore consente una perdita successiva.

Le aziende hanno bisogno di controlli in più punti. Il runtime dell'agente dovrebbe limitare gli strumenti, il livello di identità dovrebbe limitare l'autorità e l'ERP dovrebbe convalidare le regole aziendali.

Un monitoraggio indipendente dovrebbe poi verificare ciò che è effettivamente avvenuto. Affidarsi allo stesso agente per agire, valutare e riferire sul proprio comportamento concentra troppa fiducia.

L'approvazione umana resta preziosa per azioni irreversibili o rilevanti. Tuttavia, i revisori necessitano di tempo e contesto sufficienti per rilevare le manipolazioni.

La stanchezza da approvazione può trasformare una salvaguardia in una formalità. Gli agenti che operano alla velocità delle macchine possono generare più richieste di revisione di quante i dipendenti riescano a valutare con attenzione.

L'autonomia graduata in base al rischio offre un modello più praticabile. Le attività a basso impatto e reversibili possono procedere automaticamente, mentre le azioni sensibili richiedono una convalida indipendente.

Esempi di lavoro a minor rischio includono la redazione di spiegazioni, la raccolta di prove e la segnalazione di anomalie. Il lavoro a maggior rischio include la modifica dei dettagli di pagamento, il rilascio di fondi o la modifica degli accessi.

La reversibilità dovrebbe influenzare il livello di controllo. Un report errato può essere corretto, mentre un pagamento esterno o un record eliminato può causare danni duraturi.

Il profilo di rischio NIST organizza il lavoro sui rischi dell'AI attorno a governance, mappatura, misurazione e gestione. Questo approccio basato sul ciclo di vita si adatta agli agenti ERP meglio di un'approvazione una tantum.

Il rischio di un agente cambia quando cambiano i suoi strumenti, il modello, le fonti dati, le autorizzazioni o lo scopo aziendale. Ogni modifica dovrebbe attivare una rivalutazione e test mirati.

I test devono includere input avversariali ed eccezioni aziendali realistiche. Una dimostrazione basata su dati puliti non rivelerà come un agente si comporta in presenza di istruzioni contrastanti.

I team dovrebbero anche testare i guasti parziali. Un sistema downstream può andare in timeout dopo che un agente ha completato un passaggio ma prima che ne registri il successivo.

Senza idempotenza, che impedisce che esecuzioni ripetute producano effetti duplicati, un agente può inviare di nuovo la stessa transazione durante il ripristino.

Questi normali problemi di affidabilità diventano questioni di sicurezza quando incidono su record finanziari, diritti di accesso o dati regolamentati. La sicurezza degli agenti non può restare separata dall'ingegneria dei sistemi.

Le protezioni dei fornitori incontrano la realtà degli ERP personalizzati

SAP e Oracle possono proteggere le proprie piattaforme di agenti, ma i clienti controllano comunque le integrazioni, i ruoli, i dati e le eccezioni che determinano il rischio pratico.

I fornitori ERP hanno un vantaggio strutturale. Comprendono i modelli delle proprie applicazioni e possono integrare gli agenti accanto ai servizi esistenti di identità, workflow e audit.

Gli agenti nativi possono ereditare metadati aziendali che un modello esterno non possiede. Possono inoltre usare interfacce approvate invece di imitare le azioni degli utenti tramite uno schermo.

Oracle consiglia ai clienti di separare le responsabilità degli agenti e applicare il privilegio minimo tra gli agenti cooperanti. SAP descrive controlli dell'identità, isolamento dei tenant, convalida degli output e audit trail forensi.

Questi controlli affrontano preoccupazioni reali. Sostengono anche l'argomento dei fornitori secondo cui gli agenti integrati sono più sicuri dell'automazione di terze parti collegata in modo lasco.

L'argomento ha dei limiti. La maggior parte delle grandi organizzazioni non opera in un unico ambiente ERP pulito con configurazioni standard.

Esegue processi personalizzati su più sistemi. Alcune applicazioni restano on-premises, mentre altre risiedono in cloud pubblici o servizi gestiti dai fornitori.

Partner, appaltatori, banche, fornitori di logistica e unità aziendali acquisite possono connettersi allo stesso processo. Ogni confine introduce un diverso modello di identità e controllo.

Un agente finanziario nativo può comunque ricevere contenuti non attendibili via email. Può basarsi su un parser di documenti di terze parti o inviare un risultato a una vecchia applicazione di pagamento.

L'intero flusso di lavoro è affidabile solo quanto queste dipendenze. La documentazione di sicurezza del fornitore non può tenere conto di ogni estensione del cliente.

Gli agenti esterni presentano un diverso compromesso. Possono coordinare il lavoro tra piattaforme ERP, CRM, di comunicazione e analisi concorrenti.

Questa indipendenza può ridurre il lock-in del fornitore e supportare flussi di lavoro più ampi. Aggiunge però un ulteriore livello di identità, orchestrazione e strumenti tra utenti e record aziendali.

La scelta pratica non è quindi tra software nativo sicuro e software esterno insicuro. Entrambi gli approcci creano rischi, ma concentrano tali rischi in punti diversi.

Gli agenti nativi concentrano la fiducia nella piattaforma, nel cloud e nel modello di governance del fornitore ERP. Gli agenti esterni distribuiscono la fiducia tra connettori, credenziali, modelli e strumenti di orchestrazione.

I team di sicurezza dovrebbero valutare l'intero percorso dell'azione anziché accettare etichette di categoria. Un prodotto nativo può diventare insicuro attraverso una configurazione troppo ampia.

Un prodotto esterno può ridurre il rischio se riceve un'autorità strettamente limitata e di breve durata e non può completare direttamente transazioni sensibili.

Le revisioni degli acquisti devono riflettere queste differenze. I questionari standard sul software raramente rilevano la profondità della delega, il comportamento della memoria, la gestione dei prompt o le autorizzazioni a livello di strumento.

Gli acquirenti dovrebbero chiedere quale identità compare nel log ERP e se identifica l'utente originale. Dovrebbero anche chiedere come la policy segua un'attività attraverso i passaggi di consegne tra agenti.

Altre domande essenziali riguardano gli aggiornamenti del modello, il contesto conservato, la residenza dei dati, la risposta agli incidenti e l'accesso del cliente a una telemetria dettagliata.

Il fornitore dovrebbe spiegare come gli amministratori possano sospendere immediatamente un agente. Tale controllo deve revocare le credenziali attive e interrompere le azioni in sospeso, non limitarsi a nascondere l'interfaccia.

I clienti hanno bisogno anche di prove sulla gestione delle modifiche. Il comportamento di un agente può cambiare dopo una modifica al modello, al system prompt, alla definizione di uno strumento o a una fonte di recupero.

Un aggiornamento applicativo tradizionale modifica di solito codice deterministico. Un aggiornamento del modello può alterare le decisioni anche quando il flusso di lavoro circostante resta invariato.

I test di sicurezza devono quindi continuare dopo la distribuzione. I team dovrebbero eseguire attività rappresentative e casi di abuso ogni volta che cambia un componente significativo.

Dovrebbero confrontare i risultati tra le versioni e conservare prove sufficienti per indagare sulle regressioni. Un test superato sei mesi prima dice poco su un agente modificato.

La pressione competitiva può compromettere questa disciplina. I fornitori ERP vogliono che i clienti adottino gli agenti, mentre i leader aziendali vogliono miglioramenti di produttività misurabili.

I team di sicurezza possono ricevere pressioni per approvare progetti pilota ampi prima che i sistemi di identità e monitoraggio siano pronti. Questa sequenza trasforma la governance in un progetto di riparazione.

Un'implementazione più sicura inizia con attività delimitate e risultati osservabili. L'autorità si espande solo dopo che l'organizzazione è in grado di spiegare, rilevare e invertire il comportamento dell'agente.

Tre segnali mostreranno se la sicurezza ERP recupera terreno

La prossima fase sarà decisa da identità specifiche per gli agenti, applicazione delle policy a livello di azione e prove ricavate da incidenti reali in produzione.

Il primo segnale sarà se le piattaforme ERP adotteranno identità distinte e di breve durata per ogni agente e attività delegata. Gli account di servizio condivisi dovrebbero diventare un'eccezione.

Un'architettura matura preserverà l'utente originale, l'identità dell'agente, lo scopo e l'autorità lungo l'intero flusso di lavoro. Le applicazioni downstream dovrebbero ricevere questo contesto prima di consentire un'azione.

Ciò rafforzerebbe l'idea che gli agenti AI ERP possano operare all'interno di strutture di responsabilità consolidate. La continua dipendenza da credenziali ampie la indebolirebbe.

Il secondo segnale riguarda il fatto che fornitori e clienti applichino le policy a livello di singola transazione. L’autorizzazione a usare uno strumento non dovrebbe trasformarsi nell’autorizzazione a produrre qualsiasi possibile output con quello strumento.

I controlli dovrebbero considerare il tipo di transazione, il valore, la destinazione, le evidenze sulla fonte e la reversibilità. Le operazioni sensibili dovrebbero richiedere verifiche indipendenti esterne al modello che agisce.

I team di sicurezza dovrebbero monitorare i rilasci dei prodotti alla ricerca di funzionalità concrete di applicazione delle policy. Il linguaggio di marketing sull’AI responsabile è meno utile di controlli configurabili e log esportabili.

Dovrebbero inoltre verificare se tali controlli funzionano nelle applicazioni connesse. Una protezione limitata all’interfaccia di un singolo fornitore non coprirà un workflow multipiattaforma.

Il terzo segnale è la qualità della comunicazione pubblica degli incidenti. I fallimenti in produzione riveleranno dove le architetture teoriche si spezzano nelle condizioni operative reali.

Le comunicazioni utili identificheranno l’identità compromessa, l’input manipolato, gli strumenti coinvolti, le azioni non autorizzate e il metodo di contenimento. Riferimenti vaghi a un errore dell’AI non aiuteranno chi deve difendersi.

Gli incidenti dovrebbero anche chiarire se fosse prevista un’approvazione umana e perché non abbia funzionato. Queste evidenze mostreranno se la supervisione riduce il rischio o si limita a trasferire la responsabilità.

L’affermazione centrale alla base dell’avvertimento di Google News acquisirà forza se gli agenti si espanderanno più rapidamente di questi tre controlli. Si indebolirà se identità, applicazione delle policy ed evidenze matureranno insieme.

Le organizzazioni non dovrebbero attendere una perdita rilevante prima di mappare la propria esposizione. Possono iniziare elencando ogni agente connesso a un processo ERP.

Tale inventario dovrebbe includere proprietario, scopo, modello, strumenti, fonti dati, credenziali, punti di approvazione e procedura di arresto. Le voci sconosciute meritano un’indagine immediata.

Successivamente, i team dovrebbero tracciare alcuni workflow ad alto impatto, dall’istruzione alla transazione finale. Le modifiche ai pagamenti, le concessioni di accesso, le registrazioni contabili e gli aggiornamenti dei dati dei dipendenti sono buoni punti di partenza.

L’esercizio metterà in luce il contesto mancante tra i sistemi. Rivelerà inoltre dove una singola credenziale o uno strumento possiede più autorità di quanto il compito aziendale richieda.

Le aziende dovrebbero quindi classificare le azioni in base a impatto e reversibilità. La ricerca in sola lettura non richiede gli stessi controlli dell’erogazione di fondi o della modifica dei dati anagrafici principali.

Infine, i responsabili della sicurezza dovrebbero testare la risposta dell’organizzazione quando un agente si comporta in modo errato. Il rilevamento senza contenimento lascia senza risposta la domanda più importante.

Gli amministratori possono fermare l’agente, revocarne l’autorità, preservare le evidenze, annullare l’azione e identificare i record coinvolti prima che il danno si diffonda?

La sicurezza ERP non deve eliminare l’autonomia. Deve garantire che l’autonomia non si trasformi mai in un’autorità senza limiti.

Il prossimo passo pratico è semplice: scegliete un workflow di agente già attivo o pianificato e tracciate ogni identità, strumento, fonte dati e approvazione che coinvolge. Se il vostro team non riesce a spiegare tale catena, l’agente non è pronto per un accesso più ampio.

Chiedetevi chi può fermarlo, quali evidenze restano disponibili e quali azioni possono essere annullate. Queste risposte contano più di un’altra dimostrazione ben rifinita.

Google News ha portato alla luce l’avvertimento. Ora i team aziendali devono decidere se i loro controlli ERP governano gli agenti con la stessa attenzione con cui governano le persone.