Przejdź do głównej treści
Klucz pojawił się w publicznym commicie, logu CI, zrzucie ekranu lub naruszeniu dostawcy. Zegar tyka: ktokolwiek trzyma ten ciąg sk-orca-…, może wydawać twoje saldo i sterować twoimi agentami, dopóki go nie odetniesz. Ta strona to runbook incydentu — najpierw odetnij poświadczenie, potem audytuj, co zrobiło — dla klientów zarządzających własnymi kluczami w konsoli. Mechanika cyklu życia (wyłączenie vs usunięcie, stany klucza, role) żyje w Zarządzaniu kluczami; ta strona to sekwencja pod-atakiem i, co krytyczne, co sprawdzić w śladzie audytu, gdy krwawienie ustanie.
Zatrzymaj wydatki, zanim zbadasz. Klucz o ograniczonym zakresie z limitem credit_limit_usd i listą allow_ips ogranicza szkodę, ale wyciekły klucz bez limitów może spalać saldo tak długo, jak pozostaje żywy. Najpierw unieważnij; forensyka w drugiej kolejności.

​
1. Unieważnij wyciekły klucz api (zrób to najpierw)

Masz dwa ruchy odcięcia, oba na ekranie Klucze w konsoli (/console/token). Oba wymagają roli Developer lub wyższej — akcja działa na twoim tokenie sesji / dostępu, nigdy na kluczu relay.

Wyłącz — odwracalna pauza

Przestaw status klucza na Disabled. Każde żądanie, które wykonuje, jest odrzucane natychmiast, ale klucz, jego limity, jego załączniki polityk i jego historia użycia pozostają nienaruszone. Użyj tego, gdy potrzebujesz zachować konfigurację i logi, gdy drążysz.

Usuń — trwałe unieważnienie

Wybierz Usuń przy kluczu. Poświadczenie nigdy więcej nie autoryzuje żądania i nie da się go odzyskać. Użyj tego, gdy wyciek jest potwierdzony, a ty przechwyciłeś, czego potrzebujesz ze śladu.
Częsty wzorzec: wyłącz natychmiast w chwili, gdy podejrzewasz ekspozycję (zawężenie o zerowej latencji, nic nie stracone), uruchom audyt w §3–§4, potem usuń, gdy ograniczysz promień rażenia. Cokolwiek robisz, wydaj świeży klucz na zastępstwo — nigdy nie włączaj ponownie poświadczenia, które widziano w naturze. Przekazanie bez przestoju jest w Rotacji kluczy.
Wyłączenie lub usunięcie wchodzi w życie przy następnym żądaniu — bez ponownego wdrożenia i bez opóźnienia propagacji.

​
2. Przy okazji zacieśnij zastępstwo

Wyciek to moment, by naprawić zakres, który pozwolił mu zaszkodzić. Klucz zastępczy powinien nieść najwęższą tożsamość, której zadanie faktycznie potrzebuje, tak by następny wyciek był zdarzeniem bez znaczenia:
Lista dozwolonych IP oznacza, że wyciekły klucz jest bezużyteczny z dowolnego adresu poza twoim. Żądania z niewypisanych IP są odrzucane na warstwie uwierzytelniania, zanim cokolwiek kosztują.
Limit wydatków (0 = nieograniczone) ogranicza najgorszy przypadek. Wyciekły klucz z ciasnym tygodniowym pułapem nie może wydrenować salda twojej przestrzeni roboczej.
Limity modeli powstrzymują złodzieja przed przełączeniem twojego taniego klucza na twój najdroższy model.
Wygaśnięcie (-1 = nigdy) oznacza, że klucz, który umknie twojej uwadze, wciąż przestaje autoryzować sam.
Po pełną postawę jeden-klucz-na-agenta zobacz Listę kontrolną minimalnych uprawnień.

​
3. Audytuj logi żądań — co klucz wywołał?

Z odciętym poświadczeniem ogranicz szkodę. Każde wywołanie relay, które ten klucz wykonał, jest zapisane w logach żądań twojej przestrzeni roboczej, a każdy wiersz niesie pola, których potrzebujesz, by zrekonstruować incydent:
PoleCo ci mówi
token_name / token_idKtóry klucz — potwierdź, że patrzysz na wyciekły.
ipAdres źródłowy każdego wywołania. Seria z IP, którego nie rozpoznajesz, to dymiący pistolet.
model + użycieKtóre modele były uderzone i ile kosztowały — twoja ekspozycja wydatków.
Przefiltruj widok logów do wyciekłego klucza i posortuj po czasie. Dwa pytania najszybciej odpowiadają „jak źle jest”:
  1. Czy jest ruch z IP, które nie jest twoje? To potwierdzone nadużycie, nie fałszywy alarm.
  2. Czy wydatki lub wzorzec wywołań skoczyły wokół okna wycieku? Nagły skok to ślad atakującego.
