Wzorce projektowe identyfikatora agenta Microsoft Entra

Identyfikator programu Microsoft Entra Agent wprowadza nowe konstrukcje tożsamości, a także nowe sposoby myślenia o istniejących wzorcach uwierzytelniania i autoryzacji. Aby lepiej zrozumieć, jak te konstrukcje pasują do siebie, warto zapoznać się z typowymi wzorcami wdrażania agenta sztucznej inteligencji i sposobem mapowania ich na identyfikator agenta entra firmy Microsoft.

W tym artykule opisano typowe wzorce wdrażania agenta sztucznej inteligencji oraz sposób mapowania ich na identyfikator agenta Entra Agent firmy Microsoft. Artykuł rozpoczyna się od przeglądu kluczowych pojęć dotyczących tożsamości, opisuje uprawnienia i granice zaufania, a następnie przechodzi przez typowe wzorce wdrażania.

Aby uzyskać szczegółowe wskazówki dotyczące podejmowania decyzji dotyczących liczby strategii i tożsamości agentów do utworzenia, zobacz Planowanie architektury tożsamości agenta.

Kluczowe pojęcia

Poniższe składniki są podstawą identyfikatora programu Microsoft Entra Agent. Jeśli jesteś nowym użytkownikiem, zacznij od kluczowych pojęć dotyczących identyfikatora programu Microsoft Entra Agent , zanim przejdziesz do tego artykułu.

Konstrukcje tożsamości

Następujące konstrukcje tożsamości są używane we wszystkich wzorcach opisanych w tym artykule:

• Strategia tożsamości agenta: szablon i podstawa uwierzytelniania dla co najmniej jednej tożsamości agenta. Zawiera poświadczenia i zasady, które mają zastosowanie do wszystkich utworzonych na jej podstawie tożsamości agentów.
• Główny element schematu tożsamości agenta: obiekt Entra firmy Microsoft utworzony podczas dodawania schematu do dzierżawcy. To właśnie uzyskuje tokeny, tworzy tożsamości agentów i pojawia się w dziennikach inspekcji w imieniu strategii.
• Tożsamość agenta: tożsamość środowiska uruchomieniowego dla określonego agenta sztucznej inteligencji z własnymi uprawnieniami do zasobów podrzędnych.
• Konto użytkownika agenta: opcjonalne konto 1:1 sparowane z tożsamością agenta jest wymagane tylko wtedy, gdy agent musi uzyskiwać dostęp do systemów wymagających obiektu użytkownika.

Modele uprawnień

Uprawnienia na poziomie szablonu i uprawnienia na poziomie tożsamości agenta służą różnym celom:

• Uprawnienia strategii reprezentują minimalne uprawnienia współużytkowane we wszystkich tożsamościach agentów utworzonych na podstawie strategii. Użyj uprawnień dziedziczych w strategii, jeśli chcesz, aby wszystkie tożsamości agentów rozpoczynały się od wspólnego punktu odniesienia.
• Uprawnienia tożsamości agenta reprezentują zróżnicowane uprawnienia dla określonego agenta. Użyj tych uprawnień, gdy różni agenci w tym samym systemie potrzebują innego dostępu do zasobów podrzędnych.

Aby uzyskać więcej informacji, zobacz Konfigurowanie uprawnień dziedzicznych dla szablonów i Autoryzacja w identyfikatorze Microsoft Entra Agent.

Granica zaufania

Granica zaufania odnosi się do wspólnej powierzchni ryzyka, w której zakłada się, że jeden kompromis wpływa na cały obwód. Agenci działający na oddzielnych platformach z oddzielnymi kontami usługowymi, tajnymi danymi i segmentami sieci nie dzielą granicy zaufania.

Granica zaufania to decyzja dotycząca modelowania zagrożeń aplikacji, a nie taka, którą definiuje identyfikator programu Microsoft Entra Agent.

Wzorce wdrażania

Poniższe wzorce są oparte na rzeczywistych wdrożeniach agentów. Każdy z nich opisuje architekturę agenta, jego strukturę tożsamości oraz istotne zagadnienia dotyczące uprawnień i ładu.

Pojedynczy agent o niskim kodzie

Pojedynczy agent, który pomaga w konkretnym zadaniu, często oparty na platformie o niskim kodzie lub bez kodu, takiej jak Microsoft Copilot Studio. Agent zawsze działa w imieniu zalogowanego użytkownika (interaktywnego) lub zawsze działa jako sam (autonomiczny).

Struktury: Jedna strategia → jednej tożsamości agenta

