Cała branża właśnie zgodziła się, że agent nie powinien widzieć Pana kluczy. Chowa je w niewłaściwym miejscu.

W tym tygodniu Anthropic opublikował w changelogu Claude Code jedną, niepozorną linię: "Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" [1]. Mówiąc wprost — gdy Claude Code działał w trybie headless (tak jak w CI i zautomatyzowanych potokach agentów), narzędzia uwierzytelniania, które miały pozostać ukryte, były udostępniane modelowi: AI widziało nazwy narzędzi auth, ich parametry i potencjalnie mogło przy nich grzebać. W najczęściej używanym agencie kodującym na świecie — 133 tys. gwiazdek — warstwa danych uwierzytelniających wyciekała tam, gdzie najmniej Pan tego chce: do samego kontekstu modelu.

Zostało to naprawione. Ale sama poprawka to mała historia. Duża brzmi: dlaczego każde poważne środowisko agenta nagle toczy tę samą walkę.

Trzy środowiska, jeden tydzień, ten sam instynkt

Proszę spojrzeć, co trafiło do produkcji w jednym 24-godzinnym oknie:

• Claude Code załatał wyciek auth-stub opisany wyżej i zaostrzył kontrolę uwierzytelniania MCP [1].
• Hermes (v0.17.0) dodał „Managed Scope" — sekrety przypięte przez administratora, niezmienialne przez użytkownika, zablokowane na poziomie systemu plików tak, by operator agenta nie mógł ich nadpisać — a także redakcję sekretów w zrzutach debugowych i blokowanie konfiguracji MCP o kształcie exfiltracji, zanim te wystartują [2].
• Codex (v0.141.0) owinął ruch zdalnego wykonania w szyfrowane kanały Noise i zaczął kierować wtyczki według trybu uwierzytelniania [3].

Trzej rywale, trzy podejścia, jeden wspólny wniosek: środowisko agenta musi zarządzać sekretami, a agent nigdy nie może widzieć surowych kluczy. Gdy konkurenci zbiegają się w ten sposób w tym samym tygodniu, to nie jest moda. To kategoria, która w końcu przyznaje, po co istnieje.

Kolejny problem to rozproszenie danych uwierzytelniających

Jest haczyk. Każda z tych poprawek żyje wewnątrz środowiska agenta. A błąd Claude Code to wskazówka: gdy uwierzytelnianie mieszka w środowisku, tuż obok modelu, zdanie „agent nigdy tego nie zobaczy" przestaje być faktem, a staje się własnością, którą trzeba nieustannie inżynierować — i od czasu do czasu w tym zawieść, w trybie headless, gdzie nikt nie patrzy. Nie da się tego ogłosić raz. Broni się tego, wydanie po wydaniu.

Ale głębszy problem to nie pojedynczy wyciek — lecz to, co się dzieje, gdy każde środowisko, każdy dostawca i każdy przypadek użycia wdraża własną odpowiedź. Powstaje sejf w Claude Code, sejf w Hermesie, sejf w Codexie, tu pula OAuth, tam plik z sekretami — osobny magazyn danych uwierzytelniających dla każdego narzędzia, którego Pan używa. To jest rozproszenie danych uwierzytelniających i to jest następny problem, nie problem rozwiązany.

Rozproszenie jest porażką nawet wtedy, gdy żadne silosy nie przeciekają. Pana sekrety są kopiowane do każdego z nich, żeby działały — więcej kopii, więcej miejsc, z których można je ukraść. Rotacja musi się odbyć N razy, ręcznie, a ta jedna, o której Pan zapomni, jest tą, która Pana pali. I nikt nie potrafi odpowiedzieć na jedyne pytanie, które naprawdę ma znaczenie — który agent użył którego klucza, wobec czego i kiedy — bo odpowiedź jest rozsiana po kilkunastu magazynach, które ze sobą nie rozmawiają. Nie da się stawiać świeżego sejfu dla każdego dostawcy i każdego przepływu pracy. To się nie skaluje. To jest rzecz, która pęka.

Klucze w ogóle nie należą do środowiska agenta

