{"id":30452,"date":"2026-09-15T17:20:15","date_gmt":"2026-09-15T15:20:15","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=30452"},"modified":"2026-09-15T17:35:30","modified_gmt":"2026-09-15T15:35:30","slug":"la-governance-che-nessuno-ha-interesse-ad-aggirare","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2026\/09\/15\/la-governance-che-nessuno-ha-interesse-ad-aggirare\/","title":{"rendered":"La governance che nessuno ha interesse ad aggirare"},"content":{"rendered":"\n

Terza e ultima parte degli appunti di AI security<\/a>. Nella prima <\/a>ho scritto che i controlli tecnici non sopravvivono senza qualcuno che possieda il processo. Nella seconda <\/a>che i server MCP ombra nascono perch\u00e9 il percorso conforme \u00e8 pi\u00f9 scomodo di quello che lo aggira. Restava una domanda, ed \u00e8 quella di oggi.<\/em><\/p>\n\n\n\n

Le due puntate precedenti finivano entrambe nello stesso punto cieco.<\/p>\n\n\n\n

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\u00e9 non dice come<\/em> si costruisce una governance che regge.<\/p>\n\n\n\n

La seconda era pi\u00f9 scomoda ancora. Una banca europea trova 47 server MCP fuori inventario, diversi con credenziali di produzione cablate dentro, e nessuno di quei server \u00e8 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?<\/p>\n\n\n\n

Il \u201ce poi\u201d \u00e8 il tema di questo terzo pezzo, che nasce da un corso su tutt\u2019altro 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.<\/p>\n\n\n\n

La giungla, e le tre persone che ci vivono<\/strong><\/h1>\n\n\n\n

Il punto di partenza \u00e8 una diagnosi che chiunque lavori in un\u2019organizzazione medio-grande riconosce al primo colpo. Dieci anni fa un\u2019azienda grande gestiva qualche decina di servizi; oggi sono migliaia. La crescita ha superato la capacit\u00e0 di governarli a mano, e il risultato \u00e8 quello che il corso chiama la giungla delle API: documentazione assente, sicurezza aggiunta dopo, servizi ombra che crescono al buio.<\/p>\n\n\n\n

Il corso racconta la cosa attraverso tre persone, ed \u00e8 un espediente che funziona meglio di qualunque diagramma.<\/p>\n\n\n\n

Ada<\/strong> \u00e8 una sviluppatrice brava che vorrebbe costruire. Oggi per\u00f2 ha davanti quattro versioni della stessa API di pagamento – payments,<\/em> payments_new,<\/em> payments_v2_final,<\/em> billing_service<\/em><\/mark> – 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.<\/p>\n\n\n\n

Alex<\/strong> \u00e8 il consumatore. Deve rilasciare una funzionalit\u00e0 e dipende dal servizio del team di Ada. Il progetto ha gi\u00e0 due settimane di ritardo. Dal suo punto di vista l\u2019ecosistema API non \u00e8 una libreria di servizi riusabili, \u00e8 una collezione di promesse non mantenute. Cerca in un registro incompleto, chiede a un collega, tira a indovinare.<\/p>\n\n\n\n

Iris<\/strong> \u00e8 la governance. \u00c8 una cartografa che prova a mappare un territorio in movimento con carta e matita. A ogni vulnerabilit\u00e0 annunciata parte un audit manuale che dura settimane, e lei sa gi\u00e0 in partenza che non trover\u00e0 tutti i servizi ombra n\u00e9 tutte le dipendenze obsolete.<\/p>\n\n\n\n

Nessuno dei tre sta sbagliando qualcosa. \u00c8 il sistema attorno a loro che rende la strada giusta anche la pi\u00f9 faticosa.<\/p>\n\n\n\n

Perch\u00e9 il casello produce esattamente ci\u00f2 che vorrebbe impedire<\/strong><\/h1>\n\n\n\n

Qui sta l\u2019osservazione pi\u00f9 utile del corso, e vale la pena riportarla intera perch\u00e9 \u00e8 controintuitiva solo finch\u00e9 non la si \u00e8 vista accadere.<\/p>\n\n\n\n

L\u2019organizzazione del racconto aveva<\/em> un modello di governance: un Architecture Review Board centralizzato, riunione ogni due marted\u00ec, revisione di ogni nuova API sottoposta. Sulla carta garantisce qualit\u00e0 e coerenza. Nella pratica il board \u00e8 sommerso, le revisioni durano settimane o mesi, e gli sviluppatori – che hanno scadenze – costruiscono servizi fuori dai registri ufficiali per aggirare l\u2019attesa.<\/p>\n\n\n\n

Il modello a casello genera quindi una relazione conflittuale: il board diventa \u201cquelli del no\u201d, gli sviluppatori diventano \u201ci cowboy\u201d. E la conseguenza che conta \u00e8 strutturale: il sistema progettato per creare ordine sta producendo disordine<\/strong>, perch\u00e9 costringe le persone a lavorargli attorno.<\/p>\n\n\n\n

La parte che riguarda direttamente chi fa sicurezza operativa \u00e8 il conto che arriva dopo. Ogni servizio costruito nell\u2019ombra non \u00e8 solo una riunione saltata: \u00e8 un punto cieco permanente. Debito di governance che si accumula al buio, dove librerie non aggiornate ed endpoint non cifrati prosperano proprio perch\u00e9 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\u2019indagine su chi possieda<\/em> un servizio che sta fallendo; le integrazioni post-acquisizione che diventano un incubo, perch\u00e9 non si integra ci\u00f2 che non si riesce a trovare; il riuso che muore, con Alex che riscrive ci\u00f2 che Ada aveva gi\u00e0 fatto, raddoppiando manutenzione e superficie d\u2019attacco.<\/p>\n\n\n\n

Il checkpoint nato per garantire l\u2019eccellenza \u00e8 diventato il motore principale della proliferazione e del rischio nascosto.<\/p>\n\n\n\n

Da cancelli a guardrail: quattro workflow<\/strong><\/h1>\n\n\n\n

La proposta \u00e8 tutta in una metafora: i guardrail di un\u2019autostrada non esistono per fermarti, esistono perch\u00e9 tu possa viaggiare a centoventi in sicurezza. Tradotto: incorporare sicurezza e conformit\u00e0 dentro<\/em> il flusso di lavoro, in modo che nessuno debba fermarsi ad aspettare.<\/p>\n\n\n\n

Quattro pilastri, tutti automatizzati.<\/p>\n\n\n\n

Deployment<\/strong><\/h2>\n\n\n\n

Ada parte da un golden path<\/strong>: uno scheletro di progetto approvato che porta gi\u00e0 con s\u00e9 dipendenze consentite, configurazione di logging, integrazione con gli strumenti di monitoraggio e gran parte della checklist di conformit\u00e0. Non deve costruirsi l\u2019impalcatura: comincia dalla logica di business.<\/p>\n\n\n\n

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

E poi il pezzo che rende tutto il resto possibile: la stessa pipeline registra automaticamente il servizio sul gateway e sul catalogo<\/strong>. Nessun passaggio manuale successivo.<\/p>\n\n\n\n

Il risultato \u00e8 la frase attorno a cui ruota l\u2019intero modello: creare un\u2019API conforme \u00e8 adesso pi\u00f9 rapido che crearne una non conforme<\/strong>. Non c\u2019\u00e8 pi\u00f9 nessuna ragione razionale per lavorare fuori dal sistema. \u00c8 cos\u00ec che si elimina lo shadow IT – togliendogli il movente.<\/p>\n\n\n\n

Endorsement<\/strong><\/h2>\n\n\n\n

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

Intanto Alex cerca un servizio di pagamento, trova quello di Ada e vede accanto al nome un badge – diciamo bronze<\/em> – 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<\/em>, cio\u00e8 pronto per la produzione.<\/p>\n\n\n\n

Il punto non \u00e8 il badge: \u00e8 che Ada non \u00e8 bloccata mentre la revisione avviene<\/strong>. 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.<\/p>\n\n\n\n

Reporting<\/strong><\/h2>\n\n\n\n

Poich\u00e9 tutto passa dal gateway, la telemetria arriva da sola su un cruscotto. Iris comincia la giornata guardando lo stato reale dell\u2019ecosistema: quante API sono nate ieri, com\u2019\u00e8 distribuita la qualit\u00e0 tra i reparti, chi \u00e8 fuori standard.<\/p>\n\n\n\n

L\u2019esempio che il corso usa \u00e8 quello giusto: quando esce una vulnerabilit\u00e0 tipo Log4j, Iris non apre un\u2019indagine manuale. Aggiunge una policy, e il cruscotto le mostra immediatamente ogni servizio non conforme.<\/p>\n\n\n\n

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<\/em>: al deploy successivo, di chiunque, il controllo \u00e8 gi\u00e0 attivo. Lo standard si alza da solo, senza che nessuno diventi un collo di bottiglia.<\/p>\n\n\n\n

Retirement<\/strong><\/h2>\n\n\n\n

L\u2019ultimo pilastro \u00e8 quello che di solito non si costruisce, ed \u00e8 quello che tiene in piedi gli altri tre nel tempo.<\/p>\n\n\n\n

Le zombie API<\/strong> sono servizi abbandonati da chi li ha creati e ancora attivi in rete. La definizione del corso \u00e8 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

E questo \u00e8 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<\/strong>. Un ecosistema veloce e sporco torna a essere un ecosistema sporco in un paio d\u2019anni.<\/p>\n\n\n\n

Cosa ci aggiungo io<\/strong><\/h1>\n\n\n\n

Fin qui il corso. Tre osservazioni che mi sembrano pi\u00f9 interessanti del materiale da cui nascono.<\/p>\n\n\n\n

Questo \u00e8 l\u2019inventario che i due articoli precedenti continuavano a invocare.<\/strong> Sia sull\u2019AI security sia sull\u2019MCP, la conclusione tornava sempre la stessa: l\u2019inventario \u00e8 la postura di sicurezza, non puoi proteggere ci\u00f2 di cui ignori l\u2019esistenza. Ma un inventario compilato a mano \u00e8 vero il giorno in cui lo scrivi e falso il mese dopo. L\u2019unico inventario che resta attendibile \u00e8 quello che si aggiorna da solo come effetto collaterale del deploy – che \u00e8 esattamente ci\u00f2 che fa il primo pilastro. Non \u00e8 un dettaglio implementativo: \u00e8 la differenza tra avere un registro e avere una fotografia storica.<\/p>\n\n\n\n

La telemetria per il pensionamento \u00e8 la stessa telemetria che serve per indagare.<\/strong> \u00c8 l\u2019aspetto che mi interessa di pi\u00f9 professionalmente. I dati che permettono di dire \u201cquesto servizio non riceve richieste da novanta giorni\u201d sono gli stessi che permettono di dire \u201cquesto servizio ha ricevuto un picco anomalo di richieste marted\u00ec alle 3 del mattino\u201d. Chi costruisce il quarto pilastro per ragioni di igiene architetturale si ritrova la capacit\u00e0 investigativa in omaggio – e viceversa, chi non ce l\u2019ha scoprir\u00e0 di non averla nel momento peggiore. Aggiungo il corollario che il corso non trae: la domanda che blocca l\u2019avvio di quasi ogni incident response \u00e8 chi possiede questo servizio<\/em>. Un catalogo con proprietario obbligatorio per la registrazione la risolve mesi prima che venga posta.<\/p>\n\n\n\n

E il legame diretto con l\u2019MCP.<\/strong> Un server MCP non \u00e8 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 \u00e8 il prerequisito a monte della governance MCP<\/strong>, non un tema parallelo. Se il catalogo sottostante \u00e8 una giungla, l\u2019MCP 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<\/em>, cio\u00e8 di specifiche OpenAPI accurate e leggibili dalla macchina: governando le API non stai solo governando codice, stai scrivendo il manuale con cui un\u2019AI operer\u00e0 sulla tua azienda. Vero. E vale anche il rovescio: quel registro centrale con i livelli di qualit\u00e0 \u00e8, alla lettera, il controllo che la MCP09 chiede per i server ombra. Chi ha gi\u00e0 costruito l\u2019autostrada per le API ha met\u00e0 del lavoro fatto per gli agenti.<\/p>\n\n\n\n

Sul piano degli standard, il riferimento che il corso cita \u00e8 NIST SP 800-228<\/strong>, 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\u00e9 organizzano i controlli tra fase di pre-runtime e fase di runtime – che \u00e8 poi la stessa distinzione tra i quattro pilastri di cui sopra.<\/p>\n\n\n\n

Qualche cautela, che il corso non mette<\/strong><\/h1>\n\n\n\n

Il materiale \u00e8 dichiaratamente entusiasta, come capita a chi ha visto il modello funzionare. Tre avvertenze da praticante.<\/p>\n\n\n\n

Il golden path \u00e8 un prodotto, e i prodotti si manutengono.<\/strong> 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.<\/p>\n\n\n\n

I livelli di qualit\u00e0 possono diventare teatro.<\/strong> Se gold<\/em> si ottiene superando controlli automatici che nessuno rivede, il badge misura la conformit\u00e0 formale e non l\u2019affidabilit\u00e0. La revisione di dominio del secondo pilastro \u00e8 la parte che impedisce questa deriva, ed \u00e8 anche la prima che verr\u00e0 sacrificata quando si sar\u00e0 di corsa.<\/p>\n\n\n\n

Non \u00e8 un progetto a costo zero n\u00e9 a tempo breve.<\/strong> Tra piattaforma interna, gateway centralizzato, catalogo, motore di policy e pipeline condivise c\u2019\u00e8 un investimento serio. In un\u2019organizzazione piccola il modello va ridotto all\u2019osso: catalogo con proprietario obbligatorio, un solo controllo automatico bloccante, telemetria minima. Meglio un pilastro solo che quattro disegnati su una slide.<\/p>\n\n\n\n

Cosa farei luned\u00ec mattina<\/strong><\/h1>\n\n\n\n
    \n
  1. Conta i tuoi servizi e conta quanti hanno un proprietario nominato.<\/strong> La differenza tra i due numeri \u00e8 la tua esposizione reale, ed \u00e8 anche il tempo che perderai all\u2019inizio del prossimo incidente.<\/li>\n\n\n\n
  2. Cerca i duplicati.<\/strong> Quattro varianti della stessa API sono un sintomo, non un problema estetico: qualcuno ha trovato pi\u00f9 facile riscrivere che riusare, e va capito perch\u00e9.<\/li>\n\n\n\n
  3. Misura la latenza della tua governance.<\/strong> Quanto passa tra la richiesta di revisione e la risposta? Se si misura in settimane, hai gi\u00e0 delle API ombra: non \u00e8 un\u2019ipotesi, \u00e8 aritmetica.<\/li>\n\n\n\n
  4. Definisci i criteri di zombie e applicali una volta sola, a mano.<\/strong> Nessun traffico in novanta giorni, nessun consumatore, nessuna risposta valida. L\u2019elenco che ne esce \u00e8 la riduzione di superficie d\u2019attacco pi\u00f9 economica che tu possa fare quest\u2019anno.<\/li>\n\n\n\n
  5. Sposta un controllo dalla riunione alla pipeline.<\/strong> Uno solo, il pi\u00f9 meccanico che hai. \u00c8 la dimostrazione che serve per ottenere il budget per gli altri.<\/li>\n\n\n\n
  6. Verifica se il tuo catalogo API \u00e8 leggibile da una macchina.<\/strong> Perch\u00e9 il prossimo consumatore dei tuoi servizi, molto probabilmente, non sar\u00e0 una persona.<\/li>\n<\/ol>\n\n\n\n

    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\u00f9 comoda da percorrere. Tutto il resto viene aggirato – non per malizia, ma perch\u00e9 c\u2019\u00e8 una scadenza.<\/p>\n\n\n\n

    Articolo elaborato a partire dagli appunti del corso “Zero Touch API Governance” di AISEC University<\/a> (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.<\/em><\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    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\u00e9 il percorso conforme \u00e8 pi\u00f9 scomodo di quello che lo aggira. Restava una domanda, ed \u00e8 quella di oggi. Le due … Leggi tutto “La governance che nessuno ha interesse ad aggirare”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[114,12,14],"tags":[108,141,137],"class_list":["post-30452","post","type-post","status-publish","format-standard","hentry","category-ai","category-cyber-security","category-digital-forensics","tag-ai","tag-api","tag-mcp"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/30452","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=30452"}],"version-history":[{"count":8,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/30452\/revisions"}],"predecessor-version":[{"id":30464,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/30452\/revisions\/30464"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=30452"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=30452"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=30452"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}