Vom Prompt zum Pull Request: Threat Modeling für von KI-Agenten geschriebenen Code

Ein Coding-Agent kann ein Issue in einen glaubwürdigen Pull Request verwandeln: Er liest das Repository, schlägt einen Plan vor, ändert Dateien, aktualisiert Tests und bereitet ein Diff für das Review vor. Das konkrete Risiko besteht darin, dass das Team nur bewertet, ob die Funktion läuft, ohne sich zu fragen, ob der ursprüngliche Prompt tatsächlich Daten, Rollen, mögliche Missbrauchsszenarien, Vertrauensgrenzen (Trust Boundaries) und Auswirkungen auf die Produktion beschreibt.

Genau hier setzt Threat Modeling an: nicht als bürokratische Übung, sondern als leichtgewichtige Methode, um zu verstehen, was sich ändert, was schiefgehen kann, welche Kontrollen erforderlich sind und ob die durchgeführte Überprüfung vor dem Merge, Deployment oder Go-Live ausreicht.

Für CTOs, Tech Leads und Security Champions lautet die Frage nicht: „Können wir KI-Agenten zum Schreiben von Code verwenden?“. Die nützliche Frage ist: Wie verwandeln wir Prompts, Agentenpläne und Pull Requests in eine nachvollziehbare Risikoentscheidung?

Warum sich Threat Modeling durch KI-generierten Code verändert

Beim traditionellen Applikations-Threat-Modeling geht man von Features, Assets, Akteuren, Datenflüssen und Vertrauensgrenzen aus. Bei von KI-Agenten geschriebenem Code muss eine Ebene hinzugefügt werden: der Weg vom Prompt zum Diff.

Eine Anforderung wie „Team-Einladungen hinzufügen“ kann ein Datenmodell, APIs, E-Mails, temporäre Token, Rollen, Admin-Seiten, Tests, Umgebungsvariablen und eine Migration generieren. Jedes Element führt unterschiedliche Bedrohungen ein: wiederverwendbare Einladungen, zu lange Token in Logs, Rollen, die nur im Frontend angewendet werden, ungeschützte Endpunkte, unvollständige Mandantentrennung (Tenant Isolation), E-Mail-Spoofing, Abhängigkeiten, die ohne Review hinzugefügt wurden. Der Prompt enthält dies selten, da der Agent die Lücken mit plausiblen Konventionen füllt. Threat Modeling dient dazu, diese Lücken explizit zu machen, bevor sie zu akzeptiertem Code werden.

Die vier Fragen für jeden KI-generierten PR

OWASP fasst Threat Modeling in vier Fragen zusammen: Was bauen wir, was kann schiefgehen, was tun wir dagegen und haben wir genug getan? Im Kontext von KI-Coding müssen diese Fragen auf Prompts, Pläne, Diffs und Laufzeit angewendet werden.

Frage	Bedeutung im Workflow mit KI-Agenten
Was bauen wir?	Welche Aufgabe hat der Agent erhalten, welche Dateien wurden geändert, welche Daten und Systeme sind betroffen?
Was kann schiefgehen?	Welcher Missbrauch wird bei Rollen, Daten, APIs, Tools, Pipelines und exponierten Oberflächen möglich?
Was tun wir dagegen?	Welche Kontrollen werden in Code, Tests, Konfiguration, Review, Pipeline oder Prozess implementiert?
Haben wir genug getan?	Welche Nachweise blockieren den Merge, welche Risiken werden akzeptiert und wer verantwortet sie?

Diese Struktur vermeidet zwei häufige Fehler: Threat Modeling als abstraktes Meeting zu behandeln oder es auf eine generische Checkliste von Schwachstellen zu reduzieren.

Ausgangspunkt: Assets, Daten und reale Akteure

Der erste Schritt besteht nicht darin, das Diff Zeile für Zeile zu lesen, sondern zu verstehen, welche Assets in den Bereich der Änderung fallen: personenbezogene Daten, Kundendokumente, Zahlungen, administrative Rollen, Token, interne APIs, Webhooks, Repositories, Pipelines, Logs, Speicher, Datenbanken und Cloud-Dienste.

Dann braucht man die Akteure. Es reicht nicht, zwischen „Benutzer“ und „Admin“ zu unterscheiden: In einem realen Feature kann es eingeladene Benutzer, gesperrte Benutzer, Owner, Teil-Admins, Service-Accounts, externe Integrationen, Mitglieder eines anderen Mandanten, deaktivierte Kunden, Support-Operatoren, geplante Jobs und anonyme Angreifer geben. Eine minimale Akteur-Aktion-Ressourcen-Matrix hilft weitaus mehr als ein generisches Review. Für jede Rolle muss man sich fragen: Welche Ressourcen kann sie lesen, erstellen, ändern, löschen oder exportieren? Überprüft das Backend dies wirklich, oder hat der Agent die Kontrolle nur im Interface implementiert?

