Klucze agentów potrzebują budżetów ryzyka

Repozytorium shuriken-skills firmy Shuriken zawiera instrukcje dla Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, Cursor, OpenCode oraz agentów zgodnych z AGENTS.md.¹ To samo repozytorium kieruje tych agentów do platformy, na której klucze agentów mogą odczytywać dane rynkowe, sprawdzać portfele, żądać kwotowań i wykonywać transakcje, jeśli użytkownik przyzna im taką możliwość.²

Nie handel jest tu najważniejszy. Najważniejszy jest wzorzec: agenci potrzebują dziś poświadczeń do narzędzi, które mogą wywoływać realne skutki zewnętrzne. Klucz agenta nie powinien działać jak zwykły klucz API. Powinien działać jak budżet ryzyka.

Klucz agenta jest obiektem o ograniczonych uprawnieniach. Powinien określać, co agent może zrobić, czego nie może zrobić, jak duże ryzyko może wytworzyć, jak operatorzy mogą sprawdzać jego działania oraz jak szybko można go wstrzymać, rotować lub unieważnić. Instrukcje dla modelu pomagają, ale granicę wyznaczają limity po stronie serwera.

TL;DR

MCP i przenośne umiejętności ułatwiają agentom łączenie się z systemami zewnętrznymi.³⁴ Ta przenośność podnosi stawkę w projektowaniu poświadczeń. Dokumentacja Shuriken opisuje właściwy kształt kontroli dla niebezpiecznych narzędzi: utworzyć klucz agenta, nadać wyłącznie potrzebne uprawnienia, egzekwować limity po stronie serwera, rejestrować aktywność i unieważnić klucz, gdy integracja przestaje go potrzebować.²⁵⁶ Najnowsze badania nad zasadą najmniejszych uprawnień prowadzą w tym samym kierunku: umiejętności mogą wykonywać działania wykraczające poza minimalny zakres konkretnego zadania, dlatego uprawnienia muszą zależeć od zadania, a nie od całego pakietu.⁹

Wniosek dotyczy nie tylko finansów. Każde narzędzie agenta, które wysyła pieniądze, publikuje treści, zmienia infrastrukturę, wysyła wiadomości do klientów albo dotyka prywatnych danych, potrzebuje klucza o ograniczonym zakresie z budżetem ryzyka. Ten budżet musi znajdować się poniżej modelu i poniżej pliku umiejętności. Serwer powinien odrzucać nieautoryzowane działanie nawet wtedy, gdy agent prosi o nie z pełnym przekonaniem.

Najważniejsze wnioski

• Dla twórców narzędzi agentów: poświadczenia należy projektować jako budżety uprawnień, nie jako uniwersalne tokeny bearer.
• Dla zespołów bezpieczeństwa: należy oddzielić zakresy odczytu od zakresów zapisu lub wykonania, a następnie nałożyć limity wydatków, tempa i obiektów po stronie wykonawczej.
• Dla zespołów produktowych: dzienniki aktywności i kontrolki unieważniania dostępu powinny być widoczne w głównym UI, a nie ukryte głęboko w ustawieniach.
• Dla twórców MCP: dystrybucję narzędzi i uprawnienia poświadczeń trzeba traktować jako dwie różne płaszczyzny. Umiejętności mogą uczyć. Klucze muszą ograniczać.
• Dla operatorów: warto zacząć od trybu tylko do odczytu, potwierdzić ścieżkę integracji, a dopiero potem dodać dostęp do zapisu, gdy istnieje plan reakcji.

Umiejętności dystrybuują instrukcje. Klucze dystrybuują uprawnienia.

Repozytorium shuriken-skills pokazuje nowy wzorzec dystrybucji. Jedno drzewo źródłowe zawiera markdown z umiejętnościami, manifesty wtyczek dla Claude i Codex, manifest wtyczki dla Cursor, plik rozszerzenia Gemini, wtyczkę OpenCode, crate Rusta oraz awaryjną ścieżkę AGENTS.md.¹⁷

