Threat Modeling für generative KI-Apps anpassen

Introduction: why this matters

Threat Modeling hilft Teams, frühzeitig zu erkennen, was schiefgehen kann – bevor es in der Praxis zu Ausfällen oder adversarial exploits kommt. Microsoft weist darauf hin, dass KI-Anwendungen (insbesondere generative und agentische Systeme) viele Annahmen traditioneller, deterministischer Software aufbrechen. Daher müssen Security-Teams ihren Threat-Modeling-Ansatz anpassen, um probabilistische Outputs, erweiterte Attack Surfaces und menschenzentrierte Schäden zu berücksichtigen.

What’s new: how AI changes the threat landscape

Microsoft hebt drei Eigenschaften hervor, die Threat Modeling für KI grundlegend verändern:

• Nondeterminism: Derselbe Input kann über mehrere Runs hinweg unterschiedliche Outputs erzeugen. Das erfordert eine Analyse von Bandbreiten wahrscheinlichen Verhaltens – einschließlich seltener, aber hochwirksamer Ergebnisse.
• Instruction-following bias: Modelle sind darauf optimiert, hilfreich zu sein, und sind dadurch anfälliger für prompt injection, Zwang und Manipulation – besonders wenn Daten und Instruktionen denselben Input-Kanal teilen.
• System expansion via tools and memory: Agentische Systeme können APIs aufrufen, State behalten und Workflows autonom auslösen. Wenn etwas schiefgeht, können sich Fehler schnell über Komponenten hinweg verstärken.

Diese Eigenschaften formen bekannte Risiken in neue Varianten um, darunter:

• Direct and indirect prompt injection (u. a. über externe Inhalte, die das Modell abruft)
• Tool misuse and privilege escalation through chaining
• Silent data exfiltration (Outputs oder Tool-Calls, die sensitive Informationen preisgeben)
• Confidently wrong outputs, die als Fakten behandelt werden
• Human-centered harms wie Vertrauensverlust, Überabhängigkeit, Verstärkung von Bias und überzeugende Desinformation

Threat model from assets, not attacks

Eine zentrale Empfehlung ist, mit der expliziten Definition dessen zu beginnen, was Sie schützen – weil KI-Assets über Datenbanken und Credentials hinausgehen. Typische KI-spezifische Assets sind:

• User safety (insbesondere wenn KI-Empfehlungen Handlungen beeinflussen)
• User trust in Outputs und Verhalten
• Privacy/Security sensibler Business- und User-Daten
• Integrity von Prompts, Instruktionen und Kontextdaten
• Integrity von Agent Actions und nachgelagerten Effekten

Dieses Asset-first-Framing erzwingt außerdem frühe Policy-Entscheidungen: Welche Aktionen darf das System niemals ausführen? Manche Outcomes können unabhängig vom potenziellen Nutzen inakzeptabel sein.

Model the system you actually built

Microsoft betont, dass KI-Threat Modeling den realen Betrieb abbilden muss – nicht idealisierte Diagramme. Achten Sie besonders auf:

• Wie User tatsächlich mit dem System interagieren
• Wie Prompts, Memory und Context zusammengestellt und transformiert werden
• Welche externen Quellen ingestiert werden und welche Trust-Assumptions gelten
• Welche Tools/APIs das System aufrufen kann (und mit welchen Permissions)
• Ob Actions reaktiv oder autonom sind – und wo Human Approval erzwungen wird

In KI-Systemen wird die prompt assembly pipeline zur erstklassigen Security Boundary: Context Retrieval, Transformation, Persistenz und Reuse sind die Bereiche, in denen sich „stille“ Trust-Assumptions ansammeln.

Impact on IT admins and platform owners

Für Administratoren, die KI-Lösungen bereitstellen (Custom Apps, Copilots oder agentische Workflows), unterstreicht diese Guidance, dass Controls Folgendes abdecken müssen:

• Den gesamten data-to-prompt-to-action-Pfad (nicht nur Model Hosting)
• Permissions und Guardrails für tool access und nachgelagerte Automationen
• Operational Monitoring für unexpected outputs, ungewöhnliche Tool-Calls und Exfiltration-Patterns

Action items / next steps

• Inventory AI assets: Trust, Safety sowie Instruction/Context Integrity mit erfassen.
• Map the prompt pipeline end-to-end: Sources, Retrieval, Transformation, Memory und Reuse.
• Constrain tool permissions und human approval für Actions mit hohem Impact erzwingen.
• Test for injection and misuse: auch indirekte Prompt Injection über abgerufene Inhalte einbeziehen.
• Plan for accidents: Überabhängigkeit durch UX-Cues, Validierungsschritte und Escalation Paths reduzieren.