Microsoft zaprojektował rolę Agent ID Administrator z jednym celem: zarządzanie cyklem życia tożsamości agentów AI w organizacji. Dokumentacja była jasna — rola zarządza obiektami związanymi z agentami: planami, tożsamościami agentów, użytkownikami agentów. Tylko tymi obiektami. Nic poza nimi.
Silverfort 24 lutego 2026 roku odkrył że ta granica nie istniała. Użytkownik z rolą Agent ID Administrator mógł przejąć dowolny Service Principal w tenancie — nie tylko te związane z agentami, ale każdy. Stać się właścicielem, dodać własne poświadczenia, uwierzytelnić się jako ta tożsamość. Odziedziczyć wszystkie jej uprawnienia.
Noa Ariel z Silverfort ujmuje to wprost: "To jest pełne przejęcie Service Principal."
Czym są Service Principals i dlaczego to ma znaczenie
Żeby zrozumieć wagę tej podatności, trzeba zrozumieć co w Microsoft Entra ID robi Service Principal.
Gdy aplikacja jest rejestrowana w Entra ID, tworzone są dwa obiekty: globalny obiekt aplikacji i lokalny Service Principal — cyfrowa karta tożsamości dla oprogramowania w danym tenancie. To przez Service Principal aplikacja się uwierzytelnia, otrzymuje przypisania ról i uzyskuje dostęp do zasobów organizacji.
Service Principals są tożsamościami za wszystkim co działa automatycznie: potoki CI/CD, skrypty automatyzacji, narzędzia bezpieczeństwa, integracje między systemami, połączenia z zewnętrznymi usługami. W wielu organizacjach Service Principals mają uprawnienia, których nie mają nawet administratorzy — dostęp do całego Microsoft Graph API, uprawnienia do odczytu i zapisu katalogów, prawa do zarządzania innymi tożsamościami.
Silverfort zbadał środowiska klientów: 99% tenantów ma co najmniej jeden uprzywilejowany Service Principal. Ponad połowa już używa tożsamości agentów — a z tych prawie połowa ma ich ponad 100. Warunki dla eskalacji uprawnień przez tę podatność istniały w niemal każdej organizacji używającej Entra ID.
Jak działał atak
Mechanizm był prosty i elegancki zarazem.
Agent identities w Microsoft Entra ID są zbudowane na tych samych fundamentalnych prymitywach katalogu co zwykłe aplikacje i Service Principals — aplikacjach i Service Principalach właśnie. Microsoft dodał rolę Agent ID Administrator żeby zarządzać nową warstwą kontroli tożsamości agentów. Zgodnie z dokumentacją rola miała być ograniczona wyłącznie do obiektów związanych z agentami.
Problem: akcje takie jak aktualizacja właścicieli tożsamości agentów były zaimplementowane na poziomie Service Principala — bo tożsamości agentów to po prostu specjalny rodzaj Service Principala. Ta implementacja nie rozróżniała między Service Principalami agentów a wszystkimi innymi Service Principalami w tenancie. Przypisanie właściciela do tożsamości agenta i przypisanie właściciela do dowolnego innego Service Principala były technicznie tym samym wywołaniem API.
Scenariusz ataku opisany przez Silverfort w demonstracji: użytkownik z rolą Agent ID Administrator identyfikuje uprzywilejowany Service Principal — na przykład taki z przypisaną rolą Global Administrator. Przypisuje się jako właściciel tego Service Principala przez API Graph. Dodaje własne poświadczenia. Uwierzytelnia się jako ten Service Principal. Dziedziczy rolę Global Administrator całego tenantu.
Eskalacja od roli zaprojektowanej dla AI do pełnej kontroli nad organizacją. Bez żadnej podatności w tradycyjnym sensie — tylko błąd w zakresie roli który pozwalał na operacje poza zamierzonym zasięgiem.
Dodatkowy szczegół: interfejs nie ostrzegał
Silverfort zwraca uwagę na jeden praktyczny element incydentu który zasługuje na osobne zdanie.
Interfejs użytkownika Entra ID nie oznaczał roli Agent ID Administrator jako uprzywilejowanej. Administratorzy przypisujący tę rolę nie widzieli żadnego wizualnego sygnału że nadają uprawnienia mogące prowadzić do eskalacji. Rola wyglądała jak administracyjna funkcja zarządzania narzędziami AI — coś co można przypisać osobie odpowiedzialnej za wdrożenia agentów bez szczególnej ostrożności.
Microsoft zapowiedział że rozbieżność między interfejsem a dokumentacją dotycząca wskaźnika "uprzywilejowana" zostanie naprawiona osobno. Łatka eliminuje błąd funkcjonalny — ale luka informacyjna która prowadziła do nieświadomego nadawania zbyt szerokich uprawnień wymaga własnej poprawki.
Ten sam wzorzec w nowej warstwie
Przez cały kwiecień cyberflux opisywał jak nowe warstwy infrastruktury AI dziedziczą strukturalne problemy bezpieczeństwa znane z poprzednich generacji.
Raport OX Security o architektonicznym błędzie w STDIO w MCP pokazał że protokół agentowy zbudowany na standardowych prymitywach Unix dziedziczy ich właściwości bezpieczeństwa — i że "oczekiwane zachowanie" może być jednocześnie krytyczną podatnością. CVE-2026-32211 w Azure MCP Server pokazał że brak autentykacji może być decyzją projektową wynikającą z założeń o środowisku. Comment and Control i Gemini CLI pokazały że agenty AI w potokami CI/CD dziedziczą podatność na wstrzyknięcie przez niezaufane wejście.
Entra Agent ID Administrator to ta sama klasa problemu na poziomie tożsamości: warstwa zarządzania agentami AI zbudowana na fundamencie istniejących prymitywów katalogu — Service Principals, właścicielstwo aplikacji, poświadczenia — bez ścisłego ograniczenia zakresu operacji do obiektów agentowych. Nowa funkcja zbudowana na starych fundamentach, z błędem wynikającym dokładnie z tej architektury.
Noa Ariel z Silverfort podsumowuje to precyzyjnie: "Tożsamości agentów są częścią szerszego przejścia ku tożsamościom nieludzkim, zbudowanych dla ery agentów AI. Gdy uprawnienia ról są nakładane na wspólne fundamenty bez ścisłego ograniczenia zakresu, dostęp może wykraczać poza to co było pierwotnie zamierzone."
99% tenantów — i rola jeszcze nie w szerokim użyciu
Jest jeden szczegół raportu Silverfort który wymaga podkreślenia ze względu na konsekwencje dla przyszłości.
Rola Agent ID Administrator jest stosunkowo nowa i jeszcze nie jest w szerokim użyciu. Silverfort widzi ją w środowiskach klientów, ale nie masowo. Podatność jest już naprawiona — Microsoft wdrożył łatkę do wszystkich środowisk chmurowych 9 kwietnia, nie wymagając żadnych działań ze strony użytkowników.
Ale wniosek strukturalny nie znika razem z łatką. Warunki dla esploitowania tej klasy błędu — uprzywilejowane Service Principals bez odpowiedniej ochrony właścicielstwa — istniały i wciąż istnieją w 99% tenantów. Gdy organizacje będą przypisywać rolę Agent ID Administrator coraz częściej w miarę wdrażania agentów AI — a będą, bo to jest dokładnie do czego rola jest przeznaczona — każdy przyszły błąd zakresu w tej warstwie trafi na gotowy grunt.
Silverfort rekomenduje traktowanie Service Principals jako infrastruktury krytycznej na równi z kontami administratorów — z odpowiednim monitorowaniem zmian właścicielstwa i dodawania poświadczeń w dziennikach zdarzeń. To jest praktyczna rekomendacja niezależna od konkretnej podatności: w środowisku gdzie agenty AI dostają własne tożsamości a liczba tożsamości nieludzkich przekracza ludzkie, klasyczne podejście "pilnuj kont administratorów" jest niewystarczające.
Co zrobić
Łatka jest już wdrożona przez Microsoft do wszystkich środowisk chmurowych — nie jest wymagana żadna akcja ze strony administratorów żeby ją aktywować. Po naprawie każda próba przypisania właścicielstwa nad niebędącym agentem Service Principalem przez rolę Agent ID Administrator kończy się błędem "Forbidden".
Silverfort rekomenduje jednak aktywne działania weryfikacyjne: sprawdzenie AuditLogspod kątem nieoczekiwanych zmian właścicielstwa kont lub tworzenia nowych poświadczeń na wrażliwych kontach — szczególnie dla Service Principals z uprawnieniami administracyjnymi lub wysokim poziomem dostępu do Microsoft Graph API.
Dla organizacji które przypisały rolę Agent ID Administrator przed 9 kwietnia: weryfikacja czy w tym okresie nie nastąpiły nieautoryzowane zmiany właścicielstwa Service Principali jest zalecana jako krok prewencyjny.
Podsumowanie
Błąd w Microsoft Entra Agent ID Administrator to historia o tym że warstwa tożsamości AI dziedziczy strukturalne problemy warstwy tożsamości ogólnej — i że "ograniczona do agentów" rola może nie być naprawdę ograniczona gdy jest zbudowana na prymitywach stosowanych przez cały katalog.
Microsoft naprawił konkretny błąd zakresu. Ale wzorzec pozostaje: każda nowa warstwa infrastruktury AI budowana na istniejących fundamentach — prymitywach katalogowych, protokołach komunikacji, mechanizmach uwierzytelnienia — dziedziczy zarówno ich możliwości jak i ich podatności. Gdy zakres nie jest ściśle weryfikowany na poziomie implementacji, "zaprojektowane dla agentów" może w praktyce oznaczać "działa na wszystkim."
99% tenantów ma co najmniej jeden uprzywilejowany Service Principal. Adopcja tożsamości agentów rośnie. Kombinacja tych dwóch faktów oznacza że ten konkretny błąd mógł mieć znacznie szerszy zasięg gdyby był odkryty przez atakujących przed badaczami Silverfort.
Źródła
Silverfort — pierwotny raport techniczny z opisem mechanizmu i demonstracją: https://www.silverfort.com/blog/agent-id-administrator-scope-overreach-service-principal-takeover-in-entra-id/
The Hacker News — omówienie podatności z komentarzem badaczki Noa Ariel: https://thehackernews.com/2026/04/microsoft-patches-entra-id-role-flaw.html
Hackread — szczegóły odkrycia i chronologia odpowiedzialnego ujawnienia: https://hackread.com/microsoft-entra-agent-id-flaw-tenant-takeover/
CSO Online — analiza kontekstu organizacyjnego i danych o skali ryzyka: https://www.csoonline.com/article/4163708/microsoft-patched-an-agent-only-role-that-was-not.html
Security Affairs — szczegóły techniczne i rekomendacje: https://securityaffairs.com/191414/security/microsoft-fixes-entra-id-flaw-enabling-privilege-escalation.html
