Pojęcia dotyczące tożsamości agenta w usłudze Microsoft Foundry

Tożsamość agenta to wyspecjalizowany typ tożsamości w Microsoft Entra ID, zaprojektowany specjalnie dla agentów sztucznej inteligencji. Zapewnia on ustandaryzowaną strukturę do zarządzania, uwierzytelniania i autoryzowania agentów sztucznej inteligencji w usługi firmy Microsoft. Ta struktura umożliwia agentom bezpieczny dostęp do zasobów, interakcję z użytkownikami i komunikację z innymi systemami.

Microsoft Foundry automatycznie zapewnia tożsamości agentów i zarządza nimi na każdym etapie cyklu życia agenta. Ta integracja upraszcza zarządzanie uprawnieniami przy zachowaniu zabezpieczeń i inspekcji w miarę przechodzenia agentów z programowania do środowiska produkcyjnego.

W tym artykule wyjaśniono, jak tożsamości agentów odnoszą się do obiektów Microsoft Entra ID, jak Foundry ich używa, gdy agent wywołuje narzędzia, oraz jak zastosować dostęp z najmniejszymi uprawnieniami za pomocą kontroli dostępu opartej na rolach w Azure (RBAC, role-based access control). Ten sam model tożsamości dotyczy agentów monitów opartych na tekście i agentów monitów głosowych. W scenariuszach obsługujących komunikację głosową platforma Foundry zarządza środowiskiem wykonawczym głosu w czasie rzeczywistym i połączeniem WebSocket, a tożsamość agenta nadal uwierzytelnia dostęp do narzędzi i zasobów podrzędnych.

Wymagania wstępne

• Znajomość uwierzytelniania Microsoft Entra ID i OAuth
• Znajomość kontroli dostępu opartej na rolach (RBAC) w Azure
• Podstawowa wiedza na temat agentów sztucznej inteligencji i ich wymagań dotyczących środowiska uruchomieniowego

Aby zapoznać się z rolami i zakresami RBAC specyficznymi dla narzędzia Foundry, proszę zapoznać się z kontrolą dostępu opartą na rolach Azure w Foundry.

Tożsamości i strategie agenta

Usługa Foundry używa tożsamości agenta Microsoft Entra ID do obsługi dwóch powiązanych potrzeb:

• Zarządzanie i ład: zapewnij administratorom spójny sposób tworzenia spisu agentów, stosowania zasad i działań inspekcji.
• Uwierzytelnianie narzędzia: Pozwól agentowi uwierzytelnić się w systemach podrzędnych (na przykład Azure Storage) bez osadzania tajnych danych w monitach, kodzie lub ciągach połączenia.

Strategia tożsamości agenta

Schemat tożsamości agenta modeluje agenta i jest obiektem nadrzędnym dla skojarzonych tożsamości agenta. Udostępnia szablon nadrzędny dla tych tożsamości.

Plan może również służyć jako punkt logowania agenta. Korzystając ze schematu autoryzacji punktu końcowego w wersji zapoznawczej AgentBlueprint, klienci uzyskują tokeny dla odbiorcy strategii agenta w celu wywołania agenta. Ten dostęp przychodzący jest oddzielony od dostępu tożsamości agenta do zasobów docelowych. Zobacz Dostęp do punktu końcowego szablonu agenta i Konfigurowanie dostępu do szablonu agenta.

Usługa Foundry aprowizuje poświadczenie tożsamości federacyjnej w planie, który ufa dostawcy zasobów „Azure Machine Learning”, aplikacji własnej firmy Microsoft zarządzanej przez Microsoft o identyfikatorze aplikacji 0736f41a-0425-4b46-bdb5-1563eff02385. To nie jest „Azure Machine Learning Services”, czyli tożsamość używana do logowania się do portalu Foundry. To poświadczenie ufa tej aplikacji tylko wtedy, gdy działa w Twojej dzierżawie.

