So verhindern Sie außer Kontrolle geratene Kosten durch KI-API-Zugangsdaten

Ein KI-API-Schlüssel ist nicht bloß eine Anmeldezeichenfolge. Er ist ein Weg zu abgerechneter Rechenkapazität, und ein kopierter Schlüssel kann Anfragen noch lange autorisieren, nachdem ein Angreifer die Anwendung verlassen hat, in der er offengelegt wurde. Kostenkontrolle gehört daher zum Sicherheitsdesign jedes KI-Systems, einschließlich zeitlich begrenzter Forschungswerkzeuge und interner Prototypen.

METRs Offenlegung von 2026 verleiht diesem Risiko eine konkrete Form. Ein über das Internet erreichbares Agenten-Dashboard hatte einen Fail-open-Fehler bei der Authentifizierung, das heißt, die Anwendung blieb verfügbar, wenn ihre Zugriffskontrolle ausfiel. METR berichtete, dass ein Angreifer das Dashboard erreichte, einen Agenten dazu brachte, eine Zugangsdaten eines Modellanbieters preiszugeben, einen SSH-Schlüssel für dauerhaften Hostzugriff hinzufügte und die gestohlene Zugangsdaten drei Wochen lang nutzte. Die verbrauchten Credits wurden mit ungefähr 600.000 US-Dollar bewertet, obwohl METR diesen Betrag nicht zahlte, weil der Anbieter die Credits kostenlos bereitgestellt hatte.

Die nützliche Lehre ist weder der Schlagzeilenwert noch der Entwicklungsstil einer einzelnen Anwendung. Mehrere unabhängige Kontrollen verhinderten denselben Pfad nicht. Ein dauerhafter Präventionsplan nimmt an, dass eine Schnittstelle, ein Host oder ein Schlüssel irgendwann kompromittiert werden kann, und begrenzt, was danach geschehen kann.

Den Schadensradius vor der Bereitstellung eines Agenten festlegen

Klassifizieren Sie eine KI-Anwendung danach, was ein nicht vertrauenswürdiger Benutzer über sie erreichen könnte, nicht danach, ob das Team sie als Prototyp bezeichnet. Ein Experiment wird betrieblich bedeutsam, wenn es Internetverkehr annimmt, ein kostenpflichtiges oder knappes Modell aufrufen kann, nicht öffentliche Daten erreichen kann oder Werkzeuge mit Wirkungen außerhalb seines eigenen Prozesses aufrufen kann. Eine kurze Lebensdauer verringert diese Fähigkeiten nicht.

Erstellen Sie vor der Exponierung einen kleinen Bereitstellungsdatensatz. Benennen Sie Eigentümer, öffentliche Endpunkte, Cloud-Konto, Modelle, Zugangsdaten, Datenspeicher, Werkzeugberechtigungen, erwarteten Nutzungsbereich, Ablaufdatum und Abschaltverfahren. Dieses Inventar macht vergessene Experimente auffindbar und gibt einem Incident-Responder eine verlässliche Karte. Öffentliche Dienste sollten in einer architektonisch von internen Systemen getrennten Umgebung laufen, damit ein Defekt in einem Viewer oder Dashboard keinen Weg zu sensibler Infrastruktur schafft.

METRs Offenlegung beschrieb einen zweiten Fehler in einem öffentlichen Transkript-Viewer: Ein schreibgeschützter SQL-Mechanismus konnte manipuliert werden, um unveröffentlichte Evaluierungsdaten offenzulegen, und einige sensible Ausgaben waren in eine Datenbank gelangt, die nur öffentliche Modellergebnisse enthalten sollte. METR sagte, die verfügbaren Belege deuteten nicht darauf hin, dass Angreifer den Exploit entdeckten oder nicht öffentliche Informationen abriefen. Der Vorfall zeigt dennoch, warum die beabsichtigte Datenklassifizierung nicht genügt. Die Isolierung muss abdecken, wo Datensätze gespeichert werden, wie Abfragen begrenzt sind und ob eingeschränktes Material in einen öffentlich zugänglichen Datenspeicher gelangen kann.

Legen Sie eine leicht durchsetzbare Regel fest: Internetexponierung oder Zugriff auf aktive Zugangsdaten löst automatisch eine grundlegende Sicherheitsprüfung aus. Die Prüfung kann schlank sein, sollte aber Standardverweigerung bei der Authentifizierung, verwaltetes Hosting, benannte Eigentümerschaft, Protokollierung, Zugangsgrenzen und ein Enddatum bestätigen.

Rohe Geheimnisse außerhalb der Reichweite des Agenten halten