Datenfluss zeichnen, auch wenn es einfach gehalten ist

Das Threat Model muss nicht zwingend ein perfektes Diagramm erzeugen, aber es muss Datenflüsse, Datenspeicher, Prozesse, externe Entitäten und Vertrauensgrenzen sichtbar machen. Wenn ein PR Frontend, API-Routen, Datenbanken, Objektspeicher, E-Mail-Provider, Webhooks und Deployment-Pipelines durchläuft, ist das Risiko nicht für alle Komponenten gleich.

Bei KI-generiertem Code muss der Datenfluss auch oft vergessene Elemente enthalten: Agenten-Prompts, Chat-Verläufe, Tool-Outputs, Build-Logs, Umgebungsvariablen, Secret Manager, Test-Fixtures, Seeds, Snapshots und Deployment-Artefakte. Ein Geheimnis, das in den Prompt oder ein Log kopiert wurde, erscheint nicht immer im finalen Diff, kann aber dennoch eine Rotation erfordern.

Die wichtigste Grenze ist der Punkt, an dem ein nicht vertrauenswürdiger Input in eine vertrauenswürdige Komponente gelangt. Ein Wert aus Formularen, Tickets, Dokumenten, Webhooks, hochgeladenen Dateien, LLM-Outputs oder externen Tools muss validiert werden, bevor er zu einer Abfrage, einem Befehl, einer Autorisierung, einer E-Mail, einer Entscheidung oder einer nachgelagerten Aktion wird.

Abuse Cases schreiben, nicht nur User Stories

User Stories beschreiben die beabsichtigte Nutzung; Abuse Cases beschreiben, was ein Benutzer, ein Mandant, eine Integration oder ein bösartiger Inhalt tun kann, wenn das System außerhalb der vorgesehenen Sequenz verwendet wird. Einige nützliche Beispiele für einen KI-generierten PR:

Ein Benutzer ändert die ID in der URL und liest einen Datensatz eines anderen Mandanten.
Eine abgelaufene Einladung wird wiederverwendet, um Zugriff zu erhalten.
Ein Webhook wird wiederholt oder mit einem falschen Schlüssel signiert.
Eine Read-Only-Rolle ruft direkt die Änderungs-API auf.
Eine hochgeladene Datei enthält Payloads, die in HTML, Parsern oder Speichern landen.
Eine Prompt-Injection in einem Ticket veranlasst den Agenten, eine Richtlinie zu ändern oder ein Tool zu verwenden.
Eine Migration legt Testdaten oder sensible Felder in der Produktion offen.

STRIDE bleibt als Anregung nützlich — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — aber bei KI-generiertem Code muss es mit konkreten Fällen verknüpft werden, anstatt es als dekoratives Akronym zu verwenden.

Den Plan des Agenten vor dem Diff bewerten

Viele Teams beginnen mit dem Review, wenn der Pull Request fertig ist. Bei KI-Agenten lohnt es sich, früher anzusetzen: Wenn der Agent einen Plan vorschlägt, der Auth, Rollen, Daten, Cloud, CI/CD, Geheimnisse oder Abhängigkeiten betrifft, muss das Threat Model beginnen, bevor das Diff zu groß wird.

Der Plan des Agenten sollte mit präzisen Fragen gelesen werden: Erstellt er neue Endpunkte oder legt er bisher nicht existierende Routen offen? Ändert er Middleware, Richtlinien, Berechtigungsprüfungen oder Rollen? Fügt er Abhängigkeiten, Skripte, Workflows oder Deployment-Befehle hinzu? Ändert er Tests so, dass sie nur seine eigene Implementierung bestätigen? Geht er davon aus, dass eine clientseitige Kontrolle ausreicht? Verwendet er echte Daten, Logs oder Geheimnisse, um die Aufgabe zu erledigen? Wenn die Antwort auf auch nur eine dieser Fragen „Ja“ lautet, muss der PR aufgeteilt oder als risikoreich markiert werden, da ein effektives Review eine Textkorrektur nicht gleich behandeln kann wie eine Änderung, die Autorisierungen, Datenbanken und Pipelines durchläuft.

Bedrohungen, Kontrollen und Tests verknüpfen

Ein nützliches Threat Model produziert überprüfbare Kontrollen. Wenn die Bedrohung „Benutzer von Mandant A liest Daten von Mandant B“ lautet, ist die Kontrolle nicht „Berechtigungen verwalten“: Es ist eine serverseitige Richtlinie, eine nach Mandanten gefilterte Abfrage, Tests mit zwei unterschiedlichen Mandanten, Logging des verweigerten Zugriffs und ein Middleware-Review.