To opakowanie ma znaczenie, bo instrukcje agentów przemieszczają się dziś między klientami. Dostawca może nauczyć Codex, Claude Code, Cursor, Gemini i inne narzędzia integracji z tym samym API. Dokumentacja MCP opisuje umiejętności agentów jako przenośne zestawy instrukcji, które przekazują asystentom kodowania wiedzę domenową, w tym decyzje projektowe dotyczące modelu wdrożenia, przepływów uwierzytelniania i wzorców narzędzi.⁴ O stronie dystrybucji pisałem w Umiejętności agentów potrzebują menedżerów pakietów; strona bezpieczeństwa zaczyna się wtedy, gdy te pakiety proszą o realne uprawnienia.

Przenośne instrukcje rozwiązują jeden problem i tworzą drugi. Pomagają agentowi nauczyć się właściwej ścieżki integracji. Nie czynią jednak wynikowego działania bezpiecznym. Umiejętność może powiedzieć modelowi, żeby stosował zasadę najmniejszych uprawnień. Instrukcja dla modelu może nakazywać ostrożność. README może wyjaśniać zalecane zakresy. Żadna z tych kontroli nie zatrzyma uwierzytelnionego żądania, gdy model zdecyduje się je wysłać.

To napięcie odpowiada szerszemu problemowi MCP opisanemu w Serwery MCP są nową powierzchnią ataku: dostęp do narzędzi rozszerza powierzchnię działania szybciej, niż nadążają za tym dawne nawyki zatwierdzania. Umiejętności agentów czynią ścieżkę instrukcji przenośną. System kluczy musi utrzymać wąską ścieżkę uprawnień.

Dlatego poświadczenia potrzebują własnego projektu. Plik umiejętności żyje na płaszczyźnie instrukcji. Klucz agenta żyje na płaszczyźnie uprawnień. Mieszanie tych płaszczyzn tworzy kruchy system: ten sam tekst uczy agenta, co ma robić, i jednocześnie próbuje powstrzymać go przed zrobieniem zbyt wiele.

Granica należy do serwera.

Wzorzec Shuriken to budżet ryzyka

Dokumentacja Agent Kit firmy Shuriken opisuje klucz agenta jako obiekt kontrolujący, co narzędzie AI może zrobić: od odczytu cen tokenów po wykonywanie transakcji, z limitami egzekwowanymi po stronie serwera, zanim agent zacznie działać.⁵ Strona uprawnień wymienia sześć kategorii uprawnień i wskazuje, że wywołania poza nadanym zakresem kończą się błędem autoryzacji.⁶

Takie ujęcie pozwala też uniknąć częstego błędu w publicznych demonstracjach agentów: traktowania otwartego kodu, widocznych instrukcji albo czytelnego manifestu wtyczki jako granicy bezpieczeństwa. Otwartość może pomagać w przeglądzie, ale open source nie jest granicą bezpieczeństwa. Granica znajduje się tam, gdzie nieautoryzowane działania kończą się niepowodzeniem.

Ten wzorzec ma pięć części:

To właściwy kształt dla narzędzi agentów wysokiego ryzyka. Projekt nie polega na tym, że model stanie się mądry. Zakłada, że model może się mylić, być zbyt pewny siebie, zostać skompromitowany przez dane wejściowe albo po prostu otrzymać złą instrukcję. Serwer nadal egzekwuje klucz.

Skopiowałbym wzorzec kontroli, nie domenę. Klucz wdrożeniowy, klucz publikacyjny, klucz do wiadomości dla klientów, klucz do zwrotów w Stripe i klucz transakcyjny wymagają tego samego pytania: jaka jest maksymalna szkoda, którą ten klucz może wyrządzić, zanim człowiek ją zauważy?

Limity po stronie serwera są silniejsze niż obietnice instrukcji dla modelu

Dokumentacja OpenAI Agents SDK przedstawia zabezpieczenia jako kontrole, które mogą działać wokół agenta, w tym zabezpieczenia wejścia i wyjścia z mechanizmami wyzwalającymi.⁸ Zabezpieczenia pomagają, bo wykrywają ryzyko przed wykonaniem modelu lub po nim. Nadal jednak należą do innej warstwy niż uprawnienia poświadczeń.

Zabezpieczenie wyjścia może oznaczyć złe proponowane działanie. Limit klucza po stronie serwera może odrzucić działanie nawet wtedy, gdy zabezpieczenie go nie wychwyci. Ta różnica jest ważna, gdy działanie wychodzi poza tekst.

