Threat modeling per app di AI generativa e agentica

Introduction: perché è importante

Il threat modeling aiuta i team a identificare cosa può andare storto in anticipo—prima che si verifichino guasti nel mondo reale o exploit avversari. Microsoft osserva che le applicazioni di AI (soprattutto i sistemi generativi e agentici) violano molte assunzioni del software tradizionale e deterministico, quindi i team di sicurezza devono adattare l’approccio di threat modeling per tenere conto di output probabilistici, superfici d’attacco ampliate e danni incentrati sulle persone.

What’s new: come l’AI cambia il panorama delle minacce

Microsoft evidenzia tre caratteristiche che spostano in modo sostanziale il threat modeling per l’AI:

• Nondeterminism: lo stesso input può produrre output diversi tra esecuzioni, richiedendo l’analisi di intervalli di comportamento probabile—including esiti rari ma ad alto impatto.
• Instruction-following bias: i modelli sono ottimizzati per essere utili, il che li rende più suscettibili a prompt injection, coercizione e manipolazione—soprattutto quando dati e istruzioni condividono lo stesso canale di input.
• System expansion via tools and memory: i sistemi agentici possono chiamare API, mantenere stato e attivare workflow in modo autonomo. Quando qualcosa va storto, i guasti possono propagarsi rapidamente tra i componenti.

Queste proprietà rimodellano rischi noti in nuove forme, tra cui:

• Direct and indirect prompt injection (incluso tramite contenuti esterni che il modello recupera)
• Tool misuse and privilege escalation through chaining
• Silent data exfiltration (output o chiamate a tool che fanno trapelare informazioni sensibili)
• Confidently wrong outputs trattati come fatti
• Human-centered harms come erosione della fiducia, eccessiva dipendenza, rafforzamento dei bias e disinformazione persuasiva

Threat model from assets, not attacks

Una raccomandazione chiave è iniziare definendo in modo esplicito cosa si sta proteggendo—perché gli asset dell’AI vanno oltre database e credenziali. Gli asset tipici, specifici dell’AI, includono:

• User safety (soprattutto quando le indicazioni dell’AI influenzano le azioni)
• User trust negli output e nel comportamento
• Privacy/security of sensitive business and user data
• Integrity of prompts, instructions, and contextual data
• Integrity of agent actions and downstream effects

Questo inquadramento asset-first forza anche decisioni di policy fin dall’inizio: Quali azioni non dovrebbe mai compiere il sistema? Alcuni esiti possono essere inaccettabili indipendentemente dal beneficio.

Model the system you actually built

Microsoft sottolinea che il threat modeling per l’AI deve riflettere l’operatività reale, non diagrammi idealizzati. Prestare particolare attenzione a:

• Come gli utenti interagiscono realmente con il sistema
• Come prompt, memoria e contesto vengono assemblati e trasformati
• Quali fonti esterne vengono ingerite e quali assunzioni di trust esistono
• Quali tool/API il sistema può invocare (e con quali autorizzazioni)
• Se le azioni sono reattive o autonome, e dove viene applicata l’approvazione umana

Nei sistemi di AI, la prompt assembly pipeline diventa un confine di sicurezza di primo livello—recupero del contesto, trasformazione, persistenza e riuso sono i punti in cui si accumulano assunzioni di trust “silenziose”.

Impact on IT admins and platform owners

Per gli amministratori che distribuiscono soluzioni di AI (app personalizzate, Copilot o workflow agentici), queste indicazioni ribadiscono che i controlli devono coprire:

• L’intero percorso data-to-prompt-to-action (non solo l’hosting del modello)
• Autorizzazioni e guardrail per l’accesso ai tool e le automazioni downstream
• Monitoraggio operativo per output inattesi, chiamate ai tool insolite e pattern di exfiltration

Action items / next steps

• Inventariare gli asset di AI: includere fiducia, sicurezza e integrità di istruzioni/contesto.
• Mappare la prompt pipeline end-to-end: fonti, retrieval, trasformazione, memoria e riuso.
• Vincolare le autorizzazioni dei tool e richiedere approvazione umana per azioni ad alto impatto.
• Testare injection e misuse: includere indirect prompt injection tramite contenuti recuperati.
• Pianificare gli incidenti: mitigare l’overreliance con segnali UX, passaggi di validazione e percorsi di escalation.