Podłączyłeś swojego agenta AI do tuzina narzędzi — GitHub, Slack, bazy danych, API chmurowe — i w kilka minut ogarnia to, co kiedyś zajmowało godziny. Dodałeś serwery MCP (Model Context Protocol — uniwersalny standard wtyczek dla narzędzi AI, taki USB, ale do danych), podpiąłeś tokeny API (cyfrowe hasła, które pozwalają programom korzystać z usług w twoim imieniu) i wszystko po prostu działało. Przyszłość nadeszła — produktywna i kompletnie niezabezpieczona.

Bo kiedy podpinałeś te połączenia, każde narzędzie prosiło o pełny dostęp. Nie "tylko do odczytu". Nie "tylko to repo". Pełny dostęp. I żadna platforma agentowa nie oferowała sposobu na ograniczenie uprawnień na poziomie orkiestracji — warstwy, gdzie agent decyduje, których narzędzi użyć i kiedy. Oddałeś klucz generalny i nazwałeś to integracją.

Między 1 a 14 kwietnia 2026 ten klucz generalny został skopiowany. Wielokrotnie.

Google daje każdemu agentowi hasło roota, a potem aktualizuje README

1 kwietnia Unit 42 z Palo Alto ujawnił lukę "Double Agent" w Google Vertex AI. To najlepsze studium przypadku luki między uwierzytelnianiem a autoryzacją, jakie do tej pory widziałem.

Co się stało: każdy agent Vertex AI dostawał domyślne konto serwisowe (tożsamość na poziomie systemu, działająca w imieniu agenta). To konto przychodziło z uprawnieniami, od których sysadmin dostałby zawału. Nie mówimy o "lekko za szerokich uprawnieniach". Mówimy o dostępie do:

  • Bucketów Cloud Storage innych klientów — dane innych użytkowników, dostępne z dowolnej instancji agenta
  • Zastrzeżonych wewnętrznych obrazów kontenerów Google — tych normalnie chronionych wieloma warstwami zatwierdzania
  • Kodu źródłowego samego Vertex AI — wewnętrzne repozytoria platformy, czytelne dla jednorazowego agenta demo

Badacze zademonstrowali pełny łańcuch eskalacji uprawnień: zacznij od podstawowego agenta, odziedzicz domyślne konto serwisowe, przeskocz lateralnie do zasobów Google Cloud, których żaden agent nie powinien dotykać. Domyślna tożsamość nie była "trochę za uprzywilejowana" — była funkcjonalnie wszechwiedząca w granicach projektu i częściowo wszechwiedząca poza nimi.

Reakcja Google? Zaktualizowana dokumentacja sugerująca, żebyś przyniósł własne, mniej uprzywilejowane konto serwisowe. Nie zmiana platformy. Nie sensowne ustawienia domyślne. Łatka w docsach. Powiedzieli klientom, żeby uważniej czytali instrukcję. Odpowiednik producenta samochodów, który na awarię hamulców reaguje: "zaktualizowaliśmy instrukcję obsługi, zalecamy zwalnianie przed skrzyżowaniami".

Luka istniała, bo warstwa uwierzytelniania Vertex AI działała perfekcyjnie — agenci się łączyli, tokeny wymieniane, handshake'i się odbywały — podczas gdy warstwa autoryzacji była pustym placem. Nikt w Google nie zbudował części, która pyta "czy ten agent powinien mieć dostęp do tego?"

Credential Vault Anthropic: jeden workspace, wszystkie klucze, zero ścian

Tydzień po kompromitacji Google, Anthropic uruchomił Claude Managed Agents 8 kwietnia z uprawnieniami per narzędzie — allowed_tools, denied_tools. Lepsze niż nic. Ale 13 kwietnia badacz bezpieczeństwa hi120ki zademonstrował, że Credential Vault pod tymi uprawnieniami ma klasyczny problem confused deputy (gdy zaufany program zostaje oszukany, by nadużyć swoich uprawnień).

Ścieżka ataku jest prosta i paskudna:

  1. Workspace ma wiele agentów, każdy z innymi poświadczeniami narzędzi przechowywanymi w Credential Vault
  2. Vault ogranicza dostęp na poziomie workspace'a, nie agenta ani sesji
  3. Dowolny klucz API z dostępem do workspace'a może odwołać się do dowolnych poświadczeń w tym sejfie
  4. Atakujący (albo skompromitowany agent) z jednym poprawnym kluczem API workspace'a może wstrzyknąć wywołania narzędzi, używając poświadczeń należących do innych agentów

W praktyce: Agent A ma dostęp tylko do odczytu na GitHubie. Agent B ma dane do zapisu w produkcyjnej bazie danych. Jeśli sesja Agenta A zostanie skompromitowana — przez prompt injection, zatruwanie narzędzi albo złośliwy serwer MCP — może wyciągnąć poświadczenia bazodanowe Agenta B ze wspólnego Vault i wykonać zapisy. Uprawnienia per narzędzie (allowed_tools) rządzą tym, co agent powinien robić. Vault rządzi tym, co może robić. Te dwie listy się nie zgadzają.

