Terza e ultima parte degli appunti di AI security. Nella prima ho scritto che i controlli tecnici non sopravvivono senza qualcuno che possieda il processo. Nella seconda che i server MCP ombra nascono perché il percorso conforme è più scomodo di quello che lo aggira. Restava una domanda, ed è quella di oggi.

Le due puntate precedenti finivano entrambe nello stesso punto cieco.

La prima si chiudeva sulla governance: senza un proprietario del processo, senza evidenze conservate, senza revisione periodica, i controlli tecnici decadono in silenzio. Vero, e insufficiente – perché non dice come si costruisce una governance che regge.

La seconda era più scomoda ancora. Una banca europea trova 47 server MCP fuori inventario, diversi con credenziali di produzione cablate dentro, e nessuno di quei server è opera di un malintenzionato: sono colleghi che dovevano consegnare. La conclusione era che lo shadow IT si batte con la convenienza, non con le circolari. Bella frase. E poi?

Il “e poi” è il tema di questo terzo pezzo, che nasce da un corso su tutt’altro argomento – la governance delle API, niente AI security in senso stretto – e che proprio per questo chiude il cerchio meglio di quanto avrebbe fatto un terzo corso sulle minacce.

La giungla, e le tre persone che ci vivono

Il punto di partenza è una diagnosi che chiunque lavori in un’organizzazione medio-grande riconosce al primo colpo. Dieci anni fa un’azienda grande gestiva qualche decina di servizi; oggi sono migliaia. La crescita ha superato la capacità di governarli a mano, e il risultato è quello che il corso chiama la giungla delle API: documentazione assente, sicurezza aggiunta dopo, servizi ombra che crescono al buio.

Il corso racconta la cosa attraverso tre persone, ed è un espediente che funziona meglio di qualunque diagramma.

Ada è una sviluppatrice brava che vorrebbe costruire. Oggi però ha davanti quattro versioni della stessa API di pagamento – payments, payments_new, payments_v2_final, billing_service – nessuna documentata davvero. Fa quella che il corso chiama archeologia digitale: scava nei log e nel codice per trovare un endpoint di cui fidarsi. Alla fine rinuncia e ne scrive una nuova, per rispettare la scadenza. Ha appena aggiunto il quinto ramo alla proliferazione che la stava esasperando.

Alex è il consumatore. Deve rilasciare una funzionalità e dipende dal servizio del team di Ada. Il progetto ha già due settimane di ritardo. Dal suo punto di vista l’ecosistema API non è una libreria di servizi riusabili, è una collezione di promesse non mantenute. Cerca in un registro incompleto, chiede a un collega, tira a indovinare.

Iris è la governance. È una cartografa che prova a mappare un territorio in movimento con carta e matita. A ogni vulnerabilità annunciata parte un audit manuale che dura settimane, e lei sa già in partenza che non troverà tutti i servizi ombra né tutte le dipendenze obsolete.

Nessuno dei tre sta sbagliando qualcosa. È il sistema attorno a loro che rende la strada giusta anche la più faticosa.

Perché il casello produce esattamente ciò che vorrebbe impedire

Qui sta l’osservazione più utile del corso, e vale la pena riportarla intera perché è controintuitiva solo finché non la si è vista accadere.

L’organizzazione del racconto aveva un modello di governance: un Architecture Review Board centralizzato, riunione ogni due martedì, revisione di ogni nuova API sottoposta. Sulla carta garantisce qualità e coerenza. Nella pratica il board è sommerso, le revisioni durano settimane o mesi, e gli sviluppatori – che hanno scadenze – costruiscono servizi fuori dai registri ufficiali per aggirare l’attesa.

Il modello a casello genera quindi una relazione conflittuale: il board diventa “quelli del no”, gli sviluppatori diventano “i cowboy”. E la conseguenza che conta è strutturale: il sistema progettato per creare ordine sta producendo disordine, perché costringe le persone a lavorargli attorno.

La parte che riguarda direttamente chi fa sicurezza operativa è il conto che arriva dopo. Ogni servizio costruito nell’ombra non è solo una riunione saltata: è un punto cieco permanente. Debito di governance che si accumula al buio, dove librerie non aggiornate ed endpoint non cifrati prosperano proprio perché nessuno li vede. E poi i costi che si manifestano tutti insieme nel momento peggiore: la risposta a un incidente che si trasforma in un’indagine su chi possieda un servizio che sta fallendo; le integrazioni post-acquisizione che diventano un incubo, perché non si integra ciò che non si riesce a trovare; il riuso che muore, con Alex che riscrive ciò che Ada aveva già fatto, raddoppiando manutenzione e superficie d’attacco.

Il checkpoint nato per garantire l’eccellenza è diventato il motore principale della proliferazione e del rischio nascosto.

Da cancelli a guardrail: quattro workflow