Wenn die Bedrohung „wiederverwendbares Einladungs-Token“ lautet, können die Kontrollen Ablaufdatum, Einmalverwendung, Bindung an E-Mail oder Mandant, Hashing des Tokens im Ruhezustand, Rate Limiting und Audit-Logs umfassen. Wenn die Bedrohung „Prompt-Injection durch Tickets“ lautet, sind die Kontrollen die Trennung von Daten und Anweisungen, menschliche Bestätigung für sensible Tools, Allowlisten für Aktionen und Tests mit feindseligen Inhalten.

Scanner und automatische Tests helfen, beweisen aber nicht allein, dass Geschäftslogik, Mandantentrennung, Autorisierungen und Vertrauensgrenzen im realen Kontext korrekt sind.

Definieren, was Merge und Go-Live blockiert

Threat Modeling sollte nicht mit „Wir haben über die Risiken gesprochen“ enden: Es muss zu Entscheidungen führen. Den Merge oder das Go-Live blockieren Nachweise, die Daten offenlegen, Privilegienerweiterungen ermöglichen, Autorisierungen umgehen, Geheimnisse enthüllen, Speicher oder Datenbanken öffentlich machen, Pipelines schwächen, Sicherheitskontrollen deaktivieren oder kritische, nicht bewertete Abhängigkeiten einführen.

Andere Punkte können als geplante Sanierung (Remediation) behandelt werden, aber nur mit klaren Verantwortlichen, Daten und Restrisiken. Die Verbesserung des Loggings, das Hinzufügen von Alerts, die Stärkung der Dokumentation oder eine granularere Rollenmatrix können geplant werden; eine unsichere Zugriffskontrolle vor dem Go-Live zu akzeptieren, ist hingegen keine Option.

Threat-Modeling-Checkliste für KI-generierte PRs

Identifiziere den ursprünglichen Prompt/Task, den verwendeten Agenten oder das Tool sowie die generierten oder geänderten Teile.
Liste betroffene Assets, echte Daten, Rollen, Mandanten, externe Systeme und Geheimnisse auf.
Zeichne einen minimalen Datenfluss mit Vertrauensgrenzen, Prozessen, Datenspeichern und externen Entitäten.
Schreibe feature-spezifische Abuse Cases, nicht nur generische Schwachstellen.
Überprüfe objektbasierte Autorisierungen und Mandantentrennung mit verschiedenen Benutzern.
Prüfe, ob der PR Middleware, Richtlinien, Rollen, Callbacks, Redirects, CORS oder Sitzungen ändert.
Trenne Code-Review, Pipeline-Review, Abhängigkeits-Review und Test-Review.
Suche nach Geheimnissen in Prompts, Logs, Repositories, Builds, Workflows und Konfigurationen.
Fordere negative Tests ein, die aus den Bedrohungen abgeleitet sind, nicht nur Tests für den „Happy Path“.
Dokumentiere, was den Merge blockiert, was das Go-Live blockiert und was als akzeptiertes Risiko verbleibt.

Wie man die Methode in den Entwicklungszyklus integriert

Threat Modeling für KI-Coding muss leichtgewichtig und wiederholbar sein. Es braucht keine lange Sitzung für jeden Commit, aber klare Schwellenwerte: Ein PR, der nur Text oder Layout betrifft, kann dem normalen Fluss folgen, während ein PR, der Auth, Daten, APIs, Zahlungen, Cloud, CI/CD, Geheimnisse, Rollen oder Agenten-Tools betrifft, eine strengere Kontrolle auslösen muss.

Im praktischen Prozess sollte der Task Sicherheitsvorgaben enthalten; der Plan des Agenten sollte bei sensiblen Bereichen genehmigt werden; der PR sollte klein sein; Tests sollten Abuse Cases abdecken; das Review sollte technische Verantwortliche haben; die finale Entscheidung sollte nachvollziehbar sein. Wenn die Nutzung von KI-Agenten kontinuierlich wird, wird dies zu einem Thema des Software Assurance Lifecycle: Entwicklungsregeln, Branch-Protection, Security-Gates, Ownership, Nachweise, Sanierung und wiederkehrende Kontrollen.

Wann eine unabhängige Überprüfung einzubeziehen ist

Eine interne Überprüfung kann für isolierte Änderungen ausreichen, ohne echte Daten, ohne Rollen, ohne exponierte APIs und mit erfahrenen Reviewern. Eine unabhängige Überprüfung ist hingegen erforderlich, wenn der von KI generierte oder geänderte Code in ein Produkt einfließt, das von Kunden, Mitarbeitern oder Partnern genutzt wird, oder wenn der PR Autorisierungen, Daten, Pipelines, Cloud, Zahlungen, Geheimnisse oder kritische Logik betrifft.