Proszę rozważyć narzędzie, które może opublikować post, wysłać e-mail, zmienić rekord DNS, scalić pull request albo wykonać transakcję. Reguła w instrukcji dla modelu może mówić: „najpierw zapytaj”. Zabezpieczenie może szukać tekstu wysokiego ryzyka. Klucz po stronie serwera może wyegzekwować faktyczny limit:

Reguła instrukcji może zawieść po cichu. Granica na poziomie klucza tworzy obserwowalne odrzucenie. To odrzucenie staje się dowodem. Agent próbował przekroczyć zakres. Serwer odmówił. Operator może sprawdzić nieudane żądanie i zdecydować, czy integracja potrzebuje nowego klucza, węższego przepływu pracy albo kroku zatwierdzenia przez człowieka.

To ta sama logika, która stoi za bramką dowodową: zaufanie powinno wynikać z obserwowalnego dowodu, nie z pewności siebie. Końcowa odpowiedź „pozostałem w limitach” znaczy mniej niż dziennik serwera pokazujący, który limit zadziałał.

Zmienia to również końcową odpowiedź w coś bliższego pakietowi przeglądowemu. W tekście Pakiety przeglądowe są nową odpowiedzią końcową argumentuję, że poważna praca agentów potrzebuje artefaktów dowodowych. Odrzucenia poświadczeń, dzienniki aktywności i zmiany kluczy o ograniczonym zakresie są bezpieczeństwową wersją takiego artefaktu.

Minimalny kształt poświadczeń agenta

Każde poświadczenie agenta, które może wpłynąć na świat zewnętrzny, powinno mieć sześć właściwości.

Umiejętności Shuriken mówią to samo językiem integracji: tworzyć jeden klucz na integrację, nadawać minimalny zakres, trzymać klucze w tajemnicy, rotować je po podejrzeniu kompromitacji i unieważniać wycofane integracje.⁷ Ich umiejętność dotycząca zakresów oddziela też zakresy odczytu od zakresów transakcyjnych i ostrzega przed szerokimi kluczami „na wszelki wypadek”.⁷

Słownik badawczy dogania wzorzec produktowy. Artykuł SkillScope opisuje nadmiarowe uprawnienia jako zależne od zadania: to samo działanie umiejętności może być prawidłowe dla jednej prośby użytkownika i nadmierne dla innej.⁹ Autorzy raportują 7 039 umiejętności ze zweryfikowanymi zachowaniami nadmiarowo uprzywilejowanymi oraz redukcję liczby uruchomionych instancji takich działań o 88,56% po ograniczeniu uprawnień za pomocą ich ram.⁹ Nie trzeba kopiować dokładnego mechanizmu, aby przyjąć lekcję produktową. Poświadczenia agentów powinny odzwierciedlać bieżące zadanie, nie największe możliwe zadanie, jakie narzędzie potrafi sobie wyobrazić.

Ta wskazówka powinna stać się normalnym elementem projektowania produktów agentowych. Szerokie klucze API miały sens wtedy, gdy usługa backendowa kontrolowała wąską ścieżkę kodu. Agenci nie zachowują się jak jedna wąska ścieżka kodu. Planują, ponawiają próby, łączą narzędzia, streszczają błędy, wywołują skrypty pomocnicze i reagują na zewnętrzne dane wejściowe. Poświadczenie powinno zakładać większą zmienność zachowania niż zwykły token usługi.

Właśnie dlatego wyszukiwanie kodu przez agentów ma problem z budżetem tokenów ma znaczenie nawet w artykule o poświadczeniach. Agenci często podejmują decyzje przy częściowym kontekście. Wąski klucz daje systemowi drugą szansę, gdy okno kontekstu pominie niebezpieczny szczegół.

Czego nie kopiować

Nie należy kopiować marketingowego optymizmu.

Publiczna dokumentacja Shuriken używa mocnego języka o agentach działających pod nieobecność użytkowników i wychwytujących okazje.² Taka fraza może pasować do ich produktu. Nie powinna jednak stać się domyślną postawą bezpieczeństwa dla narzędzi agentów, które wywołują skutki zewnętrzne.

