Eine korrekte Fehlerzuordnung (Failure Map) macht die Zuweisung von Verantwortlichkeiten konkret. Das Modell generierte zwar Text, doch das Backend entschied, ob POST /v1/tools/refund.create tatsächlich ausgeführt wurde. Im Backend können wir den Berechtigungsumfang des Akteurs (Principal) verifizieren, Genehmigungen für irreversible Aktionen erzwingen und einen Idempotenz-Schlüssel hinzufügen, um bei Wiederholungsversuchen Doppelbuchungen zu vermeiden. Sobald wir diese Grenze durchsetzen, werden Prompt-Injection-Versuche zu Eingaben, die bei der Validierung und Autorisierung scheitern, anstatt zu Anweisungen, die Geldtransfers auslösen.
Wir setzen ein grundlegendes Verständnis von HTTP-Statuscodes voraus; es ist also bekannt, was eine Antwort, die eine Anfrage ablehnt, auf Protokollebene bedeutet.
Wir setzen Grundkenntnisse zu JWT voraus, insbesondere die Fähigkeit, Signaturen zu verifizieren sowie Aussteller (Issuer), Zielgruppe (Audience) und Ablaufdatum (Expiry) mithilfe einer bewährten Bibliothek zu prüfen.
Wir setzen Kenntnisse in der Dependency Injection von FastAPI voraus, sodass wir Authentifizierung, Autorisierung und Kontingentprüfungen als Abhängigkeiten mit Request-Scope implementieren können, anstatt diese Prüfungen über verschiedene Handler zu verteilen.
Das im Verlauf des Kurses entwickelte Artefakt ist eine Referenz-Backend-Pipeline, bei der jede Stufe einen klaren Punkt für die Ablehnung von Anfragen aufweist, jeder Log-Eintrag über stabile Felder verfügt, die für Prüfer nachvollziehbar sind, und jeder Regressionsfall mit einer spezifischen Kontrollmaßnahme verknüpft ist. Das Ziel ist nicht ein raffinierter Prompt. Das Ziel ist ein Backend, das sicher RAG (Retrieval-Augmented Generation) auf der Kontohistorie durchführen, refund.create nur bei entsprechender Berechtigung und Genehmigung für u_123 aufrufen und Analyseskripte ausführen kann, ohne dabei Zugriff auf das Netzwerk oder Geheimnisse (Secrets) zu gewähren. Das folgende Diagramm veranschaulicht den Anfragepfad, den wir schrittweise absichern werden.
Das Backend eines FastAPI-basierten Support-Copiloten versagt meist auf gewöhnliche Weise. Das Backend liest die Kontohistorie für acct_987 aus, ein Modell schlägt nächste Schritte vor, und ein Tool-Aufruf veranlasst eine Rückerstattung für txn_456, weil der Text des Support-Tickets überzeugend klang. Es geschah nichts Ungewöhnliches. Die Anwendung akzeptierte nicht vertrauenswürdigen Text aus dem Ticket, interpretierte den Vorschlag als Autorisierung und führte refund.create mit den Berechtigungen des Dienstes aus, anstatt die Berechtigungen des Endnutzers und einen Genehmigungsprozess durchzusetzen.
Die Sicherheitsarbeit in diesem Kurs besteht darin, die fehlenden Kontrollmechanismen genau dort zu implementieren, wo sie wirksam werden können. Die Formulierung eines Prompts kann einen Tool-Router nicht davon abhalten, eine Anfrage zu senden, und ein Modell kann nicht nachweisen, dass u_123 berechtigt ist, txn_456 zu erstatten. Das Backend lehnt die Anfrage entweder vor der Ausführung des Tools ab, oder es führt das Tool aus und veranlasst eine echte Geldtransaktion.
Wir verwenden für jede Lektion einen festen Bezugspunkt, damit sich alle Sicherheitsmaßnahmen auf dieselben Komponenten beziehen. Der Mandant (Tenant) ist t_acme, der Endnutzer ist u_123, das Konto ist acct_987 und die für eine Rückerstattung infrage kommende Transaktion ist txn_456. Das einzige Tool für Rückerstattungen heißt refund.create, und die einzige Route, die es anspricht, ist POST /v1/tools/refund.create.
Zudem legen wir den einzigen Scope-Namen fest, der eine Rückerstattung erlaubt. Ein Akteur (Principal) ohne die Berechtigung support:refund kann zwar weiterhin über Richtlinien chatten, die Kontohistorie zusammenfassen und Antwortentwürfe erstellen, darf jedoch nicht refund.create ausführen. Die Wahl des Modells bleibt explizit, aber abstrakt. Die Anwendung ruft ein Chat-Modell über $CHAT_MODEL auf und verwendet $MODERATION_MODEL dort, wo in einer späteren Lektion eine gezielte Überprüfung erforderlich ist.
Sobald die Bezeichnungen festgelegt sind, können wir einen einzelnen Anfragepfad nachvollziehen und markieren, an welchen Stellen nicht vertrauenswürdige Daten in das System gelangen. Die Nachricht des Aufrufers gilt als nicht vertrauenswürdig, selbst wenn sie von einem authentifizierten Support-Mitarbeiter stammt, da sie kopierte Kundentexte oder Ticketinhalte enthalten kann. Abgerufene Teile der Kontohistorie sind nicht vertrauenswürdig, da der Abrufprozess alle im Speicher vorhandenen Daten liefert – einschließlich veralteter Notizen und Freitexten, die versuchen könnten, das Modell zu steuern. Tool-Ergebnisse sind nicht vertrauenswürdig, da nachgelagerte Systeme unerwartete Zeichenfolgen oder Datenfelder zurückgeben können; ebenso ist die Modellausgabe nicht vertrauenswürdig, da das Modell auf plausiblen Text und nicht auf die Einhaltung von Richtlinien optimiert ist.
Der Kurs implementiert gezielt jene Kontrollpunkte, die es ermöglichen, nicht vertrauenswürdige Eingaben in eine begrenzte, nachvollziehbare Aktion zu überführen. Wir authentifizieren und binden einen Principal, sodass jede Anfrage t_acme und u_123 als serverseitig verifizierte Fakten enthält – und nicht als vom Aufrufer bereitgestellte Header. Wir erfassen das Kontingent (Quota) vor dem Aufruf des Providers, um zu verhindern, dass ein einzelner Endpunkt das Token-Budget eines ganzen Monats über Nacht aufbraucht. Wir autorisieren den Abruf direkt am Aufrufort, sodass das Backend nur Datenfragmente abruft, für deren Einsicht u_123 berechtigt ist; zudem behandeln wir jedes abgerufene Fragment grundsätzlich als nicht vertrauenswürdigen Inhalt. Wir validieren die strukturierte Ausgabe des Modells, bevor sie von Routern, Parsern, Templates oder Tools verarbeitet wird. Wir autorisieren und genehmigen Tool-Aufrufe, damit refund.create nicht allein deshalb ausgeführt wird, weil das Modell einen überzeugenden Vorschlag unterbreitet hat. Wir führen Analyseskripte in einer Sandbox aus, um sicherzustellen, dass generierter Code weder auf das Netzwerk noch auf Geheimnisse (Secrets) zugreifen kann. Wir protokollieren jede Ablehnung und jede ausgeführte Aktion mit ausreichenden Details, um nachvollziehbar zu machen, wer was für welchen Mandanten (Tenant) getan hat und warum das Backend dies zugelassen hat.
Wenn der Text eines Support-Tickets versucht, eine Rückerstattung auszulösen: Welche Instanz hätte die Rückerstattung verweigern können, noch bevor ein Tool ausgeführt wurde?