Eine Anwendung kann Berechtigung benötigen, ein Modell aufzurufen, doch das Modell muss die wiederverwendbare Zugangsdaten nicht lesen. Speichern Sie Geheimnisse außerhalb von Prompts, Transkripten, Werkzeugen zur Umgebungsinspektion, Dateien, die der Agent öffnen kann, und Befehlsausgaben, die der Agent zurückgeben kann. Anweisungen wie „Diesen Schlüssel niemals offenlegen“ sind keine Sicherheitsgrenze, weil ein Sprachmodell nicht vertrauenswürdige Anweisungen verarbeitet und zur Offenlegung zugänglicher Informationen manipuliert werden kann.

Schalten Sie einen Broker oder eng definierten Dienst zwischen Agent und Anbieter. Der Agent fordert eine erlaubte Operation an; der Broker hält die Zugangsdaten, validiert die Anfrage, wendet Richtlinien an, zeichnet Nutzung auf und gibt nur das nötige Ergebnis zurück. Beschränken Sie den Broker auf genehmigte Modelle und Operationen. Wo Anbieterfunktionen es erlauben, geben Sie jeder Anwendung und Umgebung getrennte Zugangsdaten, verringern Berechtigungsumfänge und verwenden kurze Laufzeiten.

Getrennte Identitäten erleichtern sowohl Eindämmung als auch Untersuchung. Wenn ein Schlüssel mehrere Experimente bedient, hat hohe Nutzung viele plausible Erklärungen, und ein Widerruf stört nicht zusammenhängende Arbeit. Ein einer Arbeitslast gewidmeter Schlüssel hat einen kleineren Verhaltensbereich, einen klaren Eigentümer und einen praktischen Notschalter. Kurzlebige Zugangsdaten verkürzen außerdem den Zeitraum, in dem ein kopierter Wert nützlich bleibt, während eng begrenzte Berechtigungen einschränken, was der Angreifer in diesem Zeitraum tun kann.

Hostzugriff braucht seine eigene Grenze. Der METR-Angreifer fügte nach dem Eindringen in das exponierte System einen SSH-Schlüssel hinzu; daher hätte das Rotieren allein der Anbieter-Zugangsdaten die Persistenz nicht entfernt. Überwachen Sie Änderungen der Fernzugriffskonfiguration, beschränken Sie, wer Schlüssel hinzufügen darf, und behandeln Sie eine neue dauerhafte Zugriffsmethode als Vorfall, auch wenn der API-Verbrauch noch gewöhnlich aussieht.

Budgets in durchgesetzte Sicherheitsgrenzen verwandeln

Ein Ausgabenalarm ist nützlich, aber ein Alarm ist nur eine Aufforderung an einen Menschen zu untersuchen. Bevorzugen Sie ein hartes Anbieter- oder Broker-Limit, das weitere Nutzung ablehnt, sobald das genehmigte Budget ausgeschöpft ist. Wenden Sie Grenzen auf mehreren Ebenen an, wenn verfügbar: Organisation, Projekt, Anwendungszugangsdaten und Zeitfenster. Eine monatliche Kontogrenze allein kann zu Beginn des Zeitraums immer noch einen schädlichen Ausbruch erlauben.

Manche Anbieter oder Kontovereinbarungen bieten möglicherweise keine direkte Ausgabenobergrenze. METR sagte, es habe damals keine für den betroffenen Schlüssel setzen können, und gespendete Credits beseitigten die steigende Rechnung, die sonst Aufmerksamkeit ausgelöst hätte. Bilden Sie die Grenze in dieser Situation in der aufrufenden Schicht nach. Ein Zugangsdaten-Broker kann Anfragen oder Tokens zählen, Tages- und Pro-Lauf-Kontingente erzwingen, Parallelität begrenzen und Zugriff aussetzen, wenn ein Schwellenwert überschritten ist. Gewährte oder vorausbezahlte Kapazität sollte selbst dann als Vermögenswert mit Ersatzwert behandelt werden, wenn die aktuelle Barabrechnung null beträgt.

Wählen Sie Schwellenwerte aus dem erklärten Zweck der Zugangsdaten. Eine geplante Evaluierung, ein interaktives Dashboard und ein Batchauftrag sollten nicht dieselben Grenzen teilen. Definieren Sie ein erwartetes Maximum für einen einzelnen Lauf, eine rollierende stündliche oder tägliche Obergrenze und eine maximale Rate fehlgeschlagener oder abgelehnter Anfragen. Dokumentieren Sie, wer eine vorübergehende Erhöhung genehmigen kann und wann diese Ausnahme abläuft. Andernfalls werden Notfallüberschreibungen still zum normalen Betriebsrahmen.