Przy działaniach wysokiego ryzyka „pod nieobecność użytkownika” musi oznaczać operacyjnie coś węższego:

• agent może gromadzić informacje pod nieobecność użytkownika;
• agent może przygotować projekt działania pod nieobecność użytkownika;
• agent może wykonać działanie tylko w małym, jawnym, egzekwowanym po stronie serwera budżecie;
• operator może później sprawdzić każde działanie;
• operator może natychmiast wstrzymać lub unieważnić klucz.

Na tym polega różnica między autonomią a abdykacją. Użytkownik może delegować działanie. System nie może delegować odpowiedzialności.

Ta sama ostrożność dotyczy umiejętności i manifestów wtyczek. Repozytorium może obsługiwać każdego klienta agentowego, a mimo to zasługiwać na konserwatywne ustawienie domyślne. Sprawdzony przeze mnie .codex-plugin/plugin.json wymienia możliwość odczytu w metadanych interfejsu, natomiast dokumentacja wyjaśnia, że handel wymaga jawnie włączonych uprawnień i limitów.⁷ To dobry kierunek: dystrybucja może być szeroka, a uprawnienia powinny zaczynać wąsko.

Reguła decyzyjna

Gdy nowa integracja agenta prosi o poświadczenie, należy sklasyfikować klucz przed jego wydaniem.

Ta tabela daje agentowi użyteczną ścieżkę, bez udawania, że granicę utrzymuje sam model. Przepływ pracy nadal może się poprawiać. Klucz zapobiega temu, aby poprawa stała się nieograniczonymi uprawnieniami. Ślady wykonania agentów są kontraktem środowiska wykonawczego pokazują to samo od strony audytu: jeśli system nie potrafi pokazać, co się wydarzyło, nie potrafi udowodnić, że agent działał w ramach zamierzonego kontraktu.

O tym samym podziale pisałem w Bezpieczeństwo sandboxa agenta jest sugestią: model może działać całkowicie w ramach nadanych uprawnień, a mimo to stworzyć niebezpieczny wynik. Klucze agentów potrzebują budżetów ryzyka, bo uprawnienie nie jest tym samym co bezpieczeństwo.

FAQ

Czy klucze agentów to po prostu klucze API pod nową nazwą?

Nie. Zwykły klucz API często daje szeroki dostęp do usługi. Klucz agenta powinien nadawać ograniczony zestaw możliwości dla jednej integracji, z limitami po stronie serwera, dziennikami aktywności i unieważnianiem, które nie wpływa na główną sesję użytkownika.

Dlaczego egzekwowanie po stronie serwera ma znaczenie?

Serwer widzi końcowe żądanie. Instrukcja modelu, plik umiejętności albo zabezpieczenie mogą przeoczyć złe działanie. Sprawdzenie uprawnień po stronie serwera może odrzucić żądanie, gdy klucz nie ma potrzebnego zakresu albo przekracza skonfigurowany limit.⁶

Czy każdy agent powinien zaczynać tylko od odczytu?

Tak, jeśli narzędzie ma istotne skutki zewnętrzne. Należy zacząć od dostępu tylko do odczytu, zweryfikować ścieżkę integracji, a dopiero potem dodać uprawnienia zapisu lub wykonania, gdy zespół wie, jakie istnieją dzienniki, limity, zatwierdzenia i kroki wycofania.

Czy MCP zwiększa ryzyko związane z poświadczeniami agentów?

MCP ułatwia podłączanie narzędzi zewnętrznych między klientami.³ Ta wygoda zwiększa znaczenie projektu poświadczeń. Przenośny dostęp do narzędzi powinien iść w parze z wąskimi kluczami, nie z szerszym zaufaniem.

Co zespoły powinny skopiować od Shuriken?

Warto skopiować rozdzielenie dystrybucji instrukcji od uprawnień po stronie serwera: przenośne umiejętności mogą uczyć integracji, a klucze o ograniczonym zakresie, limity, dzienniki i unieważnianie dostępu ograniczają działanie. Nie należy kopiować domenowego zachowania transakcyjnego, jeśli nie uzasadniają go produkt, prawo i kontrole operacyjne.

Źródła