Podłączyłeś swojego agenta AI do Slacka, GitHuba i Jiry. Platforma grzecznie wyświetliła okienko: "Zezwolić na dostęp do Slacka?" Kliknąłeś tak. Czułeś się odpowiedzialny. Czułeś, że masz kontrolę.
Nie miałeś. Agent właśnie wysłał twojemu CEO na priv draft raportu o bugach przeznaczony na #engineering. Bramka uprawnień nigdy nie pytała o odbiorców, kanały ani o to, co tak naprawdę oznacza "dostęp do Slacka", gdy kluczami obraca maszyna.
Trzy platformy, jeden wzorzec, zero głębi
Dwa tygodnie temu dyskusja kręciła się wokół tego, że platformy agentowe w ogóle nie mają sensownej autoryzacji — agenty z dostępem roota, a nikt nie buduje sudo. Ta rozmowa jest już nieaktualna. Wszystkie trzy główne platformy odpowiedziały: workflowy zatwierdzania narzędzi, te okienka "Na pewno?" wyskakujące, zanim agent AI (program działający w twoim imieniu, nie tylko chatbot) zrobi coś poważnego. Luka w autoryzacji nie została załatana. Została zaklejona tapetą.
ADK od Google dodało potwierdzenia akcji na Cloud Next (22–24 kwietnia). Managed Agents od Anthropic, uruchomione 8 kwietnia, miały polityki uprawnień per narzędzie od pierwszego dnia. Agents SDK od OpenAI dostarczyło callbacki needs_approval w aktualizacji z 15 kwietnia. Trzy firmy, zbieżność na ten sam pomysł — jak trzech architektów, którzy niezależnie zaprojektowali ten sam dziurawy dach.
Wzorzec jest identyczny we wszystkich trzech: zatwierdzasz lub odrzucasz dostęp na poziomie narzędzia. "Zezwól na Slacka" albo "Odmów Slacka". Binarnie. Tak albo nie. Bramkarz sprawdzający dowody przy wejściu do budynku, podczas gdy drzwi do każdego mieszkania w środku stoją otworem.
Gdzie naprawdę mieszka zagrożenie
Zasięg rażenia złego wywołania narzędzia — szkody, jakie faktycznie może wyrządzić — tkwi w parametrach: na który kanał Slacka leci wiadomość, na który branch ktoś robi force-push, które zapytanie SQL odpala się na produkcyjnej bazie, który projekt w Jirze agent zalewa automatycznie wygenerowanymi ticketami.
Uczciwie mówiąc, Google ADK i OpenAI przekazują parametry wywołania do callbacków pisanych przez programistę. Możesz napisać kod typu return amount > 1000, żeby blokować kosztowne operacje. Ale tu jest kluczowe rozróżnienie: platforma daje ci hook, nie siatkę bezpieczeństwa. Sam piszesz reguły, w gołym Pythonie, dla każdego narzędzia, każdego parametru, każdego edge case'a. Żadnego deklaratywnego silnika polityk. Żadnych wbudowanych allowlist. Żadnego przełącznika "postuj tylko na #engineering i #random" w dashboardzie.
Implementacja Anthropic jest jeszcze prostsza — ich polityki uprawnień działają wyłącznie na nazwach narzędzi. Event user.tool_confirmation przyjmuje dokładnie dwie odpowiedzi: "allow" lub "deny". Żadnego pola na ograniczenia argumentów. Żadnej logiki warunkowej. Agent albo może używać Slacka, albo nie.
Jak napisał badacz bezpieczeństwa Simon Willison we wrześniu 2024: "Gdy agent LLM przetworzy niezaufane dane wejściowe, musi być ograniczony tak, aby te dane nie mogły wywołać żadnych konsekwentnych akcji." Bramki na poziomie narzędzi tego nie zapewniają. Ograniczają, które akcje istnieją, a nie co te akcje robią.
Ten film już widzieliśmy
Wzorzec to kopia z uprawnień mobilnych około 2008 roku. Android 1.0 przyznawał ogólnikowy "dostęp do aparatu" — bez rozróżnienia między apką do selfie a skanerem dokumentów po cichu fotografującym twoje biurko. Google potrzebowało siedmiu lat i Androida 6.0 Marshmallow (2015), żeby dostarczyć kontekstowe kontrole nad jak aplikacja używa aparatu, a nie tylko czy może.
Platformy agentowe są dziś na etapie Androida 1.0. Okienko uprawnień istnieje. Wygląda jak bezpieczeństwo. Nim nie jest.
Microsoft powiedział na głos to, o czym inni milczą
22 kwietnia blog developerski Microsoftu opublikował brutalnie szczere przyznanie: "Samo wykonywanie instrukcji nie powinno być traktowane jako granica bezpieczeństwa." Ich własne testy red team — przeprowadzone w ramach Agent Governance Toolkit, który udostępnili jako open source na początku miesiąca — ujawniły 26,67% wskaźnik naruszeń polityk przy zabezpieczeniach opartych wyłącznie na promptach. Jedno na cztery niebezpieczne wywołania prześlizguje się, jeśli polegasz na tym, że LLM sam się upilnuje.
AGT jest najbliższy prawdziwemu rozwiązaniu: warstwa middleware między twoim agentem a jego narzędziami, wymuszająca deklaratywne reguły polityk napisane w YAML, OPA lub Cedar. Faktycznie inspekcjonuje parametry. Faktycznie bramkuje na podstawie wartości argumentów. Ale to middleware, które sam doklejasz — nie jest natywne dla żadnej platformy agentowej. Dobra taśma klejąca, ale wciąż taśma klejąca.
Cena zrobienia tego porządnie
Bramkowanie na poziomie parametrów jest naprawdę trudne. Wymaga rozumienia semantycznego — wiedzieć, że #general to kanał publiczny, a #exec-compensation już nie. Dodaje opóźnienia do każdego wywołania narzędzia w systemach, które i tak walczą z limitami okna kontekstowego (ile tekstu AI jest w stanie "widzieć" naraz). I co najgorsze, tworzy zmęczenie zatwierdzaniem: im bardziej granularne bramki, tym szybciej użytkownicy trenują się klikać "zatwierdź wszystko" bez czytania — dokładnie to zachowanie, które zamienia uprawnienia w teatr.
Co faktycznie powinieneś zrobić
Dopóki platformy nie dostarczą bramek świadomych parametrów jako natywnej funkcji, masz dwie uczciwe opcje. Pierwsza: zbuduj middleware sprawdzający argumenty wywołań narzędzi wobec allowlist — bezpieczne kanały, bezpieczne branche, bezpieczne wzorce zapytań. Druga: zaakceptuj, że kliknięcie "Zezwól na Slacka" oznacza "pozwól agentowi robić wszystko, co obsługuje Slack API" i planuj odpowiednio.
Okienko uprawnień na twojej platformie agentowej to placebo. Kontroluje, które drzwi agent może otworzyć, ale nie to, co agent robi w środku pokoju. Trzy platformy wysłały ten sam zamek w kwietniu 2026 i żadna z nich nie dołączyła rygla.