Die Durchsetzung muss Fail-closed sein. Wenn Authentifizierungsdienst, Richtlinienprüfung, Nutzungszähler oder Genehmigungsabfrage nicht verfügbar sind, sollte das System die geschützte Operation verweigern oder stark einschränken. Ein beeinträchtigter Überwachungsdienst darf eine begrenzte Zugangsdaten nicht still in eine unbegrenzte verwandeln.

Verhalten erkennen, das eine Rechnung nicht zeigen kann

Hohes Tokenvolumen ist in Forschungs- oder Evaluierungsarbeit nicht automatisch verdächtig. METR erklärte, dass legitime Experimente erhebliche Nutzung, Rate-Limit-Antworten und Anbieterfehler erzeugen könnten. Sein internes Dashboard zeigte während des Vorfalls auch nicht jede rate-limitierte Anfrage jedes Benutzers. Diese Kombination erlaubte unbefugter Aktivität, sich in vertrautem Betriebsrauschen zu verbergen.

Bauen Sie Grundlinien um Identität und Zweck auf, statt nur das gesamte Kontovolumen zu beobachten. Bewahren Sie für jede Anwendungszugangsdaten Anforderungszeit, Modell, Ergebnis, Token- oder Nutzungsmenge, ursächliche Arbeitslast und verantwortlichen Eigentümer auf, sofern diese Signale verfügbar sind. Nehmen Sie fehlgeschlagene und rate-limitierte Versuche auf, weil Erkundung und versuchter Verbrauch möglicherweise nie in erfolgreichen Nutzungssummen erscheinen. Legen Sie das rohe Geheimnis nicht in Protokollen ab.

Nützliche Anomalieregeln vergleichen aktuelles Verhalten mit dem Bereitstellungsdatensatz. Beispiele sind Aktivität außerhalb des Zeitplans der Arbeitslast, anhaltende Nutzung nach Ende eines geplanten Experiments, eine unbekannte Herkunft, ein Modell, das die Anwendung nicht aufrufen durfte, ein ungewöhnliches Verhältnis von Fehlern zu Erfolgen oder eine plötzliche Änderung der Anfragerate. Diese Signale sind handlungsfähiger als ein allgemeiner Alarm „hohe Nutzung“, weil sie erklären, welche Erwartung verletzt wurde.

Stimmen Sie Alarme ab, ohne wichtige Beweise zu löschen. Rauschende Rate-Limit-Meldungen sollten gruppiert und zusammengefasst, nicht aus dem Dashboard ausgelassen werden. Das Ziel ist ein handhabbarer Alarmstrom, der durch vollständige durchsuchbare Ereignisse gestützt wird. Jeder Alarm braucht einen benannten Reagierenden, eine Schwere, eine Untersuchungsfrist und einen automatischen Eskalationspfad. Eine Warnung ohne Eigentümer ist nur gespeicherte Telemetrie.

Ein Agenten-Dashboard für Entscheidungen entwerfen

Ein nützliches Betriebsdashboard sollte vier Fragen schnell beantworten: Welche Zugangsdaten änderte ihr Verhalten, was darf sie tun, wie viel Wert ist derzeit gefährdet und welche Maßnahme wird sie eindämmen? Stellen Sie Nutzung und Fehler nach Zugangsdaten, Anwendung, Modell und Zeitfenster dar statt nur als organisationsweite Summe. Zeigen Sie Verbrauch harter Grenzen, vorübergehende Ausnahmen, Alter der Zugangsdaten, letzte Rotation, Eigentümer und ob die zugehörige Bereitstellung noch genehmigt ist.

Platzieren Sie Sicherheits- und Kostensignale zusammen. Ein Ausbruch von Anbieterfehlern, ein neuer SSH-Schlüssel, ein Authentifizierungsfehler und fortgesetzte API-Nutzung können in getrennten Werkzeugen gering wirken, bilden aber bei Korrelation eine klare Vorfallkette. Bewahren Sie genug Historie, um aktuelles Verhalten mit dem normalen Muster derselben Arbeitslast zu vergleichen und die Abfolge später zu rekonstruieren.

Das Dashboard sollte getestete Eindämmungsaktionen bereitstellen oder direkt darauf verweisen: die Anwendungszugangsdaten deaktivieren, die Arbeitslast stoppen, öffentlichen Zugriff entfernen und den Anbieter kontaktieren. Zerstörerische Kontrollen benötigen passende Autorisierung, sollten aber nicht davon abhängen, während eines aktiven Vorfalls einen undokumentierten Befehl zu finden. Halten Sie fest, wer jede Aktion wann ausführte.

