Zum Hauptinhalt springen
Ein Schlüssel tauchte in einem öffentlichen Commit, einem CI-Log, einem Screenshot oder einem Lieferanten-Breach auf. Die Uhr läuft: Jeder, der diesen sk-orca-…-String hält, kann Ihr Guthaben ausgeben und Ihre Agenten treiben, bis Sie ihn kappen. Diese Seite ist das Incident-Runbook — kappen Sie zuerst die Anmeldeinformation, dann auditieren Sie, was sie getan hat — für Kunden, die ihre eigenen Schlüssel in der Konsole verwalten. Die Lebenszyklus-Mechanik (deaktivieren vs. löschen, Schlüsselzustände, Rollen) lebt in Schlüssel verwalten; diese Seite ist die Unter-Angriff-Sequenz und, entscheidend, was im Audit-Trail zu prüfen ist, sobald die Blutung gestoppt hat.
Stoppen Sie die Ausgaben, bevor Sie untersuchen. Ein scoped Key mit einem credit_limit_usd-Cap und einer allow_ips-Liste begrenzt den Schaden, aber ein geleakter Schlüssel ohne Caps kann Guthaben verbrennen, solange er live bleibt. Widerrufen Sie zuerst; Forensik als Zweites.

​
1. Den geleakten API-Key widerrufen (tun Sie das zuerst)

Sie haben zwei Kappungs-Züge, beide im Konsolen-Schlüssel-Bildschirm (/console/token). Beide erfordern die Rolle Developer oder höher — die Aktion läuft auf Ihrem Session-/Access-Token, nie auf einem Relay-Schlüssel.

Deaktivieren — umkehrbare Pause

Schalten Sie den Status des Schlüssels auf Disabled. Jeder Request, den er stellt, wird sofort abgelehnt, aber der Schlüssel, seine Limits, seine Policy-Bindungen und seine Nutzungshistorie bleiben alle intakt. Verwenden Sie das, wenn Sie die Konfiguration und Logs erhalten brauchen, während Sie nachforschen.

Löschen — permanenter Widerruf

Wählen Sie Löschen auf dem Schlüssel. Die Anmeldeinformation kann nie wieder einen Request autorisieren und ist nicht wiederherstellbar. Verwenden Sie das, sobald der Leak bestätigt ist und Sie erfasst haben, was Sie aus dem Trail brauchen.
Ein gängiges Muster: deaktivieren Sie sofort in dem Moment, in dem Sie Exposition vermuten (Eindämmung ohne Latenz, nichts verloren), führen Sie das Audit in §3–§4 aus, löschen Sie dann, sobald Sie den Blast-Radius gefasst haben. Was Sie auch tun, stellen Sie für den Ersatz einen frischen Schlüssel aus — aktivieren Sie nie eine Anmeldeinformation wieder, die in freier Wildbahn gesehen wurde. Die ausfallfreie Übergabe ist in Schlüsselrotation.
Das Deaktivieren oder Löschen wird beim nächsten Request wirksam — es gibt kein Redeploy und keine Propagierungsverzögerung.

​
2. Verschärfen Sie bei der Gelegenheit den Ersatz

Ein Leak ist der Moment, um den Scope zu reparieren, der ihn schaden ließ. Der Ersatzschlüssel sollte die engste Identität tragen, die die Workload tatsächlich braucht, sodass der nächste Leak ein Non-Event ist:
Eine IP-Allowlist bedeutet, dass ein geleakter Schlüssel von jeder Adresse außer Ihrer nutzlos ist. Requests von ungelisteten IPs werden auf der Auth-Ebene abgelehnt, bevor sie irgendetwas kosten.
Ein Ausgabenlimit (0 = unbegrenzt) begrenzt den schlimmsten Fall. Ein geleakter Schlüssel mit einer engen wöchentlichen Obergrenze kann Ihr Workspace-Guthaben nicht leeren.
Modell-Limits hindern einen Dieb daran, Ihren billigen Schlüssel auf Ihr teuerstes Modell umzuschalten.
Ein Ablauf (-1 = nie) bedeutet, dass ein Schlüssel, der Ihrer Aufmerksamkeit entgeht, trotzdem von selbst aufhört zu autorisieren.
Siehe die Least-Agency-Checkliste für die vollständige Ein-Schlüssel-pro-Agent-Haltung.

​
3. Die Request-Logs auditieren — was hat der Schlüssel aufgerufen?

Mit gekappter Anmeldeinformation fassen Sie den Schaden. Jeder Relay-Aufruf, den dieser Schlüssel gemacht hat, ist in Ihren Workspace-Request-Logs aufgezeichnet, und jede Zeile trägt die Felder, die Sie brauchen, um den Vorfall zu rekonstruieren:
FeldWas es Ihnen sagt
token_name / token_idWelcher Schlüssel — bestätigen Sie, dass Sie den geleakten ansehen.
ipDie Quelladresse jedes Aufrufs. Ein Schub von einer IP, die Sie nicht erkennen, ist das rauchende Colt.
Modell + NutzungWelche Modelle getroffen wurden und was sie kosteten — Ihre Ausgaben-Exposition.
Filtern Sie die Log-Ansicht auf den geleakten Schlüssel und sortieren Sie nach Zeit. Zwei Fragen beantworten das „Wie schlimm ist es” am schnellsten:
  1. Gibt es Traffic von einer IP, die nicht Ihre ist? Das ist bestätigter Missbrauch, kein Fehlalarm.
  2. Sind die Ausgaben oder das Aufrufmuster gespikt um das Leak-Fenster herum? Ein plötzlicher Sprung ist der Fußabdruck des Angreifers.
