Per anni abbiamo costruito la sicurezza enterprise attorno a soggetti abbastanza chiari: utenti, endpoint, workload e applicazioni. Oggi ne sta comparendo un altro, molto meno deterministico: l’agente AI.
Un agente moderno può leggere una mail, analizzare un repository, interrogare un database, scegliere un tool, usare un server MCP, chiamare un’API ed eseguire un comando. OpenAI descrive i coding agent come sistemi capaci di lavorare autonomamente sui repository, eseguire comandi e interagire con strumenti di sviluppo; per questo affianca sandboxing, policy di rete, approvazioni e telemetria nativa dell’agente.
Il passaggio importante è questo: l’AI non è più soltanto un’applicazione che elabora dati. Sta diventando un’identità che usa privilegi e produce azioni reali.
Da chatbot a workload operativo
Il chatbot classico riceve una richiesta e restituisce una risposta. Un agente, invece, può pianificare una sequenza di attività e usare strumenti per raggiungere un obiettivo.
UTENTE
│
▼
AGENTE AI
├── Identità / token
├── Browser / filesystem
├── MCP server
├── API / SaaS / Cloud
└── Tool locali
│
▼
AZIONE REALE
Questa differenza sembra piccola, ma cambia il modello di rischio. Un errore del modello non produce necessariamente una frase sbagliata: può produrre una modifica, una cancellazione, un accesso o una connessione di rete.
Perché EDR e XDR non bastano a raccontare tutta la storia
EDR e XDR restano fondamentali. Il problema è che il nuovo layer agentico aggiunge un contesto che l’endpoint da solo non sempre possiede.
Immaginiamo una catena semplice:
- un agente legge un repository;
- nel repository trova un’istruzione malevola o ambigua;
- la interpreta come parte del task;
- richiama un tool;
- il tool accede a credenziali o dati sensibili;
- parte una connessione verso un servizio esterno.
L’EDR può osservare letture di file, processi e connessioni. L’XDR può correlare segnali provenienti da endpoint, identity, cloud o SaaS. Ma resta una domanda: qual è stata la catena causale che ha portato l’agente a quell’azione?
Apri: cosa vede ogni layer?
EDR: processi, file, memoria, comandi e rete sull’endpoint.
XDR: correlazione tra endpoint, identità, email, cloud, SaaS e rete.
IAM: chi o cosa può autenticarsi e quali privilegi possiede.
DLP: quali dati possono essere copiati o trasferiti e verso quali destinazioni.
AIDR / ADR: prova a collegare prompt, identità, tool call, agent session ed esecuzione runtime.
SIEM / SOAR: centralizza telemetria, correlazione, automazione e risposta.
AIDR: una categoria emergente, non ancora uno standard
Il termine AI Detection and Response viene oggi spinto soprattutto da CrowdStrike con Falcon Guardian. È importante però non confondere il posizionamento di un vendor con uno standard di mercato già consolidato.
Il problema tecnico, però, è concreto e non appartiene a un solo produttore. A maggio 2026 un gruppo di ricercatori di Uber ha pubblicato ADR: An Agentic Detection System for Enterprise Agentic AI Security, descrivendo un sistema Agentic Detection and Response utilizzato in produzione per osservare agenti che operano tramite MCP. Gli autori evidenziano esplicitamente il gap di osservabilità: gli strumenti EDR possono vedere l’effetto sull’host, ma non necessariamente il prompt, il reasoning o la catena causale che collega intenzione ed esecuzione.
Il paper riporta un deployment durato oltre dieci mesi, arrivato a più di 7.200 host unici e oltre 10.000 sessioni agentiche giornaliere. Non è la prova che “AIDR sostituirà l’EDR”; è piuttosto un segnale che il settore sta cercando nuovi sensori e nuovi modelli di correlazione.
Falcon Guardian e il concetto prompt-to-runtime
Con Falcon Guardian, CrowdStrike descrive un’architettura che unisce attività dell’agente e telemetria endpoint. Per gli agenti supportati, la piattaforma collega prompt, skill, tool call, server MCP e identità con l’esecuzione successiva sul sistema operativo.
PROMPT
│
▼
AGENT SESSION
├── Identity
├── Skill
├── MCP server
└── Tool call
│
▼
RUNTIME
┌──────┼──────┐
▼ ▼ ▼
File Process Network
└──────┼──────┘
▼
IMPACT
Il valore del modello è nella possibilità di ricostruire una catena più completa: cosa è stato chiesto → cosa ha deciso l’agente → quale strumento ha usato → quale identità ha presentato → cosa è successo sul sistema.
CrowdStrike ha inoltre annunciato l’estensione di Falcon Guardian ai Codex agents tramite la partnership con OpenAI. Va però fatta una distinzione importante sulla disponibilità: nell’annuncio del 1° settembre, il nuovo AI Gateway associato a Guardian era ancora indicato come pre-beta, con disponibilità generale prevista successivamente. La stessa CrowdStrike invita a distinguere le capacità già disponibili da quelle ancora in sviluppo.
Il problema realistico non è “l’AI che diventa cattiva”
Uno scenario molto più concreto è un agente autorizzato che viene indotto a fare qualcosa che non avrebbe dovuto fare.
NIST dedica particolare attenzione all’indirect prompt injection: istruzioni malevole inserite in contenuti esterni come email, pagine web, documenti o repository che vengono poi letti dall’agente. In una competizione di red teaming analizzata nel 2026, sono stati trovati attacchi efficaci contro tutti i 13 modelli frontier testati almeno una volta, su oltre 250.000 tentativi.
OWASP amplia il quadro con rischi come tool abuse, privilege escalation, data exfiltration, memory poisoning, goal hijacking ed excessive autonomy.
Apri: una possibile Agent Kill Chain
INDIRECT PROMPT INJECTION
↓
AGENT HIJACK
↓
TOOL CALL
↓
CREDENTIAL ACCESS
↓
MCP / API
↓
DATA ACCESS
↓
EXFILTRATION
In questa catena, nessun singolo controllo è sufficiente: identità, endpoint, dati, runtime agentico e logging devono contribuire alla stessa ricostruzione.
La vera battaglia sarà sulle identità
Se un agente deve agire autonomamente, le domande di sicurezza diventano molto simili a quelle che poniamo per utenti e workload: chi sei, chi ti ha creato, chi è il tuo owner, a cosa puoi accedere, con quali privilegi e per quanto tempo?
Microsoft Entra Agent ID nasce proprio per questo scenario. Microsoft descrive le agent identities come identità specializzate per agenti AI, distinte dagli utenti umani e dalle application identities tradizionali. Possono ottenere token, accedere a servizi e operare in modalità autonoma o delegata.
Il principio Zero Trust diventa quindi ancora più concreto: identità distinta, privilegi minimi, accesso temporaneo, ownership chiara e revoca rapida.
ZERO TRUST
│
├── Agent Identity
├── Least Privilege
├── Conditional / Contextual Access
├── Data Policy
└── Runtime Telemetry
│
▼
AI AGENT
│
▼
EDR / XDR / AIDR
│
▼
SIEM / SOC
MCP: il moltiplicatore della superficie d’attacco
Il Model Context Protocol rende molto semplice collegare un agente a tool, dati e servizi. Ed è proprio questa utilità a renderlo un punto da governare con attenzione.
OWASP descrive rischi specifici di MCP: tool poisoning, rug pull, tool shadowing, confused deputy, token troppo permissivi, data exfiltration tramite canali legittimi e supply-chain compromise. La particolarità è che il modello può decidere dinamicamente quale tool invocare, quando e con quali parametri.
Apri: controlli minimi per MCP
- allowlist di server e tool approvati;
- scope OAuth minimi e token a breve durata;
- sandbox dei server MCP locali;
- approvazione umana per azioni distruttive o sensibili;
- validazione degli input e degli output dei tool;
- logging centralizzato delle invocazioni;
- controllo delle variazioni nelle definizioni dei tool;
- separazione tra tool ad alto e basso impatto.
Un possibile Agent Security Control Loop
Il modo in cui imposterei il problema non parte da un prodotto, ma da un ciclo operativo.
- Discover — quali agenti sono realmente presenti, compresi quelli “shadow”?
- Identify — ogni agente ha un’identità, un owner e uno sponsor?
- Authorize — gli accessi sono davvero least privilege e temporanei?
- Observe — possiamo correlare prompt, sessione, tool call, identità ed execution telemetry?
- Detect — sappiamo riconoscere injection, escalation, anomalie e data exfiltration?
- Contain — possiamo revocare token, bloccare tool, terminare sessioni o isolare l’endpoint?
- Audit — dopo l’incidente possiamo ricostruire l’intera catena causale?
DISCOVER → IDENTIFY → AUTHORIZE → OBSERVE → DETECT → CONTAIN → AUDIT ↺
Cosa controllerei domani mattina
Prima ancora di acquistare un nuovo prodotto, partirei da cinque verifiche pratiche.
- Inventario: quali agenti AI e coding agent stanno già girando sui device aziendali?
- Identità: stanno usando account personali, token statici, service principal o identità dedicate?
- Tool: quali MCP server e plugin possono richiamare? Hanno privilegi di scrittura?
- Rete e dati: possono raggiungere liberamente Internet, storage, repository, email o database?
- Telemetria: in caso di incidente, possiamo correlare richiesta dell’utente, decisione dell’agente, tool invocato ed effetto sul sistema?
Se a quest’ultima domanda la risposta è “no”, abbiamo probabilmente un gap di osservabilità prima ancora che di detection.
Conclusione
EDR e XDR non stanno diventando obsoleti. Al contrario: quando gli agenti AI trasformano intenzioni in azioni, la telemetria endpoint, identity, cloud e data diventa ancora più importante.
Quello che sta emergendo è un layer in più, capace di collegare intenzione, identità, decisione ed esecuzione. CrowdStrike lo chiama AIDR. Uber parla di ADR. È troppo presto per sapere quale nome resterà.
La domanda utile, però, è già qui:
Se domani un agente AI compisse un’azione sbagliata nella mia infrastruttura, sarei in grado di sapere chi gliel’ha chiesta, perché l’ha fatta, quali privilegi ha utilizzato e come fermarlo?