AI-SPM (AI Security Posture Management) è la pratica di scoprire, valutare e applicare continuamente la sicurezza su ogni risorsa di IA operante nella tua organizzazione (modelli, agenti, server MCP, set di dati, strumenti di codifica IA e framework IA), insieme alle relazioni, ai rischi e agli obblighi normativi che li collegano. Se ti stai chiedendo cos'è AI-SPM e perché è importante ora, la risposta breve è questa: non puoi proteggere ciò che non vedi e la maggior parte delle organizzazioni non può vedere l'IA in esecuzione nelle proprie pipelines.
As L'intelligenza artificiale viene integrata in ogni fase dello sviluppo del software.La gestione tradizionale della postura di sicurezza delle applicazioni non è stata progettata per comprendere cosa sia un modello, cosa possa fare un agente o cosa possa raggiungere un server MCP. AI-SPM colma questa lacuna. Questa guida spiega cos'è la gestione della postura di sicurezza basata sull'IA e in che modo differisce da ASPMperché sta diventando un requisito di conformità e come si presenta una pratica AI-SPM matura nel 2026.
Cos'è AI-SPM? Definizione approfondita #
La gestione della postura di sicurezza dell'IA (AI-SPM) è una disciplina di sicurezza che applica la scoperta continua, la valutazione del rischio e l'applicazione delle policy alle risorse specifiche dell'IA lungo tutto il ciclo di vita dello sviluppo del software. Application Security Posture Management (ASPM) aggrega e dà priorità ai risultati da SAST, SCA, DASTe strumenti segreti, AI-SPM estende tale ambito per coprire le risorse che questi strumenti non erano mai stati progettati per comprendere: modelli linguistici di grandi dimensioni, agenti autonomi, server Model Context Protocol, configurazioni di prompt, set di dati e assistenti di programmazione AI.
La funzione principale dell'AI-SPM è la stessa di qualsiasi pratica di gestione della postura: sapere cosa si ha, comprendere il rischio che comporta e applicare le policy prima che tale rischio si trasformi in un incidente. La differenza sta nella classe di asset. Un server MCP configurato in modo errato, un agente con autorizzazioni eccessive o un modello che attinge da un dataset contaminato non è un vulnerabilità nel senso tradizionale di CVE; sono errori di postura che richiedono una logica di rilevamento specifica dell'IA, un punteggio di rischio specifico dell'IA e Linee guida per la risoluzione di problemi specifici relativi all'IA.
AI-SPM viene talvolta descritto come lo strato di intelligenza artificiale sopra ASPMe talvolta come pratica a sé stante. In entrambi i casi, il requisito fondamentale è lo stesso: le organizzazioni hanno bisogno di un metodo sistematico per individuare ogni risorsa di intelligenza artificiale, valutarne il rischio e agire in base ai risultati.
AI-SPM vs ASPMQual è la differenza? #
ASPM (Application Security Posture Management) è stato costruito per correlare i risultati degli strumenti AppSec tradizionali (SAST, SCA, DAST, scanner di segreti, IaC Gli analizzatori) in una visione unificata del rischio per l'intero portfolio applicativo. Risponde alla domanda: quali vulnerabilità esistono nel nostro codice e nelle nostre dipendenze e quali sono le più importanti?
AI-SPM pone una domanda diversa: quale intelligenza artificiale è in esecuzione nel nostro ambiente, cosa può fare ed è configurata in modo sicuro?
Le due pratiche sono complementari anziché in competizione:
ASPM copre il codice, le dipendenze, pipelines e infrastrutture. AI-SPM copre modelli, agenti, server MCP, configurazioni di prompt e set di dati. Dove ASPM valuta il rischio in base alla gravità e alla raggiungibilità delle CVE, AI-SPM valuta il rischio in base ai vettori di attacco specifici dell'IA, all'esposizione all'iniezione immediata, all'eccessiva agenzia, alle configurazioni MCP non sicure, all'IA ombra e alla fuga di dati attraverso i sistemi RAG.
In un programma di sicurezza maturo, AI-SPM alimenta ASPM: Il rischio degli asset AI è un altro segnale nella vista unificata della postura, correlato al rischio a livello di codice e pipeline security per fornire un quadro completo della superficie di attacco dell'organizzazione.
htmlPerché AI-SPM è importante ora #
Tre fattori hanno fatto sì che l'AI-SPM passasse da una considerazione futura a un requisito operativo immediato.
- Le risorse basate sull'intelligenza artificiale si stanno moltiplicando più velocemente di quanto la governance riesca a tenere il passo. Gli sviluppatori stanno configurando i server MCP localmente, scaricando modelli da hub pubblici, abilitando assistenti di codifica AI per IDE e implementando agenti autonomi in CI/CD pipelinespesso senza approvazione formale. In un sondaggio del 2026 condotto tra i responsabili della sicurezza, solo il 19% ha dichiarato di avere piena visibilità su dove e come viene utilizzata l'IA all'interno della propria organizzazione. Il resto opera alla cieca.
- Gli aggressori prendono di mira direttamente lo strato di intelligenza artificiale. La campagna PromptMink ha creato pacchetti npm dannosi specificamente progettati per ingannare gli agenti di programmazione AI. I cluster ollama-helpers e openai-agents-helpers hanno preso di mira i pacchetti utilizzati nei flussi di lavoro agentici. SkillLeak Il modello nascondeva un decrittatore di credenziali all'interno di una skill MCP anziché in un hook di installazione, precisely perché installa hooks Sono questi i punti in cui gli scanner cercano. Gli strumenti tradizionali di sicurezza delle applicazioni non comprendono queste superfici di attacco. AI-SPM sì.
- La regolamentazione sta arrivando. La legge europea sull'IA, il NIST AI RMF e la norma ISO/IEC 42001 impongono alle organizzazioni di documentare, classificare e governare i sistemi di IA che gestiscono. Nessuno di questi obblighi può essere soddisfatto senza prima sapere quale IA si sta utilizzando. AI-SPM è il prerequisito per la conformità, non un'aggiunta.
Cosa comprende AI-SPM? #
Una pratica completa di AI-SPM comprende quattro capacità:
- Rinforzo. Agire in base ai risultati dell'analisi della postura di sicurezza, bloccare i server MCP non approvati sull'endpoint dello sviluppatore, intercettare le dipendenze dannose prima che vengano installate, segnalare le configurazioni dei prompt che superano i limiti del minimo privilegio e isolare gli endpoint compromessi prima che un incidente si propaghi.
- Scoperta. Trovare continuamente ogni risorsa di IA in tutta l'organizzazione (modelli, agenti, server MCP, strumenti di programmazione IA, set di dati e framework IA), inclusi quelli che l'IT non ha mai approvato. L'IA ombra è la più difficile da trovare perché vive sui laptop degli sviluppatori, nelle configurazioni IDE locali e all'interno CI/CD pipelinepiuttosto che nelle console cloud.
- Punteggio del rischio. Valutazione di ogni risorsa rispetto ai vettori di attacco specifici dell'IA: esposizione all'iniezione immediata, rischio di avvelenamento degli strumenti, agenzia eccessiva, configurazioni MCP non sicure, fuga di dati attraverso sistemi RAG e IA ombra senza governance. La sola gravità del CVE non è sufficiente a cogliere questi rischi; AI-SPM richiede un modello di rischio costruito per il percorso di attacco dell'IA.
- Mappatura normativa. Collegamento di ogni risorsa di IA agli obblighi di conformità previsti dalla legge europea sull'IA, dal NIST AI RMF, dalla norma ISO/IEC 42001 e dalla OWASP Top 10 per le applicazioni LLM e le app agentiche. L'AI-BOM è il risultato di questa mappatura, pronto per la verifica: un inventario leggibile automaticamente di ogni risorsa di IA con il relativo livello di rischio e classificazione normativa.
AI-SPM e AI-BOM #
La AI-BOM (AI Bill of Materials) è l'artefatto esportabile e pronto per la verifica che AI-SPM produce. Dove un SBOM cataloga le dipendenze del software open-source e di terze parti, una distinta base basata sull'IA Cataloga le risorse specifiche dell'IA: modelli, set di dati, agenti, server MCP e strumenti di programmazione per l'IA, con la relativa provenienza, il livello di rischio e la mappatura normativa.
I responsabili della sicurezza ricevono sempre più richieste da parte dei revisori dei conti e enterprise team di approvvigionamento proprio per questo artefatto. Le organizzazioni in grado di generare una distinta base basata sull'IA su richiesta (come output continuo della loro pratica AI-SPM anziché come un'operazione manuale puntuale) avranno un vantaggio significativo in termini di conformità e fiducia man mano che gli obblighi di audit previsti dalla legge europea sull'IA matureranno.
AI-SPM e i framework OWASP #
Il rilevamento e la valutazione del rischio delle strategie di prevenzione e controllo dell'abuso dell'IA dovrebbero essere allineati ai framework della comunità che definiscono il rischio specifico dell'IA:
- Migliori OWASP Top 10 per le domande di LLM Copre i dieci rischi più critici per le applicazioni basate su modelli linguistici di grandi dimensioni, tra cui l'iniezione di prompt, la gestione non sicura dell'output, la divulgazione di informazioni sensibili, l'eccessiva agenzia e altro ancora. AI-SPM mappa l'esposizione di ogni risorsa di IA rispetto a queste categorie.
- Migliori OWASP Top 10 per le applicazioni agentiche Estende tale framework ai flussi di lavoro degli agenti autonomi, coprendo rischi come il dirottamento dell'agente, l'invocazione incontrollata di strumenti e l'avvelenamento della memoria, specifici delle architetture agentiche.
- Migliori OWASP MCP Top 10 Affronta i rischi per la sicurezza introdotti dalle integrazioni del Model Context Protocol, dall'avvelenamento degli strumenti, dall'iniezione di prompt tramite MCP, dall'esecuzione non autorizzata degli strumenti e dai server MCP ombra.
L'allineamento a questi framework trasforma i risultati dell'IA SPM in classificazioni di rischio attuabili e validate esternamente che i revisori e enterprise gli acquirenti possono valutare.
Cosa cercare negli strumenti AI-SPM #
Se state valutando le capacità di un sistema AI-SPM, ecco i requisiti che distinguono una vera gestione della postura di sicurezza basata sull'IA da un semplice elenco statico di risorse:
Si allunga nel SDLC: scoprire l'IA nel codice, costruire pipelinee sugli endpoint degli sviluppatori, non solo nelle console cloud, dove la maggior parte dell'IA ombra non appare mai.
Comprende i tipi di risorse, i modelli, gli agenti, i server MCP, i set di dati e le configurazioni dei prompt specifici dell'IA, non solo i pacchetti e le librerie.
Valuta il rischio in base a vettori di attacco specifici dell'IA (iniezione di prompt, MCP non sicuro, agenzia eccessiva, IA ombra) e non solo in base alla gravità delle CVE.
Genera una distinta base (BOM) per l'IA pronta per la verifica, con mappatura normativa conforme alla legge europea sull'IA, al NIST AI RMF e alla norma ISO/IEC 42001.
Collega la postura all'applicazione: quindi i risultati si traducono in dipendenze bloccate, server MCP rifiutati ed endpoint contenuti, non solo un dashboard delle questioni aperte.
Funziona in modo continuo: rileva le nuove risorse di intelligenza artificiale non appena compaiono, non si tratta di un'analisi puntuale che diventa obsoleta nel giro di pochi giorni.
Proteggere la postura dell'IA con Xygeni #
AI-SPM richiede più di un dashboardRichiede un rilevamento continuo che si estenda fino all'endpoint dello sviluppatore, una valutazione del rischio basata sul percorso di attacco dell'IA e la capacità di applicare le policy prima che un server MCP configurato in modo errato o una dipendenza dannosa causino un incidente.
La piattaforma di sicurezza basata sull'intelligenza artificiale di Xygeni fornisce AI-SPM come pratica continua: scoprendo ogni modello, agente, server MCP e strumento di codifica AI in tutta la tua SDLC tramite AI-SPM, valutando il rischio rispetto alla OWASP Top 10 per applicazioni LLM, app Agentic e MCP, producendo una distinta base AI esportabile per i revisori e enterprise acquirenti e applicazione delle politiche all'endpoint dello sviluppatore tramite Shield, bloccando i server MCP non approvati e le dipendenze dannose prima che raggiungano il pipeline.
Se i vostri team utilizzano assistenti di programmazione basati sull'IA, il problema della postura dell'IA è già presente. La domanda è se avete la visibilità necessaria per gestirlo.

