Zarządzanie sekretami w systemach AI

Sekret to wartość, której ujawnienie pozwala komuś podszyć się pod Ciebie, pobrać dane albo wykonać akcję w zewnętrznej usłudze. Należą do nich klucze API modeli AI, tokeny OAuth, hasła do baz danych, klucze prywatne i sekrety służące do weryfikacji webhooków. Zarządzanie sekretami oznacza, że te dane nie krążą przypadkowo między kodem, promptami, arkuszami i czatami. System przechowuje je w przeznaczonym do tego miejscu, ujawnia tylko procesowi, który ich potrzebuje, oraz pozwala je wymienić i sprawdzić, kto z nich korzystał.

W systemie AI ryzyko jest większe niż w prostym skrypcie, bo model może przetwarzać treść z plików, stron WWW, formularzy i wiadomości. Nie wkładaj sekretu do system promptu ani nie pozwalaj agentowi odczytać pliku środowiskowego jako części kontekstu. Model nie potrzebuje znać wartości tokenu, aby zaplanować akcję. Narzędzie wykonawcze powinno dostać sekret bezpośrednio z bezpiecznej konfiguracji, a model tylko opis narzędzia i dozwolony zakres działania. To ogranicza skutki prompt injection, błędów w logowaniu i przypadkowego udostępnienia rozmowy.

Najprostszy bezpieczny układ dla małego workflowu to osobne zmienne środowiskowe lub magazyn sekretów ustawiony w panelu hostingu albo automatyzacji. Nazwa może być widoczna, na przykład CRM_API_TOKEN, ale wartość nie może trafić do repozytorium, frontendu ani zrzutu ekranu. GitHub rozróżnia sekrety od zwykłych zmiennych konfiguracyjnych i pozwala podawać sekrety workflowom bez zapisywania ich w kodzie. Produkcja, staging i lokalna praca powinny używać osobnych wartości, żeby test nie miał dostępu do danych ani uprawnień produkcyjnych.

Praktyczny przykład: workflow odbiera lead z formularza, tworzy streszczenie przez model i zapisuje je w CRM. Klucz do modelu, token CRM oraz sekret podpisu webhooka są trzema różnymi sekretami. Workflow weryfikuje podpis przed przetworzeniem danych, wywołuje model tylko z jego kluczem, a zapis do CRM wykonuje tokenem ograniczonym do tworzenia lub aktualizacji leadów. Agent nie otrzymuje żadnej z tych wartości w tekście. Jeśli token CRM wycieknie, możesz go unieważnić bez zatrzymywania całego systemu i bez wymiany klucza do modelu.

Zastosuj zasadę najmniejszych uprawnień także do sekretów. Nie używaj jednego administratorowego tokenu do wszystkiego tylko dlatego, że jest wygodny. Osobny token dla automatyzacji publikacji nie powinien czytać płatności, a klucz testowy nie powinien wysyłać prawdziwych wiadomości. Zaplanuj rotację, czyli wymianę sekretu po czasie lub natychmiast po podejrzeniu wycieku. Magazyny sekretów wspierają zwykle wersje, ograniczenia dostępu, daty wygaśnięcia i dzienniki dostępu. Sama rotacja bez aktualizacji wszystkich zależnych workflowów może jednak wywołać awarię, więc sprawdź ją najpierw w środowisku testowym.

Nie loguj sekretów ani całych nagłówków autoryzacji. Maskowanie w interfejsie nie jest gwarancją, że wartość nie trafiła do historii wykonania, systemu błędów albo zewnętrznego narzędzia analitycznego. OWASP zaleca między innymi szczegółową kontrolę dostępu i audyt użycia sekretów. W praktyce log powinien zawierać nazwę integracji, identyfikator wykonania i wynik działania, ale nie token, pełny adres z parametrami autoryzacji ani surowe dane klienta. Przy awarii zbieraj tyle informacji, by naprawić proces, bez kopiowania materiału, który zwiększa zakres wycieku.

Najczęstszy błąd to wrzucenie pliku .env do publicznego repozytorium lub wklejenie klucza do narzędzia AI „na chwilę”. Drugi to przekazanie jednego sekretu wielu osobom i automatyzacjom bez wiedzy, kto go używa. Samo usunięcie klucza z commita nie wystarcza, bo historia i kopie mogą nadal go zawierać. Traktuj taki incydent jak wyciek: natychmiast unieważnij sekret, wygeneruj nowy, sprawdź logi dostawcy i popraw miejsce, z którego wartość wypłynęła. Zaczynaj od inwentaryzacji: jakie sekrety istnieją, kto jest właścicielem, gdzie są używane i jak je odciąć.