Ein Support-Chat kann zu einer Transaktion mit Geldfluss führen, wenn ein FastAPI-Backend die Ausgabe eines Modells als verbindliche Anweisung akzeptiert.
In dem für diesen Kurs verwendeten Beispielszenario sendet eine aufrufende Anwendung eine unauffällige Nachricht an POST /v1/chat. Der FastAPI-Dienst leitet diesen Text an einen Modellanbieter weiter, und das Modell liefert eine Tool-Anweisung zurück, die einer Rückerstattungsanfrage ähnelt.
Das Backend führt den Tool-Aufruf aus, sobald das Modell ihn vorschlägt – ohne zu prüfen, ob der Endbenutzer zu dieser Aktion berechtigt ist, und ohne die Modellausgabe als nicht vertrauenswürdigen Text zu behandeln.
Für diesen Fehler sind keine ungewöhnlichen Umstände erforderlich. Das Backend tut genau das, wofür es entwickelt wurde; es führt jedoch den Schritt mit den höchsten Berechtigungen – die Tool-Aktion – auf der Grundlage einer Zeichenkette aus, die von außerhalb der Vertrauensgrenze stammt.
Sobald die irreversible Aktion ausgeführt wurde, kann kein nachgeschalteter Filter den Nebeneffekt rückgängig machen; daher müssen wir entscheiden, an welcher Stelle der erste wirksame Stopp erfolgen muss.
Dieselbe Anfrage überschreitet mehrere Grenzen, an denen nicht vertrauenswürdiger Text zu Kosten oder Nebeneffekten führt. Der Kurs orientiert sich durchgehend an diesem einen Pfad, sodass jede Kontrollmaßnahme an einer spezifischen Stelle greift.
Nicht vertrauenswürdiger Text gelangt über drei Wege ins System, selbst wenn sich der Aufrufer korrekt verhält: Die Nachricht des Aufrufers trifft über die HTTP-Anfrage ein, abgerufene Dokumente stammen aus den eigenen Datenspeichern des Backends, und Tool-Ergebnisse kommen von anderen Systemen, die fehlerhaft oder böswillig sein können.
An zwei Stellen können Kosten entstehen oder Daten verbraucht/verändert werden: Der Aufruf des Modellanbieters verursacht Token-Verbrauch und Kosten, und die Tool-Ausführung kann auf reale Ressourcen zugreifen oder diese verändern, die dem Benutzer möglicherweise nicht gehören.
Die einzigen zuverlässigen Kontrollpunkte sind serverseitige Prüfungen im FastAPI-Dienst im Umfeld dieser kritischen Stellen. Der Kurs implementiert Authentifizierung, Mandantenbindung, Kontingente, Eingabe- und Ausgabefilter, Tool-Autorisierung, Sandboxing und Audit-Logging als explizite Kontrollschwellen. Die Formulierung des Prompts erzwingt keine dieser Maßnahmen, da der System-Prompt lesbar ist und das Modell lediglich dem Text folgt.
Das untenstehende Diagramm markiert jede nicht vertrauenswürdige Eingabe und jeden Kontrollpunkt auf dem einzelnen Anfragepfad, den wir schrittweise erweitern. Bestimmen wir genau, an welcher Stelle Text zur verbindlichen Anweisung wird und wo wir die Ausführung verweigern können.
Dieses Diagramm veranschaulicht eine bestimmte Regel. Jeder Pfeil, der Text überträgt, gilt als nicht vertrauenswürdig; nur die Komponenten innerhalb unseres Dienstes können Anfragen ablehnen, begrenzen, validieren, autorisieren und protokollieren.
Ein sicherer API-Vertrag erfordert konsistente Ablehnungscodes, da sowohl Clients als auch die Fehleranalyse im Bereitschaftsdienst auf vorhersehbare Ergebnisse angewiesen sind, wenn eine Kontrollinstanz (ein „Gate“) eine Anfrage abweist.
Wir definieren diese Zuordnung einmal und verwenden sie durchgehend wieder, wobei wir jede Ablehnung an die Komponente binden, die sie durchsetzt, und nicht an das Modell selbst.
401 Unauthorized: Lehnt Anfragen mit fehlenden, ungültigen, widerrufenen oder kompromittierten Anmeldeinformationen ab; der Dienst gibt diesen Fehler zurück, noch bevor Kontingente verbraucht oder der Anbieter aufgerufen werden.403 Forbidden: Lehnt authentifizierte Aufrufer ab, die außerhalb ihres zulässigen Bereichs agieren (einschließlich verweigerter oder abgelaufener Berechtigungen), sowie Tool-Aufrufe an blockierte Ziele, die gar nicht erst kontaktiert werden.422 Unprocessable Content (RFC 9110): Lehnt Modellausgaben ab, die die Schema-Validierung nicht bestehen, da nicht validierte Ausgaben lediglich Text darstellen, bis der Server deren Übereinstimmung mit dem Tool-Vertrag bestätigt hat.429 Too Many Requests (mit Retry-After): Signalisiert die Überschreitung von Ratenbegrenzungen oder Kontingenten; der Zählerstand muss gemeinsam genutzt werden, damit Replikate das Limit nicht unbemerkt vervielfachen.503 Service Unavailable: Tritt auf, wenn der Speicher für Kontingentzähler nicht erreichbar ist oder ein aktiver „Circuit Breaker“ die Durchsetzung verhindert, da der Dienst nicht sicher entscheiden kann, ob die Nutzung zulässig ist.504 Gateway Timeout: Tritt auf, wenn der Aufruf an den Anbieter das Zeitlimit des Dienstes überschreitet, da hängende Aufrufe einen unkontrollierten Ressourcenverbrauch darstellen.Um den Kurs praxisnah zu gestalten, entwickeln wir eine funktionierende Komponente und härten diese schrittweise ab. Bei dieser Komponente handelt es sich um einen mandantenfähigen POST /v1/chat-Endpunkt, der genau ein Tool aufrufen kann; in jeder weiteren Lektion fügen wir diesem Ablauf eine weitere Kontrollinstanz hinzu.
Bei diesem anfänglichen Fehler kann der Aufrufer durchaus legitim sein; das bedeutet, dass die Authentifizierung erfolgreich verläuft, die Anfrage aber dennoch eine nicht autorisierte Tool-Aktion auslöst.
Wenn der Dienst die Validierung der Modellausgabe erst nach der Ausführung des Tool-Aufrufs vornimmt, kann die Schema-Validierung zwar fehlerhafte Nutzdaten (Payloads) abweisen, jedoch keine Aktion rückgängig machen, die zwar formal korrekt aussieht, aber niemals hätte zugelassen werden dürfen.
Entscheidend ist, welche Stufe den Vorgang verweigern kann, bevor eine irreversible Tool-Aktion ausgeführt wird. Welcher frühestmögliche Stopppunkt fängt den Fehler zuerst ab: Authentifizierung, Tool-Autorisierung oder Ausgabevalidierung?