FAQ #
MCAI-SPM viene utilizzato per individuare ogni risorsa di intelligenza artificiale in esecuzione all'interno di un'organizzazione, valutare il rischio di ciascuna risorsa rispetto ai vettori di attacco specifici dell'IA, generare una distinta base di intelligenza artificiale (AI-BOM) a fini di conformità e audit e applicare le policy a livello del terminale dello sviluppatore, bloccando i server MCP non approvati e le dipendenze dannose prima che causino un incidente.
La legge europea sull'IA non menziona esplicitamente l'AI-SPM, ma i suoi obblighi di documentazione, classificazione e registrazione per i sistemi di IA ad alto rischio sono impossibili da soddisfare senza sapere quale IA si sta utilizzando. L'AI-SPM è la pratica che rende possibili tali obblighi. Lo stesso vale per il NIST AI RMF e la norma ISO/IEC 42001.
Considerate l'inventario dell'IA come le fondamenta e l'AI-SPM come il quadro completo. L'inventario individua e cataloga ogni risorsa di IA, specificandone la natura, la posizione di esecuzione e le potenzialità. L'AI-SPM si basa su queste fondamenta e le sviluppa ulteriormente: valuta il rischio rispetto ai vettori di attacco specifici dell'IA, associa ogni risorsa agli obblighi normativi e applica le policy in base ai risultati ottenuti. L'inventario è indispensabile per implementare l'AI-SPM. Tuttavia, un inventario da solo, senza valutazione e applicazione delle policy, rimane un semplice elenco.
Shadow AI è l'IA che il tuo team di sicurezza non ha approvato e non può vedere, il modello che uno sviluppatore ha prelevato da un hub pubblico, il server MCP in esecuzione su un laptop, l'agente che apre silenziosamente pull requests in un pipeline Nessuno ha effettuato verifiche. Raramente compare in una console cloud, motivo per cui la scoperta basata esclusivamente sul cloud ne ignora la maggior parte. AI-SPM è importante per l'IA ombra perché raggiunge i luoghi in cui l'IA ombra risiede effettivamente: repository di codice, ambienti di build ed endpoint degli sviluppatori, scoprendo le risorse prima che diventino un rischio non gestito.