Chociaż szablon z jedną tożsamością agenta może wydawać się zbędny, szablon zapewnia agenta z spójnymi politykami dostępu warunkowego, monitorowaniem, zarządzaniem i audytem — tę samą infrastrukturę, której potrzebujesz w przypadku systemów z wieloma agentami, przy minimalnej konfiguracji.

Uprawnienia: Przyznaj uprawnienia bezpośrednio tożsamości agenta. Uprawnienia dziedziczone przez strategię nie są zwykle potrzebne w przypadku pojedynczych przypadków.

Konto użytkownika agenta: Nie jest wymagane, chyba że agent potrzebuje dostępu do programu Exchange, usługi Teams lub innego systemu, który wymaga obiektu użytkownika.

Pracownik domeny (sekwencyjny wieloagentowy)

Wielu agentów współpracuje ze sobą w ściśle powiązanym, sekwencyjnym przepływie pracy, aby obsłużyć wspólny cel domeny. Agenci zazwyczaj współdzielą bazę kodu, działają w tym samym środowisku uruchomieniowym (na przykład w tym samym obszarze nazw lub kontenerze kubernetes) i mają ten sam stan zabezpieczeń. Każdy agent ma różne obowiązki i inny dostęp do zasobów podrzędnych. Ten wzorzec mapuje na sekwencyjną orkiestrację w projektowaniu wielu agentów.

Struktury: Jedna strategia → wielu tożsamości agentów (po jednym na rolę agenta)

Użycie pojedynczej strategii jest tutaj odpowiednie, ponieważ wszyscy agenci współdzielą tę samą granicę zaufania. Każdy agent uzyskuje własną tożsamość agenta, dzięki czemu akcje mogą być przypisywane do określonego agenta w dziennikach inspekcji i logowania, a każdy z nich może przechowywać różne uprawnienia do zasobów podrzędnych.

Przykład: system zarządzania produktami detalicznymi ma trzech agentów — zapas sklepu, porównanie produktów i zapas dostawców. Wszystkie trzy elementy działają w tej samej przestrzeni nazw platformy Kubernetes i są tworzone przez ten sam zespół. Używają jednej strategii z trzema tożsamościami agentów, z których każdy ma uprawnienia ograniczone do własnych zasobów.

Uprawnienia: Ustaw dziedziczone uprawnienia współdzielonego szablonu bazowego w szablonie. Przypisz uprawnienia specyficzne dla roli bezpośrednio do każdej tożsamości agenta.

Konto użytkownika agenta: Zazwyczaj nie jest wymagane dla agentów roboczych w domenie.

Orkiestrator współbieżny z pracownikami domenowymi

Agent orkiestratora dynamicznie aktywuje różnych pracowników domenowych w oparciu o zadanie przychodzące. Pracownicy domeny mogą działać na różnych platformach, obsługiwać różne zespoły i przekraczać granice zaufania. Ten wzorzec mapuje na współbieżną orkiestrację w projekcie wielu agentów.

Struktury:

• Strategia Tożsamość agenta orkiestratora →
• Plan B → tożsamości agenta roboczego domeny (jedna na rolę, grupa międzygranicza zaufania)
• Schemat C → inna grupa robocza domeny, jeśli jest obsługiwana przez oddzielny zespół lub platformę

Pracownicy domeny przekraczają granice zaufania — oddzielne środowiska uruchomieniowe, tajne informacje lub zespoły — wymagają oddzielnych szablonów. Poświadczenia szablonu są ograniczone do jego domeny zaufania, więc naruszenie w jednej domenie nie ma wpływu na agentów partnerskich.

Efemeryczne tożsamości agentów: Wariant tego wzorca używa efemerycznych tożsamości agentów. Orkiestrator tworzy tymczasową tożsamość agenta w czasie wykonywania, aby ułatwić określoną interakcję (na przykład koordynowanie z podsystemem konserwacji), przyznaje mu uprawnienia dziedziczone z szablonu i usuwa tę tożsamość po zakończeniu sesji. Ogranicza to promień wybuchu do czasu trwania zadania.

Uprawnienia: Orkiestrator i każda grupa robocza domeny mają własne zestawy uprawnień, określone względem odpowiednich szablonów i tożsamości agentów.

Konto użytkownika agenta: Zwykle nie jest wymagane na poziomie koordynatora lub procesu roboczego domeny, chyba że określony proces roboczy domeny musi uzyskać dostęp do zasobu zależnego od obiektu użytkownika.

Agenci na użytkownika (małe n)

Dla każdego użytkownika lub jednostki organizacyjnej jest tworzona oddzielna tożsamość agenta. Na przykład agent analityka SOC może mieć jedno wystąpienie na środowisko chmury lub agent inspekcji może mieć jedno wystąpienie na dział. Liczba tożsamości agentów jest umiarkowana — dziesiątki do setek — a nie jedna na użytkownika katalogu.