Poprawki, której nigdy nie trzeba wdrażać, jest ta, w której agent w ogóle nie trzyma uwierzytelniania. Dane uwierzytelniające trzeba umieścić w jednej instytucji, która leży poza każdym środowiskiem agenta — nie sejf na dostawcę, jeden pod wszystkimi. Agent — w Claude Code, w Codexie, w Hermesie, nie ma znaczenia — prosi o jedną nazwaną akcję i dostaje wstrzyknięte ograniczone, efemeryczne dane uwierzytelniające dokładnie do niej, pobierane na żywo i znikające po użyciu. W kontekście modelu nie ma auth-stub, który można przypadkowo ujawnić, bo uwierzytelnianie nigdy nie było w środowisku agenta. Nie ma rozproszenia, bo jest jeden magazyn zamiast jednego na narzędzie — rotacja raz, nie N razy. I każdy dostęp trafia na jeden ślad audytowy zamiast rozpraszać się po kilkunastu silosach, które nie potrafią powiedzieć, kto użył czego. (Trzymanie sekretu poza miejscem, w którym uruchamia się kod, jest niemal na szczycie zasad, których powinno przestrzegać narzędzie do danych uwierzytelniających — branża właśnie spędziła tydzień, żeby to odkryć.)

I to jest ta część, która jest granicą bezpieczeństwa, a nie wygodą: dane uwierzytelniające nie mogą mieszkać w tym samym systemie co agent. Umieść je razem, a będą dzielić promień rażenia — prompt injection, zatruty serwer MCP, wspólny zrzut debugowy, kolejny błąd auth-stub, i wszystko, co dociera do agenta, dociera razem z nim do kluczy. Dlatego sama widoczność jest już naruszeniem: w chwili gdy sekret ląduje tam, gdzie agent go widzi, traktuje się go jako już wyciekły i rotuje — tak, jak każdy ostrożny zespół potraktował ten auth-stub w Claude Code w dniu premiery. Trzymać dane uwierzytelniające na dystans, w systemie, o który agent może jedynie pytać — nigdy czytać, nigdy trzymać — a w pełni skompromitowany agent nadal nie wyeksfiltruje tego, co nigdy nie było w jego zasięgu. Może poprosić o akcję. Nie może wyjść z kluczem. Dystans jest obroną; sejf w procesie go nie ma za żadne pieniądze.

Taką linię wyznacza Clavitor. Całe środowisko właśnie udowodniło zasadę — agent nie powinien widzieć kluczy. My tylko nie uważamy, by musiał Pan udowadniać ją na nowo wewnątrz każdego środowiska, którego Pan używa, i nie uważamy, by rzecz trzymająca Pana klucze miała być tym samym, co atakujący właśnie skompromitował.

Należy się uznanie zespołom środowiska agenta: sekrety przypięte przez administratora, szyfrowane przekaźniki, domyślne tryby fail-closed to prawdziwe, dobre inżynierstwo. Ale poprawka tygodnia na wyciek, który wciąż powraca, to nie architektura — to objaw. Architekturą jest to, że kluczy nie ma tam, skąd mogłyby wyciec.

Gdy trzej konkurenci łatają tę samą ranę w tym samym tygodniu, rana jest elementem projektu. Agent nie powinien widzieć Pana kluczy — więc proszę przestać trzymać je tam, gdzie może.

Clavitor (@clavitorai) to sejf na dane uwierzytelniające zbudowany dla agentów AI i przeciwko nim. clavitor.ai

Źródła

[1] Claude Code v2.1.183 — „Fixed MCP servers requiring authentication exposing auth-stub tools to the model in headless/SDK mode" — https://github.com/anthropics/claude-code/releases/tag/v2.1.183

[2] Hermes Agent v0.17.0 — Managed Scope (sekrety przypięte przez administratora), redakcja sekretów, blokowanie konfiguracji exfiltracyjnych — https://github.com/NousResearch/hermes-agent/releases

[3] OpenAI Codex v0.141.0 — szyfrowane kanały przekaźnikowe Noise, kierowanie wtyczek według trybu uwierzytelniania — https://github.com/openai/codex/releases