Bezpieczeństwo agenta AI zaczyna się od jednej zasady: Twój agent AI nigdy nie powinien przechowywać Twoich danych uwierzytelniających. Oto 38-letni wzorzec brokera, który to egzekwuje.
Agenci AI to zagubieni zastępcy. To wzorzec bezpieczeństwa znany od 38 lat, a odpowiedź jest równie stara: umieść brokera — zaufaną, obserwowalną, deterministyczną, audytowalną, niepodrabialną, o zawężonym zakresie, sterowaną polityką, nie-AI warstwę pośrednią — pomiędzy agentem a API SaaS, które musi wywołać, przechowując dane uwierzytelniające, których agent nie powinien posiadać.
W 1988 roku Norm Hardy opublikował krótką pracę, opisującą prawdziwy incydent z czasów pracy w Tymshare. Kompilator Fortrana o nazwie FORT znajdował się w katalogu systemowym SYSX. Aby zbierać statystyki użycia, kompilator musiał zapisywać do (SYSX)STAT, więc system operacyjny przyznał FORT-owi „licencję na pliki domowe”, upoważniającą do zapisu dowolnego pliku w SYSX. Plik rozliczeniowy systemu, (SYSX)BILL, również tam się znajdował. Użytkownik wywołujący kompilator mógł podać nazwę pliku do opcjonalnego debugowania. Pewnego dnia użytkownik podał (SYSX)BILL. Kompilator poprosił system o otwarcie tego pliku do zapisu; system, widząc licencję, pozwolił. Dane rozliczeniowe zostały nadpisane. Kompilator zrobił dokładnie to, do czego został zaprojektowany. Błąd był architektoniczny.
Hardy nazwał to problemem zagubionego zastępcy: uprzywilejowany program (zastępca) posiada własne uprawnienia; mniej uprzywilejowany wywołujący prosi go o wykonanie zadania; zastępca myli się co do tego, czyim uprawnieniem operuje, i używa własnego. Rozwiązaniem jest całkowite odebranie tych uprawnień zastępcy i umieszczenie ich za oddzielną warstwą, która pośredniczy w wywołaniu na żądanie. Tą warstwą jest broker.
Trzydzieści osiem lat później każdy agent AI uruchamiany w Twojej firmie jest zagubionym zastępcą. I większość działa bez brokera.
Dlaczego agenci AI pogarszają problem bezpieczeństwa
FORT Hardy’ego miał jeden kanał wejściowy: linię poleceń. Współczesny agent AI ma ich dziesiątki: treści e-maili, pobrane strony WWW, przesłane PDF-y, wyniki narzędzi z serwerów MCP, wiadomości od innych agentów w systemie wieloagentowym. Wszystko, co trafi do okna kontekstowego, może wydawać polecenia, a agent z założenia traktuje je wszystkie jako prawidłowe.
To łamie założenie, na którym opiera się tradycyjna kontrola dostępu: wywołujący kontroluje wejście. W aplikacji webowej wywołujący (uwierzytelniona sesja) i wejście (treść żądania HTTP) pochodzą z tego samego miejsca. Dla agenta wywołującym jest każdy, kto kształtuje prompt, czyli atakujący, który może napisać e-mail lub wpłynąć na wynik wyszukiwania, także jest wywołującym.
W listopadzie 2025 roku badacze bezpieczeństwa z PromptArmor pokazali, jak to wygląda w praktyce. Ukryli złośliwe instrukcje w czcionce o rozmiarze 1 pikseli w przewodniku integracji. Gdy deweloper skierował IDE Antigravity Google na tę stronę, agent ominął własną ochronę plików opartą na .gitignore, uruchamiając cat. Następnie wyciekł zawartość plików .env na kontrolowany przez atakującego adres webhook.site przez przeglądarkowego subagenta Antigravity. Użytkownik skonfigurował wszystko poprawnie. Sandbox zadziałał. Agent po prostu nie był w stanie odróżnić, czego zażądał użytkownik, od tego, co nakazało wejście.
Ten sam schemat co FORT Hardy’ego, dekady później: szerokie uprawnienia, nieufne wejście, brak możliwości ich rozdzielenia.
Społeczność zna odpowiedzi. Są tylko rozproszone.
To nie jest nowy problem. Społeczność bezpieczeństwa pisze o tym od dekad:
Bezpieczeństwo oparte na uprawnieniach (Dennis & Van Horn, 1966; później język E i prace Marka Millera nad Caja w Google). Zasada: nie przyznawaj uprawnień na podstawie tożsamości lub lokalizacji; przekazuj jawne, niepodrabialne uprawnienia do każdego zasobu, do którego program ma mieć dostęp. Uprawnienie łączy co możesz zrobić z czym możesz to zrobić i nie można go pomylić z niczym innym.
Brokerowane dane uwierzytelniające (skodyfikowane przez OWASP LLM Top 10). Nie umieszczaj tokenów API w kontekście LLM. Zaufana warstwa pośrednia wykonuje wywołanie w imieniu agenta; model decyduje co zrobić, broker obsługuje jak. Wstrzyknięcie promptu, które prosi model o wydrukowanie danych uwierzytelniających, nie daje nic użytecznego. Danych tam nie ma.
Wzorzec Phantom Token (Curity, pierwotnie dla OAuth w mikrousługach). Agent posiada nieprzezroczysty identyfikator sesji, a nie prawdziwy token. Proxy weryfikuje identyfikator, podmienia prawdziwe dane uwierzytelniające na brzegu sieci i przekazuje dalej. Jeśli agent wycieknie swoje środowisko, atakujący otrzymuje ciąg, który wygasa wraz z końcem sesji.
Wstrzykiwanie danych uwierzytelniających just-in-time (systemy tożsamości obciążeń jak Aembit). Twórz krótkotrwałe, zawężone uprawnienia na każde wywołanie zamiast wydawać długoterminowe tokeny.
Nic z tego nie jest nieznane w literaturze. Brakuje tego w domyślnych ustawieniach. Większość platform agentów nadal przekazuje modelowi token OAuth bez brokera pośredniczącego i liczy na najlepsze.
Jak działa broker Zero
Nie wymyśliliśmy żadnego z powyższych wzorców. Połączyliśmy je w jeden broker, który domyślnie działa dla każdego agenta na Zero. To zaufana warstwa pośrednia opisana przez te wzorce, zbudowana dla platformy agentów AI. Każde wywołanie agenta do łącznika przechodzi przez niego. Każdy łącznik to jedno zewnętrzne SaaS (Slack, GitHub, Notion itd.).
Broker znajduje się pomiędzy każdym agentem a każdym łącznikiem. Prawdziwe dane uwierzytelniające istnieją tylko po stronie brokera za przerywaną linią.
Można to podzielić na trzy warstwy.
1. Izolacja danych uwierzytelniających
Sandbox agenta nigdy nie przechowuje prawdziwych danych uwierzytelniających łącznika. Gdy podłączasz SaaS do Zero, token OAuth lub klucz API przechowywany jest po stronie brokera. Sandbox otrzymuje zastępczy ciąg znaków, który wygląda jak sekret środowiskowy, by istniejące narzędzia działały, ale żadne SaaS nie zaakceptuje go jako prawidłowego.
Gdy agent wysyła żądanie do zarejestrowanego hosta łącznika, broker dopasowuje żądanie, rozwiązuje szablon uwierzytelniania łącznika i wstrzykuje prawdziwe dane uwierzytelniające na brzegu sieci. Żądanie trafia do SaaS z prawidłowym uwierzytelnieniem; agent nigdy nie miał nic wartościowego. Agent z wstrzykniętym promptem, który wypisuje zmienne środowiskowe, przekazuje atakującemu zastępczy ciąg, a nie token SaaS.
To wzorzec phantom token zastosowany do agentów AI.
2. Bramka polityki łącznika
Łącznik w Zero powinien być czymś więcej niż przełącznikiem on/off. Każdy łącznik opisuje obsługiwane bazy API i sposób wstrzykiwania uwierzytelnienia. Gdy usługa SaaS publikuje stabilne mapowanie zakresów na endpointy, może także opisać, które nazwane uprawnienie obejmuje daną metodę i ścieżkę. Dobrym przykładem jest slack-api-ref Slacka.
Gdy agent połączony ze Slackiem wywołuje chat.postMessage, broker może zmapować to żądanie na chat:write. Gdy czyta logi audytu, to admin.analytics:read. Dla każdego agenta permission_policies definiuje zachowanie tych nazwanych uprawnień: zezwól, odmów lub zapytaj. Polityka jest egzekwowana przez brokera przed wstrzyknięciem uwierzytelnienia, a nie jako sugestia dla modelu. Jeśli agent próbuje wykonać wywołanie objęte odmówionym uprawnieniem, np. w wyniku wstrzyknięcia promptu, żądanie nigdy nie trafia do sieci.
Nie każdy łącznik ma dziś takie rozstrzyganie. Niektóre API nie publikują stabilnego mapowania zakresów na endpointy. Przykładem jest GraphQL GitHuba: REST można zmapować, ale GraphQL jeszcze nie. Dla tych łączników broker nadal kontroluje wstrzykiwanie danych uwierzytelniających i ścieżkę sieciową, a bramka uprawnień opiera się na ogólniejszej polityce łącznika lub hosta, którą platforma może faktycznie egzekwować. Uzupełniamy te dane, gdy pojawiają się upstream. Nie deklarujemy pokrycia, którego nie zbudowaliśmy.
Tokeny nie niosą uprawnień domyślnych. Uprawnienia są przydzielane przez brokera per agent, w zakresie obsługiwanym przez upstream. To połowa odpowiedzi oparta na uprawnieniach.
3. Pętla operacyjna i audyt
Zasada najmniejszych uprawnień działa tylko wtedy, gdy tryb awaryjny jest użyteczny. Agenci się rozwijają. Po sześciu tygodniach agent badawczy, który początkowo tylko czytał z Notion, może potrzebować zapisać podsumowanie. Typowe tryby awarii gdzie indziej: agent działa po cichu bez nowego uprawnienia i się psuje, albo operator w panice przyznaje zbyt szerokie uprawnienia i nigdy ich nie odbiera.
Odmowa żądania łącznika zwraca ustrukturyzowany 403: łącznik, metoda, ścieżka, bazowy URL i odpowiadające nazwy uprawnień, jeśli broker je rozpozna. Systemowy prompt agenta instruuje, jak zdiagnozować odmowę i jak poprosić dokładnie o to uprawnienie, generując dla użytkownika lub administratora link do jednorazowego przyznania. Dzięki temu ścieżka eskalacji pozostaje powiązana z konkretnym żądanym uprawnieniem, zamiast zamieniać się w „przyznaj wszystko”.
Żądania zmiany uprawnień trafiają do kolejki. Właściciele i administratorzy mogą je zatwierdzać lub odrzucać z poziomu panelu; zatwierdzone aktualizują politykę agenta, a kolejne próby przechodzą. Większość platform pomija tę pętlę. Bez niej „najmniejsze uprawnienia” pozostają na slajdzie, a nie w produkcji.
Ta sama ścieżka brokera zasila audyt. Logi sieciowe per run rejestrują aktywność sandboxa w sieci: HTTP, TCP, DNS i niższe warstwy dla ruchu nie-TCP. Żądania dopasowane do łącznika zawierają ustrukturyzowane metadane brokera: łącznik, dopasowane uprawnienie (jeśli dostępne), wynik (zezwól/odmów), metadane rozstrzygania uwierzytelnienia i flagę rozliczeniową. Jeśli ktoś później zapyta „co ten agent zrobił we wtorek o 15:00?”, można to odtworzyć z tych zapisów. Prewencja nie wyłapuje wszystkiego. Ślad audytowy pozwala dowiedzieć się, co się stało.
Czego nie rozwiązaliśmy
Nawet przy powyższych zabezpieczeniach agent z legalnym chat:write nadal może zostać nakłoniony do opublikowania kompromitującej wiadomości na kanale, do którego już ma dostęp. Broker ogranicza zasięg szkód; nie eliminuje ich całkowicie.
Drugą połową odpowiedzi są zatwierdzenia akcji wysokiego ryzyka, walidacja wyjścia i traktowanie wyników narzędzi jako nieufnych domyślnie. To prace na roadmapie, jeszcze nie w produkcie. Każdy, kto twierdzi, że rozwiązał problem zagubionego zastępcy end-to-end, coś sprzedaje.
To powinien być standard, nie funkcja
Bezpieczeństwo oparte na uprawnieniach istnieje od lat 70. Brokerowane dane uwierzytelniające są w OWASP LLM Top 10. Phantom tokeny powstały przed erą LLM. Nic z tego nie jest nieznane. Brakuje tego, bo wczesne platformy agentów optymalizowały pod „zrób demo” i przesuwały bezpieczeństwo na później, które często nie nadchodziło.
Następna generacja platform powinna mierzyć wyżej. Tokeny nie powinny trafiać do kontekstu modelu. Uprawnienia powinny być wyliczane per agent. Eskalacja uprawnień powinna przechodzić przez człowieka. Każda akcja powinna być audytowalna end-to-end. To nie jest nowość. To powinien być standard.
Gdy wybierasz platformę agentów, pytanie „czy jest bezpieczna?” nic nie daje. Każdy dostawca powie „tak”. Lepsze pytanie: pokaż mi swojego brokera i przeprowadź mnie przez scenariusz, gdy agent prosi o zakres, którego nie ma.
Broker domyślnie stoi przed każdym agentem na Zero. Inwentarz łączników, mapowania zakresów, polityki uprawnień i logika brokera są dostępne w repozytorium źródłowym Zero. Znalazłeś łącznik, którego nie obsługujemy? Zgłoś problem.
Źródła
Podstawowe
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (fundamentalna praca o systemach uprawnień)
- Mark Miller i in., Caja: bezpieczeństwo oparte na uprawnieniach dla webu, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Przytoczone incydenty z rzeczywistości
- PromptArmor, Google Antigravity Exfiltrates Data, listopad 2025
- Simon Willison, omówienie i analiza, 25 listopada 2025