Struktury: Jedna strategia → jedną tożsamość agenta na użytkownika, dział lub środowisko

Ten schemat jest odpowiedni, gdy każde wystąpienie agenta wymaga różnych uprawnień, różnych granic audytu lub niezależnego cyklu życia (na przykład agent dla działu może być wyłączony bez wpływu na inne).

Uprawnienia: Każda tożsamość agenta ma uprawnienia ograniczone do użytkownika lub jednostki organizacyjnej. Uprawnienia dziedziczone z szablonu ustawiają minimalną linię bazową, a każda tożsamość agenta otrzymuje dodatkowe uprawnienia według potrzeb.

Konto użytkownika agenta: Rozważ parowanie każdej tożsamości agenta z kontem użytkownika agenta, gdy każdy agent działa jako nazwany przedstawiciel swojego użytkownika lub działu — na przykład dedykowany agent sprzedaży, który otrzymuje wiadomość e-mail w imieniu terytorium.

Cyfrowy pracownik (w pełni autonomiczny agent)

W pełni autonomiczny agent działa jako wirtualny pracownik, wyposażony w zasoby zwykle zarezerwowane dla pracowników: skrzynkę pocztową programu Exchange, udział w usłudze OneDrive i widoczność w usłudze Teams. Jest to najwyższy poziom autonomii agenta.

Struktura: Jeden plan → jedna tożsamość agenta → jedno konto użytkownika agenta

Każdy cyfrowy pracownik wymaga własnego konta użytkownika agenta. Relacja 1:1 między tożsamością agenta a kontem użytkownika agenta jest stała — nie można współużytkować konta użytkownika agenta w wielu tożsamościach agenta.

Przykład: przedstawiciel handlowy sztucznej inteligencji z rzeczywistą skrzynką pocztową wymienioną na globalnej liście adresów, która odpowiada na wiadomość e-mail i ma przypisanego menedżera ludzkiego na wykresie organizacyjnym.

Uprawnienia: Przyznaj kontu użytkownika agenta określone uprawnienia programu Exchange, usługi Teams i usługi OneDrive, których potrzebuje. Nadaj tożsamości agenta uprawnienia na poziomie aplikacji dla systemów, które nie wymagają obiektu użytkownika. Aby uzyskać więcej informacji, zobacz Udzielanie agentowi dostępu do platformy Microsoft 365.

Konto użytkownika agenta: Wymagane. Utwórz jedno konto użytkownika dla każdej tożsamości agenta cyfrowego pracownika.

Wzorce, których należy unikać

Repliki rozszerzane nie wymagają oddzielnych tożsamości agentów

Uruchamianie wielu instancji tego samego kodu agenta (scale-out) nie wymaga oddzielnych tożsamości agenta. Rozszerzanie jest kwestią środowiska uruchomieniowego: schemat uzyskuje tokeny jako tożsamość agenta, a wiele instancji agenta może działać jednocześnie pod tą samą tożsamością. Utworzenie oddzielnej tożsamości agenta na replikę powoduje dodanie obiektów katalogu i obciążeń związanych z zarządzaniem bez żadnych korzyści związanych z inspekcją, kontrolą dostępu lub odpowiedzialnością.

Zarządzanie pamięcią i kontekstem nie wymaga oddzielnych tożsamości agentów

Pamięć agenta to zazwyczaj udostępniony magazyn danych (na przykład usługa Azure Cache for Redis lub Wyszukiwanie AI platformy Azure), w którym dane są filtrowane według identyfikatora sesji w czasie pobierania. Dostęp do tego magazynu danych jest kontrolowany przez uprawnienia tożsamości agenta, a nie przez oddzielne tożsamości na sesję. Oddzielne tożsamości agentów na potrzeby izolacji pamięci dodają złożoność bez korzyści dla bezpieczeństwa.

Nie używaj skalowanych tożsamości agenta dla obiektu w katalogu

Tworzenie jednej tożsamości agenta na każde spotkanie, na każdy dokument lub dla każdego obiektu efemerycznego na dużą skalę nie jest obecnie praktyczne w przypadku tożsamości na poziomie katalogów. W przypadku scenariuszy o wysokim przepływie użyj wspólnych tożsamości agentów i wykorzystaj identyfikatory sesji lub kontekstu, aby na warstwie aplikacji odróżnić interakcje.

Treści powiązane

• Strategie tożsamości agenta
• Tożsamości agenta
• Konta użytkowników agenta
• Planowanie architektury tożsamości agenta
• Konfigurowanie uprawnień dziedziczych dla szablonów