Usługa agenta używa poświadczeń do tworzenia tożsamości agenta i żąda tokenów w czasie wykonywania za pośrednictwem usługi tokenu hostowanego agenta lub dla skonfigurowanego narzędzia. Nie jest wymagany klucz tajny klienta ani certyfikat. Projekty programu Foundry, kod agenta i tożsamość zarządzana projektu nigdy nie przechowują poświadczenia.

Na przykład podmiot /eid1/c/pub/t/ERERESIiMzNERFVVVVVVVQ/a/GvQ2ByUERku9tRVj7_AjhQ/AzureAI/FMI zawiera identyfikator dzierżawy zakodowany w formacie base64url po /t/ i identyfikator aplikacji po /a/.

Aby uzyskać więcej informacji, zobacz Schematy tożsamości agenta i poświadczenia schematu.

Tożsamość agenta

Tożsamość agenta to specjalna nazwa główna usługi w Microsoft Entra ID utworzona w ramach schematu agenta. Reprezentuje wystąpienie agenta, gdy uzyskuje dostęp do zasobów zależnych. Nadrzędny plan jest upoważniony do podszywania się pod tę tożsamość. Informacje o obiekcie bazowym zawiera sekcja Tożsamości agenta.

Korzyści z zabezpieczeń

Tożsamości agentów pomagają sprostać konkretnym wyzwaniom związanym z zabezpieczeniami, które stanowią agenci sztucznej inteligencji:

• Rozróżnianie operacji wykonywanych przez agentów sztucznej inteligencji od operacji wykonywanych przez pracowników, klientów lub tożsamości zasobów obliczeniowych.
• Umożliwienie agentom sztucznej inteligencji uzyskiwania odpowiedniego poziomu dostępu w różnych systemach.
• Uniemożliwiaj agentom sztucznej inteligencji uzyskanie dostępu do krytycznych ról zabezpieczeń i systemów.
• Skalowanie zarządzania tożsamościami do dużej liczby agentów sztucznej inteligencji, które można szybko utworzyć i zniszczyć.

Jak usługa Foundry aprowizuje tożsamości

Foundry tworzy tożsamości agentów Microsoft Entra i zarządza nimi w całym cyklu życia agenta. W bieżącym modelu obiektów agenta utworzenie agenta aprowizuje unikatowy schemat agenta i tożsamość dla jego wystąpienia domyślnego.

Nowo utworzona tożsamość agenta rozpoczyna się bez uprawnień do zasobów. Foundry nie przypisuje automatycznie do niego ról RBAC ani innych uprawnień podrzędnych. Ty lub administrator przyznajecie dostęp, którego potrzebuje, za pośrednictwem modelu autoryzacji usługi docelowej. Zobacz Przypisz uprawnienia tożsamości agenta.

współdzielona tożsamość projektu pozostaje dostępna dla starszych agentów. Informacje o różnicach między starszymi agentami, aplikacjami agenta i bieżącym modelem znajdziesz tutaj: Migrowanie z aplikacji agenta do nowego punktu końcowego agenta i środowiska publikowania.

Jak agenci używają swojej tożsamości w czasie wykonywania

Gdy narzędzie używa uwierzytelniania tożsamością agenta, agent używa swojej tożsamości do uzyskiwania dostępu do zasobu docelowego.

Uwierzytelnianie narzędzi zarządzanych przez usługę

Gdy agent wywołuje narzędzie, Foundry żąda tokenu dostępu dla usługi docelowej i używa tego tokenu do uwierzytelniania wywołania narzędzia.

Ta metoda uwierzytelniania dotyczy zarówno agentów monitów opartych na tekście, jak i głosowych. Agenci głosowi używają tej samej tożsamości agenta do uwierzytelniania wywołań narzędzi, podczas gdy Foundry zarządza sesją głosową w czasie rzeczywistym i połączeniem Voice Live.

Wymiana tokenów środowiska uruchomieniowego

W przypadku wywołań narzędzia zarządzanego przez usługę, które używają uwierzytelniania tożsamości agenta, wieloetapowa wymiana tokenów OAuth 2.0 odbywa się automatycznie między Agent Service, Microsoft Entra ID i zasobem podrzędnym. Usługa agenta obsługuje wymianę.

