Un carico di lavoro AI su Azure ha tre punti di intervento: davanti al modello (il gateway), dentro al modello o all’agente (i guardrail) e sopra tutto (rilevamento e postura in Defender for Cloud). Nessuno sostituisce gli altri.
AI Gateway: mettere API Management davanti a Foundry
Nel portale di Microsoft Foundry: Manage > AI Gateway > Add AI Gateway, scegli la risorsa e decidi se creare una nuova istanza APIM o riusarne una.
Create new crea uno SKU Basic v2, da sviluppo e test; per la produzione serve Standard v2 o Premium v2. Per riusare un’istanza, deve stare nello stesso tenant e nella stessa sottoscrizione della risorsa Foundry, essere in un tier v2 e vederti almeno come API Management Service Contributor: se non compare nell’elenco, il motivo è quasi sempre uno di questi tre.
Il gateway si abilita a livello di risorsa, non di progetto: i progetti nuovi lo ereditano acceso, quelli esistenti vanno aggiunti a mano con Add project to gateway. È la causa numero uno del «le richieste bypassano il gateway». I limiti di token si impostano per progetto. Per verificare: in APIM Monitoring > Metrics, metrica Requests; i log via diagnostic setting verso Log Analytics.
ApiManagementGatewayLogs
| where TimeGenerated > ago(1h)
Due codici da riconoscere: chi supera il limite TPM riceve 429 Too Many Requests, chi esaurisce la quota 403 Forbidden.
Sotto restano le policy dell’AI gateway: llm-token-limit per limiti e quote per chiave, llm-emit-token-metric per le metriche per consumatore, il semantic caching, llm-content-safety per moderare i prompt, i backend con bilanciamento e circuit breaker. Il gateway governa però solo il traffico che ci passa: non è un confine di rete, quello resta a private endpoint e firewall.
Defender for AI Service nel Cloud Workload Protection
Si accende con gli altri piani: Defender for Cloud > Environment settings > sottoscrizione > pagina dei piani, interruttore AI services su On, con ruolo Owner o Contributor. È GA, protegge i carichi Microsoft Foundry, lavora con Azure AI Content Safety Prompt Shields e la threat intelligence Microsoft per avvisi su jailbreak, fuga di dati, avvelenamento e furto di credenziali, e li riversa in Defender XDR.
Limiti dichiarati: solo token di testo (immagini e audio non vengono analizzati) e solo cloud commerciali — niente Azure Government, 21Vianet o AWS collegato.
Tre componenti si abilitano separatamente da Settings:
- Suspicious prompt evidence: allega agli avvisi i frammenti sospetti di prompt e risposta, coi dati sensibili redatti. Se lo lasci spento il rilevamento continua: viene solo mascherato il contenuto.
- Data security for AI interactions: porta prompt e risposte in Microsoft Purview per classificazione SIT, audit, insider risk ed eDiscovery. Richiede una licenza Purview non inclusa nel piano, non copre gli agenti Foundry e vale solo per chiamate autenticate con Entra ID e contesto utente; altrimenti le interazioni finiscono solo in Purview Audit e in Activity explorer.
- AI model security: scansione dei modelli registrati per malware, operatori non sicuri, segreti esposti.
Guardrail in Foundry: quattro punti di intervento
Un guardrail è una collezione di controlli; ogni controllo definisce un rischio, il punto in cui intervenire e l’azione. I punti sono quattro: user input, tool call e tool response (in anteprima, solo per gli agenti), output. È la differenza fra filtrare un modello e proteggere un agente: il modello vede prompt e risposta, l’agente ha in mezzo le chiamate agli strumenti.
L’ereditarietà è la parte che fa sbagliare. Il guardrail assegnato all’agente sovrascrive completamente quello del modello sottostante: non si sommano. Senza assegnazione l’agente eredita quello del deployment del modello; il predefinito Microsoft.DefaultV2 vale solo se lo usa anche il modello o se lo assegni tu. Alcuni rischi in anteprima non valgono per gli agenti (Spotlighting, Groundedness): nel guardrail di un agente non hanno effetto. Sui modelli l’azione può essere Annotate, sugli agenti solo Annotate and block. Le severità sono Low, Medium, High; Off è riservato ai clienti approvati. Serve il ruolo Foundry Account Owner, e il sistema copre gli agenti del Foundry Agent Service, non ogni agente registrato nel control plane.
Sugli hosted agent il guardrail si aggancia con rai_config.rai_policy_name, che vuole l’ID ARM completo della policy RAI, non il nome. Se ometti rai_config, l’agente gira senza guardrail di contenuto. Nello stesso oggetto vivono i network egress control in anteprima: regole ordinate per host, prima corrispondenza vince, default Deny per una allow list, valutazione fail-closed, massimo 480 regole. Distribuisci in modalità Audit, leggi le decisioni, poi passa a Enforce.
Monitorare con il cruscotto Data and AI security
Il cruscotto Data and AI security unisce risorse dati e AI in una vista sola. Per vederlo pieno servono più piani accesi: Defender CSPM con l’estensione sensitive data discovery, Defender for Storage, Defender for Databases e la threat protection per i carichi AI. È abilitato per sottoscrizione, richiede il provider Microsoft.Security registrato e il ruolo Security explorer.
La sezione AI closer look è quella che conta: AI discovery con l’inventario delle risorse AI, AI threat protection con i prompt analizzati e gli avvisi per severità, query pronte nel security explorer, e le risorse esposte a internet usate per il grounding. Il contesto di postura arriva da Defender CSPM — AI BOM, raccomandazioni, attack path — con un aggiornamento chiave: dal 1° luglio 2026 la scoperta e la postura a livello di agente richiedono una licenza Microsoft Agent 365, mentre Defender CSPM continua a scoprire account e progetti Foundry.