Tre piani che l’esame ti chiede di non confondere

Un sistema che esegue istruzioni scritte in linguaggio naturale ha una superficie di attacco che nessun firewall copre: il testo stesso è codice eseguibile. Come architetto devi separare tre piani che vengono spesso trattati come sinonimi.

Il primo è il content filter, che in Microsoft Foundry si progetta oggi come guardrail: una raccolta nominata di control, dove ogni control definisce un rischio da rilevare, uno o più intervention point dove cercarlo e l’azione da eseguire. I rischi di contenuto (Hate, Sexual, Self-harm, Violence) usano una soglia di severità Low, Medium o High; il valore Off è disponibile solo per i clienti approvati tramite il processo di modified guardrails. Per impostazione predefinita i modelli usano il guardrail Microsoft.DefaultV2.

Il secondo piano è il rilevamento della prompt manipulation, affidato ai Prompt Shields. Non governa la tossicità del contenuto: cerca istruzioni ostili, cioè tentativi di riscrivere le regole del sistema.

Il terzo è l’abuse monitoring, che non è un controllo che tu configuri per proteggere l’utente finale: è il meccanismo con cui Microsoft rileva pattern ricorrenti di uso in violazione del Code of Conduct. Si compone di Content Classification, Abuse Pattern Capture, Review and Decision (automatica e, in alcuni casi, umana da parte di dipendenti Microsoft autorizzati tramite Secure Access Workstations con approvazione Just-In-Time) e Notification and Action. Un cliente che non può permettere l’archiviazione e la revisione umana dei prompt richiede il modified abuse monitoring, con criteri di Limited Access. Attenzione al tranello: quella richiesta è distinta dalla richiesta per disattivare i filtri. Sono due processi separati, e rispondere “disattivo il content filter” a un vincolo di riservatezza è l’errore che l’esame premia con zero punti. Riferimento: /azure/foundry/openai/concepts/abuse-monitoring.

Dove intercettare: gli intervention point sono una scelta di architettura

Foundry supporta quattro intervention point, e la scelta fra loro è la vera decisione progettuale. User input è il prompt inviato al modello o all’agente. Tool call (preview, solo agenti) è l’azione che l’agente propone di eseguire, argomenti e dati inclusi. Tool response (preview, solo agenti) è ciò che un tool restituisce, prima che entri nella memoria dell’agente. Output è la risposta finale all’utente. Le azioni sono due: Annotate, che si limita ad annotare, e Annotate and block. Sugli agenti solo Annotate and block è applicabile.

Due vincoli architetturali pesano più della configurazione. Primo: la documentazione afferma che il guardrail agentico “fully overrides the model’s guardrail” — i rischi si valutano in base al guardrail assegnato all’agente, non a quello del modello sottostante, quindi un modello severamente filtrato non protegge un agente configurato in modo permissivo. Secondo: i control su tool call e tool response funzionano solo con i tool che supportano la moderazione (fra gli altri Azure AI Search, Azure Functions, OpenAPI, SharePoint Grounding, Fabric Data Agent, Bing Grounding, Bing Custom Search, Browser Automation). Se l’agente usa un tool fuori da quell’elenco, quel control semplicemente non ha effetto. Va infine messo a budget un costo di latenza di circa 50-100 ms per intervention point.

Attacco diretto e attacco indiretto: difesa in profondità

I Prompt Shields coprono due famiglie. Gli user prompt attacks (in precedenza jailbreak risk detection) sono tentativi dell’utente di cambiare le regole di sistema, di incorporare finte conversazioni, di role-play o di codifica; si intercettano allo user input. I document attacks sono istruzioni nascoste in contenuto di terze parti — documenti, email, pagine web — e si intercettano sia allo user input sia alla tool response. Come difesa aggiuntiva esiste lo Spotlighting, in preview, che marca i documenti con codifica base-64 perché il modello li tratti come meno affidabili: aumenta i token, può far superare i limiti di input, non si applica agli agenti ed è disattivato per impostazione predefinita.

Scenario tipico. Una compagnia assicurativa costruisce sul Microsoft Foundry Agents service un agente che legge gli allegati inviati dai clienti e apre una pratica chiamando un’API interna. Il vincolo posto dalla compliance è che nessun documento in ingresso possa provocare una scrittura senza conferma umana. La risposta corretta non è “alzo la severità del filtro”: è un control per Indirect attack alla tool response con azione Annotate and block, human-in-the-loop sulle azioni ad alto impatto, endpoint esposti come API a scopo ristretto anziché accesso diretto al database, e una agent identity in Microsoft Entra ID con assegnazioni RBAC minime sulla risorsa. Ricorda che pubblicare un agente gli assegna una identità distinta: i ruoli assegnati all’identità condivisa del progetto non vengono ereditati.

Su Microsoft Copilot Studio il piano è diverso: qui esiste un security scan automatico che avverte il maker prima della pubblicazione quando vengono modificate le impostazioni sicure predefinite, per esempio l’autenticazione portata a No authentication, le credenziali dei connector portate a Maker-provided credentials, o la condivisione dell’agente con tutta l’organizzazione.

Misurare la resistenza: testing, evaluation, monitoring

Tre attività che l’esame tiene rigorosamente separate. Il testing avversariale si fa con l’AI Red Teaming Agent, che usa PyRIT e i Risk and Safety Evaluations per simulare attacchi e produrre un Attack Success Rate; le categorie agentiche (prohibited actions, sensitive data leakage, task adherence) sono disponibili solo in cloud red teaming, e i risultati vanno riletti perché non sono deterministici. L’evaluation misura con evaluator riutilizzabili, fra cui builtin.indirect_attack (XPIA, solo modelli) e builtin.code_vulnerability, e va integrata nelle pipeline CI/CD. Il monitoring in produzione è un’altra cosa: le tracce e le metriche dell’osservabilità di Foundry per il comportamento, e Microsoft Defender for Cloud con la threat protection per i carichi AI — in stato generally available, che lavora insieme ai Prompt Shields e convoglia gli avvisi in Defender XDR. Uno non sostituisce l’altro: il red teaming non ti dice che cosa sta succedendo ora, e la telemetria non ti dice che cosa succederebbe se qualcuno ci provasse.