La proposta è tutta in una metafora: i guardrail di un’autostrada non esistono per fermarti, esistono perché tu possa viaggiare a centoventi in sicurezza. Tradotto: incorporare sicurezza e conformità dentro il flusso di lavoro, in modo che nessuno debba fermarsi ad aspettare.

Quattro pilastri, tutti automatizzati.

Deployment

Ada parte da un golden path: uno scheletro di progetto approvato che porta già con sé dipendenze consentite, configurazione di logging, integrazione con gli strumenti di monitoraggio e gran parte della checklist di conformità. Non deve costruirsi l’impalcatura: comincia dalla logica di business.

Quando spinge il codice, la pipeline – già preconfigurata dal template – esegue i controlli con un motore di policy as code: il design segue i principi REST, lo schema di sicurezza è corretto, la documentazione è completa. I risultati arrivano come commenti dentro la sua pull request, in minuti. Manca il contatto nella specifica? Una riga, push, verde.

E poi il pezzo che rende tutto il resto possibile: la stessa pipeline registra automaticamente il servizio sul gateway e sul catalogo. Nessun passaggio manuale successivo.

Il risultato è la frase attorno a cui ruota l’intero modello: creare un’API conforme è adesso più rapido che crearne una non conforme. Non c’è più nessuna ragione razionale per lavorare fuori dal sistema. È così che si elimina lo shadow IT – togliendogli il movente.

Endorsement

Registrazione automatica significa che il catalogo può avvisare subito gli esperti del dominio di business, che ricevono una checklist di conformità già compilata dai controlli automatici e devono valutare solo ciò che una macchina non può valutare: se il servizio fornisce davvero il valore che serve.

Intanto Alex cerca un servizio di pagamento, trova quello di Ada e vede accanto al nome un badge – diciamo bronze – assegnato automaticamente dai controlli superati in fase di deploy. Gli basta per iniziare a integrare. Quando il team di dominio completa la revisione, il servizio passa a gold, cioè pronto per la produzione.

Il punto non è il badge: è che Ada non è bloccata mentre la revisione avviene. Continua a iterare sulla logica di business negli ambienti non di produzione, il consumatore inizia a lavorare, la revisione scorre in parallelo. Il gate scompare senza che scompaia il controllo.

Reporting

Poiché tutto passa dal gateway, la telemetria arriva da sola su un cruscotto. Iris comincia la giornata guardando lo stato reale dell’ecosistema: quante API sono nate ieri, com’è distribuita la qualità tra i reparti, chi è fuori standard.

L’esempio che il corso usa è quello giusto: quando esce una vulnerabilità tipo Log4j, Iris non apre un’indagine manuale. Aggiunge una policy, e il cruscotto le mostra immediatamente ogni servizio non conforme.

E qui il sistema si chiude ad anello. Iris nota che troppi servizi nascono senza rate limiting, definisce la regola e la applica al livello bronze: al deploy successivo, di chiunque, il controllo è già attivo. Lo standard si alza da solo, senza che nessuno diventi un collo di bottiglia.

Retirement

L’ultimo pilastro è quello che di solito non si costruisce, ed è quello che tiene in piedi gli altri tre nel tempo.

Le zombie API sono servizi abbandonati da chi li ha creati e ancora attivi in rete. La definizione del corso è efficace: una casa vuota, non chiusa a chiave, con le luci accese e la porta aperta. Nessuno ci abita, nessuno applica le patch, nessuno le monitora, e sono il bersaglio preferito di chi cerca il percorso di minor resistenza.

La telemetria che alimenta il cruscotto alimenta anche i criteri di pensionamento: nessuna risposta 200, nessun consumatore attivo, nessuna richiesta negli ultimi novanta giorni. I candidati vengono segnalati, i team notificati, il flusso di dismissione parte.

E questo è il punto che il corso enuncia meglio di quanto io abbia visto fare altrove: se acceleri solo la costruzione senza dismettere mai nulla, la giungla ricresce dal fondo. Un ecosistema veloce e sporco torna a essere un ecosistema sporco in un paio d’anni.

Cosa ci aggiungo io

Fin qui il corso. Tre osservazioni che mi sembrano più interessanti del materiale da cui nascono.

Questo è l’inventario che i due articoli precedenti continuavano a invocare. Sia sull’AI security sia sull’MCP, la conclusione tornava sempre la stessa: l’inventario è la postura di sicurezza, non puoi proteggere ciò di cui ignori l’esistenza. Ma un inventario compilato a mano è vero il giorno in cui lo scrivi e falso il mese dopo. L’unico inventario che resta attendibile è quello che si aggiorna da solo come effetto collaterale del deploy – che è esattamente ciò che fa il primo pilastro. Non è un dettaglio implementativo: è la differenza tra avere un registro e avere una fotografia storica.

