Agent AI w Microsoft Entra ID – nowy model tożsamości dla agentów AI
Czy agent AI powinien być traktowany jak użytkownik, aplikacja, konto techniczne czy zupełnie nowy typ tożsamości? Czy agent identity w Microsoft Entra ID to tylko nowa nazwa dla service principal? Czy agent AI może mieć konto użytkownika w Entra ID, a jeśli tak, czy oznacza to, że jest użytkownikiem…?
Pojawienie się agentów AI w środowiskach enterprise wymusza zmianę w podejściu do zarządzania tożsamością. Klasyczne modele IAM obsługiwały skutecznie trzy główne kategorie: użytkowników, aplikacje oraz konta techniczne. Agent AI nie mieści się jednak właściwie w żadnej z nich. Może działać autonomicznie, korzystać z API, wykonywać zadania w imieniu użytkownika, podejmować decyzje na podstawie kontekstu i pozostawiać w systemach ślad możliwy do audytu. Właśnie dlatego Microsoft rozwija w Entra ID osobny obszar związany z tożsamościami agentów.
Czym jest tożsamość agenta (agent identity)?
Tożsamość agenta (agent identity) to wyspecjalizowana tożsamość w Microsoft Entra ID, przeznaczona dla agenta AI. Jej zadaniem jest jednoznaczna identyfikacja agenta oraz umożliwienie mu uwierzytelniania wobec usług i aplikacji. Taki agent może uzyskiwać tokeny z Entra ID, korzystać z Microsoft Graph, usług webowych, aplikacji firmowych lub systemów zewnętrznych. W określonych scenariuszach może również działać w kontekście użytkownika, ale nadal pozostaje odrębnym bytem, który można rozpoznać w logach i objąć osobnymi zasadami kontroli.

Microsoft podaje, że dla agenta AI tożsamość agenta jest najczęściej dobrym wyborem, ale w zależności od wymagań obsługiwane jest przypisywanie również innych typów tożsamości Entra ID do agenta AI (Plan your agent identity architecture).
Czy tożsamość agenta to konto użytkownika Entra ID?
Tożsamość agenta (agent identity) nie jest zwykłym kontem użytkownika. Konto użytkownika w Entra ID reprezentuje człowieka i jest powiązane z mechanizmami typowymi dla kont osób fizycznych: hasłem, MFA, profilem organizacyjnym, skrzynką pocztową, członkostwem w zespołach czy przypisaniem do struktury firmy. Agent identity nie reprezentuje człowieka. Nie powinien być traktowany jak pracownik, konsultant ani konto współdzielone. To rozróżnienie ma duże znaczenie dla procesów zarządzania uprawnieniami, ponieważ inny powinien być cykl życia takiej tożsamości, inny model własności, inne przeglądy dostępów i inne kryteria oceny ryzyka.
Czy agent może mieć przypisane konto użytkownika?
Może, ale jest to szczególny przypadek. Microsoft opisuje również pojęcie agent’s user account, czyli konta użytkownika powiązanego relacją 1:1 z agent identity. Taki model jest potrzebny wtedy, gdy agent musi korzystać z zasobów wymagających technicznie obiektu użytkownika, na przykład skrzynki pocztowej, kalendarza, Microsoft Teams albo dokumentów. Nie oznacza to jednak, że agent staje się użytkownikiem w sensie zarządzania dostępem, lecz że dla zgodności z wybranymi usługami otrzymuje powiązany obiekt użytkownika. Z perspektywy zarządzania uprawnieniami taki obiekt nie powinien być analizowany w oderwaniu od odpowiadającej mu agent identity.
Czy agent identity to to samo co service principal?
Agent identity nie jest po prostu nową nazwą dla service principal. Microsoft opiera agent identities na tej samej infrastrukturze katalogowej, ale rozdziela je jako osobną kategorię tożsamości. Klasyczne service principals projektowano głównie z myślą o aplikacjach i workloadach, których charakter jest stosunkowo stabilny i przewidywalny. Agent AI może być tworzony dynamicznie, na przykład przez Copilot Studio, automatyzację lub API. Może istnieć krótko, pojawiać się masowo i działać w bardziej zmiennym kontekście biznesowym. Dlatego z punktu widzenia zarządzania dostępem agent identity wymaga innego podejścia niż tradycyjna application identity.
Czym jest agent identity blueprint?
Agent identity blueprint jest szablonem używanym do tworzenia tożsamości agentów. Zawiera wspólne właściwości, takie jak opis, role aplikacyjne, informacje o wydawcy, ustawienia protokołów uwierzytelniania i konfigurację tokenów. Istotne jest to, że poświadczenia wykorzystywane do uwierzytelniania agenta są konfigurowane na poziomie blueprintu, a nie bezpośrednio na pojedynczej tożsamości agenta. Dzięki temu organizacja może stosować spójne zasady dla wielu agentów utworzonych z tego samego szablonu.