Wymiana przechodzi przez cztery etapy:

1. Uwierzytelnianie projektu: Usługa agenta przedstawia poświadczenia OAuth projektu do Microsoft Entra ID. Ten krok potwierdza, że Agent Service jest autoryzowana do działania w imieniu planu i tożsamości agentów planu.

2. Wystawienie tokenu tożsamości dla agenta: Microsoft Entra ID weryfikuje poświadczenia blueprintu i wystawia token dla określonej tożsamości agenta. Ten token różni się od tokenów użytkownika lub tożsamości zarządzanej — identyfikuje agenta jako niezależnego aktora w katalogu.

3. Zakresowe żądanie tokenu: Usługa agenta przedstawia token tożsamości agenta z powrotem do Microsoft Entra ID i żąda nowego tokenu dostępu o zakresie audience usługi podrzędnej. Odbiorca jest identyfikatorem zasobu OAuth dla docelowej usługi (na przykład https://storage.azure.com dla Azure Storage).

4. Wywołanie uwierzytelnionego narzędzia: usługa Agent przekazuje token dostępu o zakresie do serwera MCP lub punktu końcowego A2A. Zasób końcowy weryfikuje token i sprawdza przypisania ról RBAC dla tożsamości agenta przed udzieleniem lub odmową dostępu.

Odbiorca identyfikuje zasób akceptujący token, który niekoniecznie jest adresem URL punktu końcowego narzędzia. Samo uwierzytelnienie do tego zasobu nie zapewnia dostępu. Aby uzyskać informacje o ustawieniach połączenia i konfiguracji odbiorców, zobacz Uwierzytelnianie serwera MCP i uwierzytelnianie A2A.

Pozyskiwanie tokenu w kodzie hostowanego agenta

W przypadku hostowanych agentów usługa tokenu umożliwia kodowi uzyskiwanie tokenów dla tożsamości bieżącego wystąpienia agenta domyślnie. Tożsamość zarządzana projektu nie jest dostępna dla kodu uruchamianego przez hostowanego agenta. Aby uzyskać informacje na temat wyboru tożsamości, zachowania usługi Azure Identity i kontraktu żądania tokenu, zobacz Dokumentacja usługi tokenu hostowanego agenta.

Izolacja tożsamości hostowanego agenta

Każda sesja hostowanego agenta jest uruchamiana we własnej piaskownicy izolowanej przez maszynę wirtualną, która nie zawiera poświadczeń blueprintu. Kod agenta uzyskuje tokeny tylko za pośrednictwem usługi tokenu hostowanego agenta lub serwera narzędzi. Obie usługi działają poza piaskownicą i identyfikują sesję wywołującą; platforma wystawia tokeny tylko dla skojarzonego agenta.

Uprawnienia i granice uprawnień dostępu

Uwierzytelnianie identyfikuje agenta wobec usługi zależnej. Model autoryzacji usługi określa, co może zrobić ta tożsamość.

Dostęp aplikacji i dostęp delegowany

Model dostępu określa, czyj autorytet decyduje o tym, jak wywoływane jest narzędzie:

• Dostęp tylko do aplikacji: agent działa z własnym uprawnieniem, bez zalogowanego użytkownika. Dostęp do niego zależy od ról, uprawnień aplikacji lub innych zasad autoryzacji przyznanych jego tożsamości.
• Dostęp delegowany: agent działa w imieniu zalogowanego użytkownika. Agent potrzebuje autoryzacji dla żądanych uprawnień delegowanych, a użytkownik musi mieć dostęp do zasobu.

Aby uzyskać informacje na temat modelu działania w imieniu użytkownika i wymagań dotyczących zgody, zobacz Delegowanie użytkowników dla narzędzi i Zgoda Microsoft Entra na dostęp delegowany.

Przypisywanie uprawnień do tożsamości agenta

usługa podrzędna określa, jak autoryzuje dostęp:

Usługa może wymagać więcej niż jednej warstwy autoryzacji. Gdy narzędzie używa uwierzytelniania tożsamości agenta, przyznaj dostęp do tożsamości agenta. Niektóre połączenia narzędzi mogą zamiast tego używać uwierzytelniania za pomocą tożsamości zarządzanej projektu, a w takim przypadku należy przyznać dostęp do tożsamości zarządzanej projektu.

Zastosuj zasadę najmniejszych uprawnień do tożsamości używanej dla każdego wywołania narzędzia. W przypadku kontroli dostępu opartej na rolach platformy Azure (Azure RBAC) preferuj zakres zasobu lub grupy zasobów zamiast dostępu obejmującego całą subskrypcję, jeśli spełnia potrzeby agenta.

Na przykład agent, który uzyskuje dostęp do obiektów blob usługi Azure Storage za pośrednictwem uwierzytelniania wyłącznie aplikacją, wymaga odpowiedniej roli RBAC platformy Azure w zasobie magazynu. Agent, który wykonuje zapytania w Azure Cosmos DB, może zamiast tego wymagać roli płaszczyzny danych specyficznej dla usługi. Te mechanizmy autoryzacji są oddzielne, mimo że oba autoryzują tożsamość agenta.

W przypadku procedur przypisywania kontroli dostępu opartej na rolach platformy Azure użyj identyfikatora obiektu tożsamości agenta używanego do wywołania narzędzia jako podmiotu przypisania. Zobacz Przypisywanie ról Azure przy użyciu Azure CLI. Aby uzyskać informacje na temat autoryzacji płaszczyzny danych usługi Cosmos DB, zobacz Konfigurowanie kontroli dostępu opartej na rolach dla Azure Cosmos DB.

Informacje o uprawnieniach związanych z wdrażaniem agenta hostowanego, w tym Azure Container Registry i usługi Application Insights, znajdziesz w dokumencie Dokumentacja uprawnień hostowanego agenta.

Obsługiwane narzędzia

Narzędzia mogą używać tożsamości agenta do uzyskiwania dostępu wyłącznie aplikacyjnego lub jako aktora w wywołaniu delegowanym. Obsługa jednego typu dostępu nie oznacza obsługi drugiego. W poniższej tabeli przedstawiono podsumowanie obsługiwanych integracji i linki do ich wskazówek dotyczących uwierzytelniania.

Tożsamość agenta działająca w imieniu użytkownika jest w wersji zapoznawczej i wymaga dostępu do punktu końcowego schematu agenta. Aby uzyskać informacje o wymaganiach dotyczących punktów końcowych, obsługiwanych typach uwierzytelniania, delegowanych zakresach i zgodzie, zobacz Konfigurowanie delegowania użytkowników dla narzędzi.

Inne narzędzia i integracje mogą używać różnych tożsamości lub metod uwierzytelniania. Potwierdź obsługę w dokumentacji narzędzia. Uwierzytelnianie tożsamości zarządzanej i oddzielne logowanie się OAuth same w sobie nie ustanawiają uwierzytelnienia tożsamości agenta.

Uwierzytelnianie tożsamości agenta nie zmienia zasad obsługi ani przechowywania danych zewnętrznego dostawcy narzędzi. Wywołania narzędzi innych niż Microsoft mogą wysyłać dane poza usługi firmy Microsoft. Przejrzyj i odnotuj ten dostęp zgodnie z zasadami organizacji.

Zarządzanie tożsamościami i ład

W bieżącym modelu obiektów agenta każdy agent ma własny plan agenta i domyślną tożsamość instancji od momentu utworzenia.

Tożsamości agenta Foundry są wyświetlane w spisie obejmującym całą dzierżawę w centrum administracyjne Microsoft Entra, obok tożsamości z Microsoft Copilot Studio i innych usług. Ten inwentarz umożliwia administratorom zarządzanie agentami między usługami, a nie tylko w projekcie Foundry.

Tożsamości poszczególnych agentów umożliwiają określanie zakresu uprawnień i audytowanie aktywności poszczególnych agentów. Agenci starszego typu, którzy współdzielą tożsamość projektu, nie mają tej separacji na poziomie tożsamości; zobacz wskazówki dotyczące migracji.

W tym środowisku można włączyć wbudowane mechanizmy kontroli zabezpieczeń, w tym:

• Dostęp warunkowy: stosowanie zasad dostępu do tożsamości agentów.
• Ochrona tożsamości: monitorowanie i ochrona tożsamości agentów przed zagrożeniami.
• Dostęp do sieci: kontrolowanie dostępu opartego na sieci dla agentów.
• Zarządzanie: kierowanie wygasaniem, właścicielami i sponsorami agentów.

Aby uzyskać więcej informacji na temat funkcji Identyfikator agenta Microsoft Entra, zobacz dokumentację Microsoft Entra.

Udostępnione tożsamości projektów i aplikacje agentów

Usługa Foundry nadal aprowizuje udostępniony plan agenta i tożsamość agenta na poziomie projektu. Starsze agenty bez unikatowej tożsamości używają tej tożsamości udostępnionej. Nowo utworzeni agenci otrzymują zamiast tego własny schemat i domyślną tożsamość instancji.

Migracja ze starszej współdzielonej tożsamości projektu lub aplikacji agenta do bieżącego modelu obiektu agenta zmienia tożsamość agenta. Przypisz wymagane uprawnienia zależne do nowego identyfikatora; istniejące przypisania ról nie są przenoszone. Zobacz Migracja z aplikacji agenta do nowego punktu końcowego agenta i środowiska publikowania.

W przypadku starszych tożsamości usunięcie projektu Foundry powoduje usunięcie udostępnionego szablonu agenta i jego tożsamości. Usunięcie starszej aplikacji agenta powoduje usunięcie odrębnej tożsamości tej aplikacji.

W przypadku starszych wdrożeń Azure Developer CLI (azd) automatycznie przypisuje rolę Foundry User do tożsamości udostępnionego agenta projektu w celu zapewnienia zgodności. Domyślny scenariusz hostowanego agenta nie wymaga tego przypisania. Starsze aplikacje agentów mają odrębne tożsamości, które wymagają oddzielnego ręcznego przypisywania ról.

Przypisanie roli Foundry tożsamości udostępnionej nie przyznaje uprawnień do zasobów Azure Container Registry, Application Insights ani zasobów niestandardowych. Informacje o uprawnieniach specyficznych dla zasobów wymaganych przez hostowanych agentów znajdziesz w Hosted agent permissions reference.

Monitorowanie i audyt aktywności tożsamości agenta

Użyj dzienników Microsoft Entra, aby przejrzeć aktywność tożsamości i śledzenie usługi Foundry w celu sprawdzenia wywołań narzędzi:

• Microsoft Entra dzienniki logowania: filtrowanie logowań agenta według typu agenta: plan tożsamości agenta, tożsamość agenta lub konto użytkownika agenta. Te dzienniki pokazują, która tożsamość agenta uzyskała token, dla którego zasobu, w tym w imieniu którego użytkownika w przypadku dostępu delegowanego. Zobacz Dzienniki logowania agenta.
• Microsoft Entra dzienniki inspekcji/audytu: Przejrzyj zdarzenia tworzenia i usuwania tożsamości schematu i agenta. Służy agentType do identyfikowania typu obiektu agenta i blueprintId do korelowania tożsamości agenta z jego planem. Zobacz Dzienniki inspekcji agenta.
• Śledzenie w Foundry: po włączeniu śledzenia sprawdź wywołania narzędzi dla poszczególnych agentów w zasobie usługi Application Insights połączonym z projektem Foundry. Zobacz Omówienie śledzenia agentów.

Powiązana zawartość

• Dokumentacja referencyjna usługi tokenu hostowanego agenta
• Aplikacje agentów Legacy w usłudze Microsoft Foundry
• Migrowanie z aplikacji agenta do nowego punktu końcowego agenta i środowiska publikowania
• Azure kontrola dostępu oparta na rolach w narzędziu Foundry
• Uwierzytelnianie serwera MCP
• Uwierzytelnianie Agent2Agent (A2A)
• dokumentacja Identyfikator agenta Microsoft Entra