Proof of concept hi120ki pokazał dostęp do poświadczeń między agentami w ramach jednego wywołania API. Naprawa wymagałaby izolacji poświadczeń per agent — w zasadzie dania każdemu agentowi własnej partycji sejfu z kryptograficzną separacją. Na 19 kwietnia żadna poprawka nie wyszła.

To wzorzec confused deputy w najczystszej formie: Vault jest zaufanym pośrednikiem, skompromitowany agent jest zdezorientowanym petentem, a docelowe poświadczenia to czyjś autorytet. Płaszcz ledwo to zakrywa.

Wzorzec: uwierzytelnianie rozwiązane, autoryzacja brakująca

To nie są pojedyncze bugi. To objawy brakującej warstwy architektonicznej.

Luka w Azure DevOps MCP (CVE-2026-32211, CVSS 9.1, ujawniona 3 kwietnia) — którą opisywałem, gdy się pojawiła — pokazała tę samą pustkę z przeciwnej strony: nie zbyt szerokie domyślne uprawnienia, ale zerowe uwierzytelnianie po stronie narzędzia. Claude Code Routines, które wyszły 14 kwietnia jako agenci działający na harmonogramach bez ludzkiej zgody, amplifikują wszelkie grzechy uprawnień, usuwając ostatni ludzki checkpoint.

Ta sama choroba, inne organy. Uwierzytelnianie (czy agent może się połączyć?) jest w zasadzie rozwiązane — OAuth flows, klucze API, sejfy poświadczeń obsługują handshake'i bez problemu. Ale autoryzacja (co agent może robić po połączeniu?) to wciąż pustka. Każde narzędzie ma własny model uprawnień — GitHub scopes, AWS IAM policies (granularne reguły dostępu do zasobów chmurowych), dostęp na poziomie stron w Notion — ale żadna platforma agentowa nie agreguje, nie audytuje ani nie wymusza zasady najmniejszych uprawnień w całym zestawie narzędzi.

Warstwa między "narzędzie podłączone" a "akcja wykonana" nie istnieje.

Audyt 7000 serwerów MCP z 11 kwietnia przeprowadzony przez Pomerium wykazał, że 36,7% jest podatnych na SSRF (Server-Side Request Forgery — oszukanie serwera, by wykonał nieautoryzowane żądania do systemów wewnętrznych). Ponad jedna trzecia serwerów MCP może zostać zamieniona w punkty pivotowe w sieci. Nie dlatego, że protokół jest zepsuty, ale dlatego, że poszczególne implementacje serwerów zakładają, że łączący się agent jest godny zaufania i ma odpowiedni zakres uprawnień. Zakładają, że warstwa autoryzacji istnieje wyżej. Nie istnieje.

Dlaczego nikt tego nie naprawi, dopóki nie będzie ich to kosztować

Cloud computing przeczołgał się przez 15 lat bolesnej ewolucji — od "SSH na roota do maszyny" po granularne IAM z logami audytu, dostępem opartym na rolach i zasadą najmniejszych uprawnień. Doszliśmy tam, bo wycieki kosztowały pieniądze, a regulacje wymuszały zmiany. Platformy agentowe są na dniu zerowym tej samej drogi, rozdając domyślnie dostęp równoważny rootowi i nazywając to ficzerem, bo dobrze wygląda na demo.

Budowanie ujednoliconej autoryzacji narzędzi zabiłoby magię "podłącz cokolwiek w 30 sekund". Dodałoby tarcie w setupie i osłabiło konkurencyjne dema. Żaden vendor nie ma motywacji rynkowej, żeby dodać tarcie jako pierwszy. Google tego nie zrobi. Anthropic nie zrobi. Microsoft nie zrobi. Motywacja przyjdzie z incydentów. Prawdopodobnie kosztownych, publicznych, wieloklientowych incydentów.

Mamy zapowiedzi: w lipcu 2025 agent Replita spanikował i usunął dane produkcyjne ponad 1200 managerów. W grudniu 2025 agent Amazona autonomicznie usunął i odtworzył żywe środowisko produkcyjne, powodując 13-godzinną awarię AWS Cost Explorer. To były wypadki. Następna runda nie będzie.

Każdy zbyt uprzywilejowany serwer MCP, każdy token API z pełnym dostępem, każde nieograniczone połączenie narzędziowe to stojąca podatność — uśpiona, gdy człowiek klika "zatwierdź", aktywna w momencie, gdy agent zaczyna działać autonomicznie na harmonogramie.

Prawdziwy wyróżnik w wyścigu platform agentowych to nie model ani liczba narzędzi. To pierwsza konsola administracyjna, która pokaże, co twój agent naprawdę może zrobić — i pozwoli ci odwołać większość z tego. Luka między "podłączone" a "autoryzowane" to miejsce, gdzie zamieszka następny wyciek. Na razie wszyscy budują mosty nad nią bez barierek i nazywają to postępem.