Zarządzanie tożsamością agenta AI
W modelu Microsoftu ważne jest rozróżnienie między właścicielem technicznym a sponsorem biznesowym. Właściciel odpowiada za konfigurację i utrzymanie operacyjne agenta. Sponsor biznesowy odpowiada za cel, zasadność istnienia, decyzje dotyczące cyklu życia oraz przeglądy dostępów. Dzięki takiemu podejściu łatwiej jest odpowiedzieć na pytanie „Kto odpowiada za użycie agenta i dalsze jego utrzymywanie?”. Właścicieli i sponsorów można konfigurować z poziomu szczegółów wybranej tożsamości lub blueprintu.

Uprawnienia i autoryzacja
Tożsamość agenta może być wykorzystana w kontekście aplikacji albo użytkownika, zależnie od scenariusza, ale powinna być objęta dodatkowymi mechanizmami kontroli. Może otrzymywać role, uprawnienia aplikacyjne, dostęp do usług lub przypisania wymagane do wykonywania określonych zadań. Dla zespołów IGA oznacza to konieczność zadawania tych samych pytań, dotyczących innych tożsamości uprzywilejowanych i nieludzkich: kto zatwierdził dostęp, czy jest on adekwatny, czy ma ograniczony czas obowiązywania, czy podlega przeglądom i czy można go jednoznacznie przypisać do właściciela lub sponsora.
Monitoring i audyt
Dla agentów AI kluczowe znaczenie ma możliwość odróżnienia ich aktywności od działań użytkowników i klasycznych aplikacji. Microsoft wprowadził w logach mechanizmy pomagające identyfikować aktywność agentów, między innymi zdarzenia typu agentSignIn oraz filtry takie jak Agent type i Is Agent. To ważne dla audytu, SOC i zespołów odpowiedzialnych za zarządzanie dostępami i uprawnieniami. Bez takiego rozróżnienia trudno byłoby ustalić, czy daną operację wykonał człowiek, aplikacja, agent identity, blueprint czy powiązane konto użytkownika agenta.
Podsumowanie – co tożsamość agenta (agent identity) oznacza dla IGA i IDM?
Agent identity nie jest jedynie nową etykietą w katalogu. To rozszerzenie modelu tożsamości o kolejną kategorię bytów nieludzkich. Agent AI nie jest zwykłym użytkownikiem i nie jest też dokładnym odpowiednikiem klasycznej aplikacji. Może potrzebować własnej tożsamości, właściciela, sponsora, polityk Conditional Access, logów, przeglądów dostępów i jasno określonego cyklu życia. Dla zespołów IGA i IDM oznacza to nowy obszar pracy: Agent Identity Governance. Chodzi o zarządzanie dostępem, odpowiedzialnością i ryzykiem agentów AI w taki sposób, aby ich działania były widoczne, rozliczalne i zgodne z modelem kontroli obowiązującym w organizacji.




