Michael JohnsonWewnętrzny audyt OpenRouter wykazał ponad 1 000 aktywnych kluczy API u 85 pracowników; według firmy 168 kluczy nie było używanych od miesięcy. Są to dane z samooceny OpenRouter, a nie niezależne badanie branży. Nawet jako pojedynczy przykład pokazują jednak znaną pułapkę inżynieryjną: można zapomnieć o kluczu, ale nie o aplikacji, która od niego zależy. Firma datuje ogłoszenie Security Center na 28 września 2026 roku.
Problem nie sprowadza się do znalezienia najstarszego poświadczenia i usunięcia go. Zespół musi ustalić, kto jest jego właścicielem, dowiedzieć się, gdzie używany jest klucz, i sprawdzić, jak go zastąpić, nie wyłączając przy tym rzadko uruchamianego zadania ani zapomnianej usługi. Bez tych informacji odebranie dostępu zamiast porządków staje się ryzykownym eksperymentem.
Co pokazuje Security Center — i czego to nie dowodzi
Według opisu OpenRouter Security Center gromadzi klucze z konta i pokazuje ich właściciela, datę ostatniego użycia, limit wydatków oraz termin ważności; administratorzy organizacji widzą wszystkie klucze, a członkowie — te, które sami utworzyli. W ramach operacji zbiorczej można wybrać maksymalnie 500 kluczy i je wyłączyć, zarchiwizować lub ustawić dla nich limit wydatków. Wyłączenie można cofnąć, archiwizacji — nie. Są to funkcje narzędzia opisane przez samego dostawcę, a nie niezależna ocena jego skuteczności.
Szczególnie ważne jest, by status „można usunąć” traktować jako wskazówkę do weryfikacji, a nie dowód, że nie ma żadnych zależności. Metryka użycia pokazuje wcześniejsze żądania, ale nie musi wyjaśniać, z którym zadaniem cron, scenariuszem awaryjnym lub procesem sezonowym powiązany jest klucz. OpenRouter sam zaleca potwierdzenie usunięcia u właściciela; dokumentacja ustawień bezpieczeństwa również ostrzega, by przed wyłączeniem lub archiwizacją sprawdzić zależności.
Ograniczenia sieciowe mają osobne zastrzeżenie: lista dozwolonych adresów IP jest dostępna dla administratorów w planie Enterprise i dotyczy wszystkich kluczy organizacji. Żądania z adresów spoza listy są odrzucane błędem 403, a zmiany wchodzą w życie natychmiast. Dlatego przed włączeniem ograniczenia trzeba uwzględnić adresy serwerów produkcyjnych, sieci biurowej i runnerów CI; w przeciwnym razie środek ochronny może przerwać prawidłowe wywołania.
Porządkowanie: najpierw właściciel, potem unieważnienie
- Przygotuj inwentaryzację. Dla każdego klucza zanotuj właściciela, przeznaczenie, środowisko, systemy korzystające z klucza, limit wydatków i termin ważności. Jeśli system pokazuje jako właściciela tylko osobę, przypisz też zespół lub usługę, które przejmą odpowiedzialność, gdy ta osoba odejdzie.
- Sprawdź użycie i zależności. Porównaj czas ostatniego żądania z harmonogramami zadań w tle, scenariuszami odzyskiwania, potokami wdrożeniowymi i integracjami zewnętrznymi. Brak niedawnej aktywności to powód, by zapytać właściciela, a nie wystarczająca podstawa do natychmiastowego usunięcia.
- Ogranicz ryzyko przed migracją. Jeśli to możliwe, ustaw rozsądny limit wydatków i termin ważności. Uwzględnij zasadę najmniejszych uprawnień i zasady przechowywania sekretów: poradnik OWASP dotyczący zarządzania sekretami traktuje ewidencję, dostęp i cykl życia poświadczeń jako osobne elementy procesu.
- Utwórz zamiennik i przenieś systemy korzystające z klucza. Zaktualizuj sekret w magazynie lub konfiguracji wdrożeniowej, a następnie przenoś aplikacje etapami. Nie wklejaj wartości klucza do zgłoszeń, logów ani kodu źródłowego.
- Sprawdź środowisko produkcyjne przed unieważnieniem. Upewnij się, że nowy klucz działa we wszystkich znanych systemach, które z niego korzystają, w tym w CI i rzadko uruchamianych zadaniach. Następnie najpierw wyłącz stary klucz, jeśli dostępna jest odwracalna operacja; zarchiwizuj go lub usuń dopiero po potwierdzeniu migracji i upływie przyjętego okresu obserwacji.
Sekwencja „utwórz nowy klucz → przenieś aplikacje → sprawdź działanie → usuń stary” jest zgodna z instrukcją rotacji OpenRouter. To zalecana kolejność, a nie gwarancja braku przestoju: rezultat zależy od tego, czy udało się znaleźć wszystkie systemy korzystające z poświadczenia.
Klucze usług to nie wszystkie sekrety organizacji
OpenRouter twierdzi również, że Security Center wykorzystuje metadane kluczy, dane o wydatkach i terminy ważności, a nie odczytuje promptów ani odpowiedzi. Jest to oświadczenie samego dostawcy; w przeanalizowanych źródłach nie ma niezależnej weryfikacji technicznej. Ogólnie rzecz biorąc, istnienie panelu nie dowodzi, że zespół ograniczył już liczbę incydentów lub wydatki: w zbadanych materiałach nie znaleziono publicznych wyników po uruchomieniu narzędzia.