Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Konto użytkownika agenta jest wyspecjalizowanym typem tożsamości zaprojektowanym w celu wypełnienia luki między agentami a możliwościami użytkownika ludzkiego. Konto użytkownika agenta umożliwia aplikacjom opartym na sztucznej inteligencji interakcję z systemami i usługami wymagającymi tożsamości użytkowników przy zachowaniu odpowiednich granic zabezpieczeń i mechanizmów kontroli zarządzania. Umożliwia ona organizacjom zarządzanie dostępem agenta przy użyciu podobnych możliwości, jak w przypadku użytkowników ludzkich.
Przykład scenariuszy konta użytkownika agenta
Czasami nie wystarczy, aby agent wykonywał zadania w imieniu użytkownika lub działał jako aplikacja autonomiczna. W niektórych scenariuszach agent musi działać jako użytkownik, działając zasadniczo jako pracownik cyfrowy. Poniżej przedstawiono przykładowe scenariusze, w których konto użytkownika agenta ma zastosowanie:
- Organizacja potrzebuje długoterminowych pracowników cyfrowych, którzy pełnią funkcję członków zespołu ze skrzynkami pocztowymi, dostępem do czatów i integracją w systemach KADR.
- Agent musi uzyskać dostęp do API lub zasobów, które są dostępne tylko dla tożsamości użytkownika
- Agent musi uczestniczyć w przepływach pracy zespołowej jako członek zespołu
Z tych powodów tworzone jest konto użytkownika agenta. Konto użytkownika agenta jest opcjonalne i powinno być tworzone tylko w przypadku interakcji, w których agent musi działać jako użytkownik lub uzyskiwać dostęp do zasobów ograniczonych do kont użytkowników.
Konto użytkownika agenta
Konto użytkownika agenta reprezentuje podtyp tożsamości użytkownika w ramach Microsoft Entra. Te tożsamości zostały zaprojektowane tak, aby umożliwić aplikacjom agentów wykonywanie akcji w kontekstach, w których wymagana jest tożsamość użytkownika. W przeciwieństwie do nieagentowych kont usługowych lub tożsamości aplikacji, konto użytkownika agenta otrzymuje tokeny z oświadczeniem idtyp=user, co umożliwia mu dostęp do interfejsów API i usług, które wymagają tożsamości użytkowników. Utrzymuje również ograniczenia bezpieczeństwa niezbędne dla tożsamości nieludzkich.
Konto użytkownika agenta nie jest tworzone automatycznie. Wymaga on jawnego procesu tworzenia, który łączy go z tożsamością agenta nadrzędnego. Ta relacja nadrzędny-podrzędna jest podstawowa do zrozumienia, w jaki sposób konto użytkownika agenta działa i jest zabezpieczone w Microsoft Entra. Po ustanowieniu ta relacja jest niezmienna i służy jako kamień węgielny modelu zabezpieczeń dla konta użytkownika agenta. Relacja jest mapowaniem jeden do jednego (1:1). Każda tożsamość agenta może mieć co najwyżej jedno skojarzone konto użytkownika agenta, a każde konto użytkownika agenta jest połączone z dokładnie jedną tożsamością agenta nadrzędnego, połączoną z dokładnie jedną aplikacją strategii tożsamości agenta.
Konto użytkownika agenta:
- Jest również tworzony przy użyciu szablonu tożsamości agenta.
- Jest zawsze skojarzony z określoną tożsamością agenta określoną podczas tworzenia.
- Ma unikatowe identyfikatory oddzielone od tożsamości agenta.
- Może uwierzytelniać się tylko poprzez przedstawienie tokenu przypisanego do powiązanej tożsamości agenta.
Relacja między kontem użytkownika agenta a tożsamością agenta
Strategia tożsamości agenta nie ma domyślnie uprawnień do tworzenia konta użytkownika agenta, ponieważ ta funkcja jest opcjonalna i nie zawsze potrzebna. Jest to uprawnienie, które musi zostać jawnie przyznane schematowi tożsamości agenta.
Konto użytkownika agenta jest tworzone przy użyciu strategii tożsamości agenta. Po udzieleniu odpowiednich uprawnień, szablon tożsamości agenta może utworzyć konto użytkownika agenta i ustanowić relację nadrzędną z określoną tożsamością agenta. Tożsamość agenta jest traktowana jako element nadrzędny konta użytkownika agenta.
Administratorzy zarządzają cyklem życia konta użytkownika agenta. Administrator może usunąć konto użytkownika agenta, gdy jego funkcje nie będą już potrzebne.
Model uwierzytelniania i zabezpieczeń
Model uwierzytelniania konta użytkownika agenta różni się znacznie od kont użytkowników ludzkich:
Poświadczenia tożsamości federacyjnej: Uwierzytelnianie odbywa się za pośrednictwem poświadczeń przypisanych do konta użytkownika agenta. W systemach produkcyjnych użyj poświadczeń tożsamości federacyjnej (FIC). Te poświadczenia są używane do uwierzytelniania zarówno szablonu tożsamości agenta, jak i samej tożsamości agenta. Poświadczenia przypisane do użytkownika są używane do uwierzytelniania w ekosystemie agentów.
Model poświadczeń z ograniczeniami: konto użytkownika agenta nie ma zwykłych poświadczeń, takich jak hasła. Zamiast tego jest ona ograniczona do używania poświadczeń udostępnianych za pośrednictwem relacji nadrzędnej. To ograniczenie dotyczące poświadczeń, wraz z ograniczeniami logowania interakcyjnego, gwarantuje, że konto użytkownika agenta nie może być używane jak konto użytkownika standardowego.
Mechanizm podszywania się: Skojarzona tożsamość agenta może podszywać się pod konto użytkownika podrzędnego agenta. Dzięki niej nadrzędna logika biznesowa może uzyskiwać tokeny i działać jako konto użytkownika agenta w razie potrzeby.
Możliwości konta użytkownika agenta
Konto użytkownika agenta ma możliwości, które umożliwiają jej efektywne działanie w Microsoft 365 i innych środowiskach:
Konto użytkownika agenta można dodać do grup Microsoft Entra, w tym grup dynamicznych, umożliwiając dziedziczenie uprawnień przyznanych tym grupom. Nie można go jednak dodać do grup z możliwością przypisywania ról.
Konto użytkownika agenta może uzyskiwać dostęp do zasobów i korzystać z innych funkcji współpracy zwykle zarezerwowanych dla użytkowników ludzkich.
Konto użytkownika agenta można dodać do jednostek administracyjnych, podobnie jak użytkowników ludzkich.
Konto użytkownika agenta może być przypisane do licencji, co jest często niezbędne do aprowizacji Microsoft 365 zasobów.
Ograniczenia zabezpieczeń
Konto użytkownika agenta działa zgodnie z określonymi ograniczeniami zabezpieczeń w celu zapewnienia odpowiedniego użycia:
Ograniczenia poświadczeń: konto użytkownika agenta nie może mieć poświadczeń, takich jak hasła lub klucz dostępu. Jedynym typem poświadczeń, który obsługuje, jest odwołanie się do tożsamości agenta jako jego elementu nadrzędnego. Tak więc nawet jeśli konto użytkownika agenta działa jak użytkownik, jego poświadczenia są poufnymi poświadczeniami klienta.
Ograniczenia roli administracyjnej: konto użytkownika agenta nie może mieć przypisanych ról administratora uprzywilejowanego. To ograniczenie zapewnia ważną granicę zabezpieczeń, uniemożliwiającą potencjalne podniesienie uprawnień.
Model uprawnień: konto użytkownika agenta zwykle ma uprawnienia podobne do użytkowników-gości, z większą liczbą możliwości wyliczania użytkowników i grup. Nie można przypisać kontu użytkownika agenta ról administratora o uprzywilejowanych uprawnieniach. Niestandardowe przypisywanie ról i grupy z możliwością przypisywania ról nie są dostępne dla konta użytkownika agenta. Aby uzyskać więcej informacji, zobacz Microsoft Graph permissions reference
Aprowizowanie kont użytkowników agenta dla Microsoft 365
Aby w pełni skonfigurować konto użytkownika agenta z funkcjami pracownika cyfrowego, takimi jak skrzynka pocztowa, status obecności w Teams lub integracja z systemem kadrowym, utwórz agenta w aplikacji Microsoft Teams. Agent 365 i zestaw SDK Agent 365 stanowią podstawę, dzięki której konta użytkowników agentów mogą w pełni uczestniczyć w środowisku Microsoft 365.
Uwaga / Notatka
Utworzenie konta użytkownika agenta bezpośrednio za pośrednictwem interfejsu API Microsoft Graph ustanawia tożsamość w usłudze Microsoft Entra, ale nie udostępnia funkcji platformy Microsoft 365. Używaj podejścia interfejs Graph API tylko w scenariuszach, które nie wymagają udziału platformy Microsoft 365.
Aby uzyskać więcej informacji, zobacz dokumentację Zestaw SDK agentów usługi Microsoft 365.