Wenn der Schlüssel eine allow_ips-Liste trug, autorisierten Aufrufe von außerhalb davon von vornherein nie — die Abwesenheit von Fremd-IP-Zeilen ist also selbst ein sauberes Gesundheitszeugnis. Genau deshalb verwandelt das Festpinnen der Quelle (§2) einen Leak in ein Non-Event.

​
4. Den Policy-Trail lesen — was hat er zu tun versucht?

Request-Logs sagen Ihnen, was der Schlüssel aufgerufen hat; die Policy-Ebenen sagen Ihnen, was er das Modell sagen oder tun zu lassen versuchte und ob Ihre Guardrails und Firewall es abfingen. Beide sind workspace-bezogen. Guardrail-Matches sind von jedem Workspace-Mitglied lesbar; die Firewall-Events / Runs-Ansicht erfordert die Rolle Developer oder höher (Firewall-Policies und -Einstellungen bleiben für jedes Mitglied offen).

Guardrail-Matches

Jedes Mal, wenn der Traffic des Schlüssels auf eine Guardrail-Regel traf, landete ein Match-Datensatz bei GET /api/guardrail/match — mit dem Regeltyp, action (block / mask / flag), stage und dem betreffenden Detail. Filtern Sie auf das Fenster des geleakten Schlüssels, um zu sehen, welche Inhalte er durchgedrückt hat (PII, Secrets, Jailbreak-Versuche).

Firewall-Events

Jeder Tool-Call, den der Schlüssel ausgab, ist ein Firewall-Event — allow, audit, deny, sanitize oder zurückgehalten. Ein Lauf von deny-Events ist ein Agent, der etwas versucht hat, das ihm nicht erlaubt war. Rollen Sie sie nach Run in der Events / Runs-Ansicht auf.
Ein paar Spezifika, die es wert sind, beim Lesen des Trails zu wissen:
  • Guardrail-Matches loggen den gematchten Teilstring nur, wenn „Log raw content” an war für dieses Guardrail (es ist standardmäßig aus) — eine Match-Zeile kann also die Regel und Aktion ohne den Rohtext zeigen. Der Typ / die Aktion / die Stage sind immer da.
  • mark-fp auf einem Match (POST /api/guardrail/match/:id/mark-fp, Admin) lässt Sie einen Treffer als Fehlalarm markieren, sodass er aufhört, Ihre Incident-Ansicht zu verzerren — verwenden Sie es nicht, um echten Missbrauch zu vergraben.
  • Firewall-Denies sind pre-tool. Ein deny-Event bedeutet, dass der Tool-Call des Angreifers blockiert wurde, bevor er das Tool erreichte — die Firewall hat diese Aktion bereits eingedämmt. Das Event ist Ihr Beweis, dass er es versucht hat.
Querverweisen Sie die drei Trails auf dasselbe Zeitfenster: eine fremde IP in den Request-Logs, ein Spike von Guardrail-Matches und ein Cluster von Firewall-deny-Events malen zusammen das volle Bild — was der Angreifer hatte, was er versuchte und was gestoppt wurde.

​
5. Nach dem Vorfall

Prüfen Sie die Schlüsselliste erneut: Der geleakte Schlüssel sollte Disabled lesen oder ganz weg sein. Wenn Sie ihn nur deaktiviert haben, planen Sie das Löschen, sobald Sie das Audit beendet haben — siehe Schlüssel verwalten.
Verschieben Sie Traffic auf den neuen, enger gefassten Schlüssel, bevor Sie den alten zurückziehen, sodass es nie eine Kein-funktionierender-Schlüssel-Lücke gibt. Vollständige Übergabe: Schlüsselrotation.
Wenn der geleakte Schlüssel keine allow_ips, kein credit_limit_usd und breite model_limits hatte, ist das die eigentliche Erkenntnis. Geben Sie jedem Agenten seinen eigenen eng gefassten Schlüssel — die Least-Agency-Checkliste und Scope & Schlüssel begehen die ganze Haltung.

​
6. Verwandtes

Schlüssel verwalten

Deaktivieren vs. löschen, Schlüsselzustände und die Rollen-Gates hinter jeder Aktion.

Schlüsselrotation

Die ausfallfreie Übergabe von einem kompromittierten Schlüssel zu einem sauberen.

IP-Allowlist

Pinnen Sie einen Schlüssel auf Ihre Quelladressen, sodass ein Leak nicht anderswo verwendet werden kann.

Datenexfiltration

Die Bedrohung, die ein geleakter Schlüssel am häufigsten füttert, und wie die Egress-Surface der Firewall sie begrenzt.
Die ganze Sequenz ist mit Absicht kurz: widerrufen, dann auditieren. Je enger der Scope jedes Schlüssels von vornherein, desto kleiner das Audit, das Sie ausführen müssen — und desto schneller geht eine geleakte Anmeldeinformation vom Notfall zur Fußnote.