La telemetria per il pensionamento è la stessa telemetria che serve per indagare. È l’aspetto che mi interessa di più professionalmente. I dati che permettono di dire “questo servizio non riceve richieste da novanta giorni” sono gli stessi che permettono di dire “questo servizio ha ricevuto un picco anomalo di richieste martedì alle 3 del mattino”. Chi costruisce il quarto pilastro per ragioni di igiene architetturale si ritrova la capacità investigativa in omaggio – e viceversa, chi non ce l’ha scoprirà di non averla nel momento peggiore. Aggiungo il corollario che il corso non trae: la domanda che blocca l’avvio di quasi ogni incident response è chi possiede questo servizio. Un catalogo con proprietario obbligatorio per la registrazione la risolve mesi prima che venga posta.

E il legame diretto con l’MCP. Un server MCP non è altro che un involucro sopra delle API: alla fine della catena ci sono sempre quelle, come scrivevo nel secondo articolo. Il che significa che la governance delle API è il prerequisito a monte della governance MCP, non un tema parallelo. Se il catalogo sottostante è una giungla, l’MCP non fa che esporla – e la espone a un decisore non deterministico che sceglie da solo quale servizio invocare. Il corso ci arriva dal lato opposto, dicendo che gli agenti hanno bisogno di contextual grounding, cioè di specifiche OpenAPI accurate e leggibili dalla macchina: governando le API non stai solo governando codice, stai scrivendo il manuale con cui un’AI opererà sulla tua azienda. Vero. E vale anche il rovescio: quel registro centrale con i livelli di qualità è, alla lettera, il controllo che la MCP09 chiede per i server ombra. Chi ha già costruito l’autostrada per le API ha metà del lavoro fatto per gli agenti.

Sul piano degli standard, il riferimento che il corso cita è NIST SP 800-228, le linee guida per la protezione delle API nei sistemi cloud-native: pubblicate a giugno 2025 e aggiornate a marzo 2026. Vale la pena leggerle direttamente, perché organizzano i controlli tra fase di pre-runtime e fase di runtime – che è poi la stessa distinzione tra i quattro pilastri di cui sopra.

Qualche cautela, che il corso non mette

Il materiale è dichiaratamente entusiasta, come capita a chi ha visto il modello funzionare. Tre avvertenze da praticante.

Il golden path è un prodotto, e i prodotti si manutengono. Un template approvato che nessuno aggiorna diventa, in diciotto mesi, il modo standardizzato di produrre debito tecnico uniforme. Serve un team che lo possieda, con un budget, altrimenti il percorso conforme torna a essere il percorso scomodo e siamo al punto di partenza.

I livelli di qualità possono diventare teatro. Se gold si ottiene superando controlli automatici che nessuno rivede, il badge misura la conformità formale e non l’affidabilità. La revisione di dominio del secondo pilastro è la parte che impedisce questa deriva, ed è anche la prima che verrà sacrificata quando si sarà di corsa.

Non è un progetto a costo zero né a tempo breve. Tra piattaforma interna, gateway centralizzato, catalogo, motore di policy e pipeline condivise c’è un investimento serio. In un’organizzazione piccola il modello va ridotto all’osso: catalogo con proprietario obbligatorio, un solo controllo automatico bloccante, telemetria minima. Meglio un pilastro solo che quattro disegnati su una slide.

Cosa farei lunedì mattina

Conta i tuoi servizi e conta quanti hanno un proprietario nominato. La differenza tra i due numeri è la tua esposizione reale, ed è anche il tempo che perderai all’inizio del prossimo incidente.
Cerca i duplicati. Quattro varianti della stessa API sono un sintomo, non un problema estetico: qualcuno ha trovato più facile riscrivere che riusare, e va capito perché.
Misura la latenza della tua governance. Quanto passa tra la richiesta di revisione e la risposta? Se si misura in settimane, hai già delle API ombra: non è un’ipotesi, è aritmetica.
Definisci i criteri di zombie e applicali una volta sola, a mano. Nessun traffico in novanta giorni, nessun consumatore, nessuna risposta valida. L’elenco che ne esce è la riduzione di superficie d’attacco più economica che tu possa fare quest’anno.
Sposta un controllo dalla riunione alla pipeline. Uno solo, il più meccanico che hai. È la dimostrazione che serve per ottenere il budget per gli altri.
Verifica se il tuo catalogo API è leggibile da una macchina. Perché il prossimo consumatore dei tuoi servizi, molto probabilmente, non sarà una persona.

La tesi delle tre puntate, a questo punto, si riassume in una riga sola: la sicurezza di questi sistemi non si ottiene aggiungendo controlli, ma rendendo la strada sicura anche la più comoda da percorrere. Tutto il resto viene aggirato – non per malizia, ma perché c’è una scadenza.

Articolo elaborato a partire dagli appunti del corso “Zero Touch API Governance” di AISEC University (docente: Supreet Nagi). Le osservazioni sul rapporto con la governance MCP, la parte investigativa, le cautele finali e la verifica dei riferimenti sono mie, aggiornate a settembre 2026.