Eine Reaktionsübung für Zugangsdaten proben

Führen Sie eine Tabletop- oder kontrollierte Übung zu einem kopierten Schlüssel durch. Beginnen Sie mit einem glaubwürdigen Signal, etwa anhaltendem Verkehr außerhalb des Zeitplans plus wiederholten Rate-Limit-Fehlern. Bitten Sie den Bereitschaftsverantwortlichen, Eigentümer zu ermitteln, das betroffene Anbieterkonto zu bestätigen, die Zugangsdaten zu deaktivieren, die Arbeitslast zu stoppen oder zu isolieren und den Host auf Persistenz zu prüfen. Das Team sollte anschließend zugehörige Zugangsdaten rotieren, gegebenenfalls Protokolle und ein forensisches Image sichern, den Anbieter benachrichtigen und feststellen, ob Daten oder andere Systeme erreichbar waren.

Der Widerruf ist der erste Eindämmungsschritt, nicht das Ende der Untersuchung. METRs Reaktion umfasste das Stoppen der kompromittierten Instanz, das Erstellen eines forensischen Images, das Rotieren von Zugangsdaten, die Untersuchung und das Löschen des Laptops des Forschers, die Information des Modellunternehmens und externe Sicherheitsunterstützung. Die genaue Reihenfolge variiert, doch das Prinzip bleibt: aktuellen Zugriff entfernen und zugleich genug Beweise erhalten, um festzustellen, wie die Kompromittierung geschah und was sich sonst ändern muss.

Messen Sie die Übung anhand verstrichener Zeit und fehlender Informationen. Wie lange dauerten Entdeckung, Eigentümerabfrage, Widerruf, Host-Isolierung und Anbieterkontakt? Welche Protokolle waren unvollständig? Konnten Reagierende gewährte Credits von abgerechneter Nutzung unterscheiden? Aktualisieren Sie Bereitstellungsvorlage, Dashboard und Runbook nach jeder Übung.

Checkliste zur Implementierung

• Inventarisieren Sie jeden internetfähigen Agentendienst, seinen Eigentümer, sein Ablaufdatum, seine Cloud-Umgebung, Zugangsdaten, Daten und Werkzeuge.
• Verlangen Sie Standardverweigerung bei Authentifizierung und eine Grundprüfung bei öffentlicher Exponierung oder Zugriff auf aktive Zugangsdaten.
• Halten Sie Anbieter-Geheimnisse außerhalb modelllesbaren Kontexts, von Transkripten, Werkzeugen und abrufbaren Dateien.
• Verwenden Sie Zugangsdaten pro Anwendung mit dem engsten verfügbaren Umfang und praktischer Laufzeit.
• Leiten Sie Aufrufe über einen Broker, wenn direkte Anbieter-Kontrollen die nötige Richtlinie nicht erzwingen können.
• Setzen Sie Pro-Lauf- und rollierende Nutzungsobergrenzen; fügen Sie einen harten Stopp hinzu, wo Anbieter oder Broker ihn unterstützen.
• Überwachen Sie erfolgreiche, fehlgeschlagene und rate-limitierte Anfragen nach Zugangsdaten und erwarteter Arbeitslast.
• Alarmieren Sie bei Verhaltensabweichungen, nicht nur bei Gesamtkosten oder Tokenvolumen.
• Korrelieren Sie Modellnutzung mit Authentifizierungs- und Host-Persistenzereignissen im Agenten-Dashboard.
• Geben Sie jedem Alarm einen Reagierenden, eine Frist, einen Eskalationsweg und eine getestete Eindämmungsaktion.
• Proben Sie Schlüsselwiderruf, Arbeitslastisolierung, Beweissicherung, Anbieterbenachrichtigung und Wiederherstellung.
• Legen Sie Zugangsdaten und öffentliche Endpunkte still, wenn das Experiment endet, und prüfen Sie dann, dass der Verkehr beendet ist.

Außer Kontrolle geratene API-Kosten verhindert man am besten durch überlappende Grenzen. Geheimnisisolierung blockiert einfache Extraktion, enge Identitäten verringern den Schadensradius, erzwungene Budgets begrenzen Verbrauch, Verhaltensüberwachung verkürzt die Erkennung und Reaktionsübungen machen Widerruf zur Routine. Nichts davon hängt davon ab, korrekt zu erraten, wie der nächste Angreifer eindringen wird. Zusammen verwandeln sie einen gestohlenen Schlüssel von einer unbefristeten Ressource in einen eingegrenzten, beobachtbaren Vorfall.