Szenario	Hauptrisiko	Empfohlene Kontrolle
KI-generierter PR zu Auth, Rollen, APIs, Queries, Geheimnissen oder Abhängigkeiten	Schwachstellen oder Regressionen im Code	Code Review
Kontinuierliche Einführung von Coding-Agenten im Engineering-Zyklus	Nicht wiederholbare Kontrollen bei Tasks, PRs und Releases	Software Assurance Lifecycle
Entscheidung über Go-Live, Restrisiko, geschäftliche Auswirkungen oder Compliance	Risiko nicht priorisiert oder ohne Verantwortlichen akzeptiert	Risk Assessment
Architektur, Datenflüsse, Vertrauensgrenzen und komplexe Integrationen	Schwache Design-Annahmen	Secure Architecture Review
Apps oder APIs, die bereits Benutzern und Kunden ausgesetzt sind	Von außen missbrauchbares Verhalten	Web Application Penetration Testing

Die Wahl sollte kein Standardpaket sein. Wenn das Risiko im Diff liegt, ist ein Code Review erforderlich. Wenn das Risiko im Prozess der Agenten-Einführung liegt, ist ein Software Assurance Lifecycle nötig. Wenn das Team über Restrisiken, Prioritäten und Auswirkungen entscheiden muss, ist ein Risk Assessment erforderlich. Wenn die Änderung Architektur, Datenflüsse und Integrationen durchläuft, ist ein Review des Designs notwendig.

Vorbereitung der Nachweise

Für eine effektive Überprüfung benötigt man Repositories, Pull Requests, Aufgabenbeschreibungen, Prompts oder Ausgangs-Issues, eine Liste der verwendeten Agenten oder Tools, generierte oder geänderte Teile, Anwendungsrollen, Datenschemata, exponierte APIs, Integrationen, CI/CD-Workflows, Umgebungsvariablen, Hauptabhängigkeiten und verfügbare Umgebungen.

Nützlich sind auch Prozessnachweise: Wer hat den Plan des Agenten genehmigt, wer hat das Diff geprüft, welche Tests wurden hinzugefügt, welche Bedrohungen wurden berücksichtigt, welche Risiken wurden akzeptiert und welche Sanierungen wurden geplant? Diese Informationen verhindern ein „blindes“ Review, da der Code nicht immer erzählt, warum eine Entscheidung getroffen wurde, welche Annahmen der Agent gemacht hat oder welches Risiko das Team zu akzeptieren glaubte.

Häufig gestellte Fragen

Ist Threat Modeling auch für einen einzelnen KI-generierten PR sinnvoll?
Ja, wenn der PR Daten, Rollen, APIs, Geheimnisse, Zahlungen, Pipelines, Cloud oder Geschäftslogik betrifft. Für kleine Änderungen reicht ein leichtgewichtiges Threat Model, aber die Fragen zu Assets, Akteuren, Flüssen und Missbrauch bleiben nützlich.
Sind Threat Modeling und Code Review dasselbe?
Nein. Threat Modeling definiert, was schiefgehen kann und welche Kontrollen erforderlich sind. Das Code Review prüft, ob der Code, das Diff und die Tests diese Kontrollen ohne Regressionen implementieren.
Reicht STRIDE für KI-generierten Code aus?
STRIDE ist nützlich, um Bedrohungsfamilien nicht zu vergessen, muss aber an Prompts, Agenten, Repositories, Pipelines, Tool-Calls, Geheimnisse und Laufzeitdaten angepasst werden. Wichtig ist, jede Bedrohung in eine überprüfbare Kontrolle zu verwandeln.
Reichen die von der KI generierten automatischen Tests aus?
Nein. KI-generierte Tests neigen dazu, den vorgesehenen Pfad abzudecken. Es braucht auch negative Tests, Multi-User-Szenarien, Rollenmissbrauch, Mandantentrennung, manipulierte Inputs sowie Überprüfungen von Pipelines und Konfigurationen.
Wann ist ein Risk Assessment erforderlich?
Wenn das Team entscheiden muss, ob ein Risiko akzeptiert wird, Sanierungen priorisiert werden müssen oder das Projekt mit geschäftlichen Auswirkungen, personenbezogenen Daten, Compliance, Lieferanten oder Betriebskontinuität verknüpft ist.

[Callforaction-SAL-Footer]

ISGroup Cybersicherheitsberatung

Bedrohungsmodellierung für KI-Code: Vom Prompt bis zum Pull Request