Jeśli klucz niósł listę allow_ips, wywołania spoza niej nigdy nie autoryzowały się w ogóle — więc brak wierszy z obcym IP jest sam w sobie czystym świadectwem zdrowia. To dokładnie dlatego przypięcie źródła (§2) zamienia wyciek w zdarzenie bez znaczenia.

​
4. Przeczytaj ślad polityki — co próbował zrobić?

Logi żądań mówią ci, co klucz wywołał; płaszczyzny polityk mówią ci, co próbował zmusić model, by powiedział lub zrobił, oraz czy twoje guardrails i firewall to wychwyciły. Oba są w zakresie przestrzeni roboczej. Dopasowania guardrailu są odczytywalne przez każdego członka przestrzeni roboczej; widok Events / Runs firewalla wymaga roli Developer lub wyższej (polityki i ustawienia firewalla pozostają otwarte dla każdego członka).

Dopasowania guardrailu

Za każdym razem, gdy ruch klucza uderzył w regułę guardrailu, rekord dopasowania wylądował pod GET /api/guardrail/match — niosąc typ reguły, action (block / mask / flag), stage oraz obciążający szczegół. Przefiltruj do okna wyciekłego klucza, by zobaczyć, jaką treść przepychał (PII, sekrety, próby jailbreaka).

Zdarzenia firewalla

Każde wywołanie narzędzia, które klucz wystawił, to zdarzenie firewalla — allow, audit, deny, sanitize lub wstrzymane. Seria zdarzeń deny to agent, który próbował czegoś, na co mu nie pozwolono. Zwiń je po przebiegu w widoku Events / Runs.
Kilka szczegółów wartych wiedzy, gdy czytasz ślad:
  • Dopasowania guardrailu logują dopasowany podłańcuch tylko, jeśli „Loguj surową treść” było włączone dla tego guardrailu (jest wyłączone domyślnie) — więc wiersz dopasowania może pokazać regułę i akcję bez surowego tekstu. Typ / akcja / etap są zawsze obecne.
  • mark-fp na dopasowaniu (POST /api/guardrail/match/:id/mark-fp, Admin) pozwala oznaczyć trafienie jako fałszywie dodatnie, tak by przestało zniekształcać twój widok incydentu — nie używaj tego, by zakopać prawdziwe nadużycie.
  • Odmowy firewalla są przed-narzędziowe. Zdarzenie deny oznacza, że wywołanie narzędzia atakującego zostało zablokowane zanim dotarło do narzędzia — firewall już zawęził tę akcję. Zdarzenie to twój dowód, że próbował.
Skrzyżuj trzy ślady na tym samym oknie czasowym: obce IP w logach żądań, skok dopasowań guardrailu i klaster zdarzeń deny firewalla razem malują pełny obraz — co atakujący miał, czego próbował i co zostało zatrzymane.

​
5. Po incydencie

Sprawdź ponownie listę Klucze: wyciekły klucz powinien czytać się jako Disabled lub być całkowicie usunięty. Jeśli tylko go wyłączyłeś, zaplanuj usunięcie, gdy skończysz audyt — zobacz Zarządzanie kluczami.
Przenieś ruch na nowy, ciaśniej ograniczony klucz, zanim wycofasz stary, tak by nigdy nie było luki bez działającego klucza. Pełne przekazanie: Rotacja kluczy.
Jeśli wyciekły klucz nie miał allow_ips, nie miał credit_limit_usd i miał szerokie model_limits, to jest prawdziwe odkrycie. Nadaj każdemu agentowi własny wąsko ograniczony klucz — Lista kontrolna minimalnych uprawnień oraz Zakres i klucze przechodzą całą postawę.

​
6. Powiązane

Zarządzanie kluczami

Wyłączenie vs usunięcie, stany klucza i bramki ról za każdą akcją.

Rotacja kluczy

Przekazanie bez przestoju ze skompromitowanego klucza na czysty.

Lista dozwolonych IP

Przypnij klucz do swoich adresów źródłowych, tak by wyciek nie mógł być użyty gdzie indziej.

Eksfiltracja danych

Zagrożenie, które wyciekły klucz najczęściej zasila, i jak powierzchnia egress firewalla je ogranicza.
Cała sekwencja jest krótka celowo: unieważnij, potem audytuj. Im węższy zakres każdego klucza na początku, tym mniejszy audyt, który musisz przeprowadzić — i tym szybciej wyciekłe poświadczenie idzie od awarii do przypisu.