Model współodpowiedzialności agenta AI

Agenci AI rozszerzają generatywną AI poza wzorzec żądań/odpowiedzi, który opisuje model współdzielonej odpowiedzialności . W przeciwieństwie do dużego modelu językowego agent nie tylko zwraca treści, na podstawie których człowiek może podjąć działanie. Zamiast tego agent:

  • Działa autonomicznie. Wywołuje narzędzia, wywołuje API, zapisuje dane i uruchamia workflow bez zatwierdzenia każdego kroku przez człowieka.
  • Plany i pętle. Rozkłada cele, rozważa wyniki pośrednie i wielokrotnie się powtarza, zanim wróci.
  • Utrzymuje stan i pamięć. Krótkoterminowy kontekst oraz trwała pamięć wpływają na przyszłe zachowania i mogą przekraczać granice sesji lub użytkowników.
  • Ma tożsamość. Uwierzytelnia się w systemach podrzędnych przy użyciu zarządzanych tożsamości, tokenów typu on-behalf-of lub odrębnej tożsamości agenta oraz ma własne uprawnienia.
  • Komponuje z innymi agentami. W orkiestracji wieloagentowej wyjście jednego agenta staje się instrukcją drugiego agenta, wprowadzając nową granicę zaufania.

Każde z tych zachowań wiąże się z obowiązkami, które nie występują w modelu AI typu żądanie–odpowiedź.

Note

W tym artykule "odpowiedzialność" używa się w sensie zarządzania: kto ma za zadanie konfigurować, obsługiwać i monitorować każdą kontrolę. Są to wskazówki ilustracyjne i nie mają na celu przekazywania wniosków prawnych ani zmiany czy sprzeczności z warunkami jakiejkolwiek umowy między Tobą a Microsoft.

Czym agenty AI różnią się od obciążeń chmurowych i obciążeń AI

Poniższa tabela podsumowuje, jak model agenta AI różni się od standardowego modelu chmury oraz modelu generatywnej AI (LLM).

Dotyczą Standardowy model chmury Model AI (LLM) Model agenta SI
Główna interakcja API lub GUI Monit do odpowiedzi Cel: autonomiczne, wieloetapowe działanie
Skutki uboczne w rzeczywistości Kod aplikacji, jawny Człowiek działa na podstawie produkcji Agent działa bezpośrednio za pomocą narzędzi
State Warstwa aplikacji i danych Prompt bezpaństwowy Trwała pamięć agenta i kontekst
Identity Tożsamość użytkownika lub aplikacji Tożsamość użytkownika lub aplikacji Odrębna tożsamość agenta plus tokeny delegowane
Granica zaufania Użytkownik aplikacji Od użytkownika do modelu Z Użytkownika do agenta, do narzędzi i innych agentów
Najwyższe ryzyko Błędna konfiguracja, ekspozycja danych Wstrzyknięcie do promptu (treść) Wstrzyknięcie polecenia, które inicjuje działania; nadmierna sprawczość; problem zdezorientowanego zastępcy

Podział odpowiedzialności

Podobnie jak w przypadku modeli odpowiedzialności dzielonej w chmurze i AI , podział odpowiedzialności zmienia się w zależności od wybranego przez Ciebie modelu wdrożenia. Dla agentów istotne opcje to:

  • Agent SaaS. Gotowy agent, taki jak agenci Microsoft 365 Copilot, Microsoft Security Copilot lub opublikowani agenci Microsoft Copilot Studio. Microsoft obsługuje orkestrator, model, systemy bezpieczeństwa oraz większość złączy narzędzi. Masz własną konfigurację, zakres dostępu do danych, tożsamość i użytkowanie.
  • Agent usługi PaaS. Budujesz agenta na platformie zarządzanych agentów, takiej jak Microsoft Foundry Agent Service, Azure SRE Agent, niestandardowych agentach Microsoft Copilot Studio lub Microsoft Agent Framework, na środowisku zarządzanym przez Azure. Microsoft zapewnia kontrolę czasu działania, hostingu modeli oraz bezpieczeństwa platformy. Jesteś właścicielem instrukcji agenta, wyboru narzędzi i wtyczek, uprawnień narzędzi, logiki orkiestracji, projektu pamięci oraz tożsamości i autoryzacji agenta.
  • Agent usługi IaaS Cały stos agentów budujesz i hostujesz samodzielnie: niestandardowy orkiestrator na maszynach wirtualnych lub w kontenerach, framework zarządzany we własnym zakresie oraz ewentualnie modele hostowane we własnym zakresie. Posiadasz prawie wszystko oprócz infrastruktury fizycznej (i modelu bazowego, jeśli korzystasz z niego jako hostowanego API).

Odpowiedzialność przesuwa się w lewo, co oznacza, że przejmujesz większą odpowiedzialność, przechodząc od agentów SaaS do PaaS i IaaS.

Poniższy diagram ilustruje obszary odpowiedzialności między Tobą a Microsoft w zależności od rodzaju wdrożenia agenta.

Diagram warstw odpowiedzialności agentów AI w ramach wdrożeń agentów IaaS, PaaS i SaaS, z trzema nowymi warstwami (pamięć i stan agenta, narzędzia i działania oraz orkiestracja agentów) dodanymi na górze modelu współdzielonej odpowiedzialności AI.

Przegląd warstwy agentów AI

System agenticzny dodaje trzy nowe warstwy na i wokół istniejącej platformy AI, aplikacji i warstw użytkowania. Odpowiedzialność za bezpieczeństwo spoczywa na tym, kto wykonuje zadanie, ale dostawca może udostępnić ci kontrolę jako konfigurację.

Warstwa platformy AI (dziedziczona)

Warstwa platformy AI hostuje i chroni model, dane treningowe, wagi i API wnioskowania oraz zapewnia wbudowane systemy bezpieczeństwa wejściowe i wyjściowe. Odpowiedzialność na tej warstwie jest dziedziczona z modelu współdzielonej odpowiedzialności AI.

Warstwa orkiestracji agentów

Warstwa orkiestracji to "pętla mózgowa": planowanie, rozumowanie, wybór narzędzi, prompt i instrukcje systemowe agenta oraz koordynacja wieloagentowa. To właśnie na tej warstwie występują zagrożenia związane z nadmierną sprawczością i wstrzyknięciem promptu prowadzącym do działania.

Kwestie bezpieczeństwa:

  • Ogranicz instrukcje i zakres agenta (najmniejsza funkcjonalność).
  • Weryfikować i oczyszczać wszelkie niezaufane treści trafiające do pętli, w tym pobrane dokumenty, dane wyjściowe narzędzi oraz wiadomości od innych agentów. Traktuj to wszystko jako nieufne informacje, a nie jako zaufane instrukcje.
  • Wymuszaj ograniczenia planowania: limity kroków i iteracji, wykrywanie pętli, limity budżetu i kosztów oraz listy dozwolonych narzędzi, które można łączyć w łańcuchy.
  • W systemach wieloagentowych traktuj każdą wiadomość międzyagentową jako granicę zaufania i ponownie zastosuj zabezpieczenia wejściowe.

Warstwa narzędzi i operacji

Warstwa narzędzi i działań zawiera konektory, wtyczki, funkcje, serwery Model Context Protocol (MCP) oraz API, które agent może wywołać, aby odczytać i zmienić stan w rzeczywistym świecie. Ta warstwa stanowi największą różnicę w porównaniu do modelu LLM.

Kwestie bezpieczeństwa:

  • Najmniejsze uprawnienia na narzędzie. Każde narzędzie lub złącze powinno zawierać tylko wymagane uprawnienia. Nie nadaj agentowi szerokiej tożsamości.
  • Autoryzacja każdej akcji, nie tylko na początku sesji. Sprawdź ponownie, czy takie działanie na tym zasobie jest dozwolone. Ta kontrola ogranicza ryzyko ataku typu confused deputy oraz nadmiernie szerokiego delegowania uprawnień.
  • Bramy człowieka w pętli. Wymagaj ich do działań o dużym wpływie, nieodwracalnych lub wrażliwych, takich jak zapisy, usuwania, płatności, zmiany produkcyjne czy wysyłanie zewnętrzne.
  • Audyt działania. Rejestruj każde wywołanie narzędzia wraz z wejściami, wyjściami, używaną tożsamością oraz uzasadnieniem decyzyjnym.
  • Sandboxing i kontrola ewakuacji. Zastosuj je do narzędzi do wykonywania kodu i przeglądania.

Pamięć agenta i warstwa stanu

Warstwa pamięci agenta obejmuje krótkoterminowe konteksty rozmowy oraz trwałą pamięć, magazyny wektorowe i tzw. scratchpady, które wpływają na przyszłe zachowania.

Kwestie bezpieczeństwa:

  • Zakres i izolacja pamięci dla użytkownika i tenanta. Zapobiegaj wyciekom pamięci między użytkownikami lub sesjami.
  • Chroń przed skażeniem pamięci. Wstrzyknięta zawartość może pozostać i zostać później ponownie aktywowana.
  • Klasyfikuj, zachowuj i usuwaj przechowywaną pamięć. Stosuj klasyfikację danych, przechowywanie i prawo do usunięcia.
  • Szyfruj magazyny pamięci i egzekwuj kontrolę dostępu. Traktuj pamięć jako dane wrażliwe.

Warstwa aplikacji AI (dziedziczona)

Warstwa aplikacji AI to aplikacja lub interfejs, z którego korzysta użytkownik, wraz z uziemieniem, wtyczkami i systemem bezpieczeństwa aplikacji.

Warstwa użytkowania AI (dziedziczona, rozszerzona)

Warstwa użytkowania AI opisuje, jak użytkownicy i aplikacje korzystają z agenta. W przypadku agentów odpowiedzialność za działania autonomiczne staje się kluczowa: polityki akceptowalnego użytkowania, edukacja użytkowników na temat ryzyk specyficznych dla agentów oraz jasna odpowiedzialność za działania podejmowane przez agenta w imieniu użytkownika.

Macierz odpowiedzialności

Poniższa macierz podsumowuje odpowiedzialność w różnych modelach wdrożeń. C = Klient, M = Microsoft, S = Współdzielone. Macierz jest ogólnym przewodnikiem; Konkretne obowiązki dla danej usługi mogą się różnić w zależności od warunków i konfiguracji usługi.

Odziedziczone obowiązki chmurowe i AI

Obszar odpowiedzialności agent usługi IaaS Agent PaaS Agent SaaS
Dane klienta (w tym dane referencyjne i zawartość pamięci) C C C
Tożsamości i użytkownicy C C C
Zarządzanie dostępem (RBAC, MFA, Dostęp warunkowy) C C C
Urządzenia klienckie i punkty końcowe C C S
Hosting modelu bazowego i wagi C/M1 M M
Bezpieczeństwo zawartości wejścia/wyjścia modelu C/M1 S M
Infrastruktura fizyczna (hosty, sieć, centrum danych) M M M

Specyficzne dla agenta obowiązki

Obszar odpowiedzialności agent usługi IaaS Agent PaaS Agent SaaS
Instrukcje agenta, polecenie systemowe i zakres C C S
Wybór narzędzi, wtyczek i złączy C C S
Uprawnienia dla każdego narzędzia (najmniejsze uprawnienia) C C S
Tożsamość agenta i zarządzanie tokenami delegowanymi C S S
Sprawdzanie autoryzacji dla każdej akcji C S S
Zatwierdzanie działań o istotnym wpływie z udziałem człowieka w pętli C C C
Bariery orkiestracji (pętle, kroki i limity kosztowe) C S M
Wieloagentowe sterowanie granicami zaufania C S S
Projekt pamięci, izolacja i obrona przed zatruciem C S M
Sandboxing narzędzi i mechanizmów oraz kontrola wyjścia C S M
Rejestrowanie i monitorowanie audytu działań C S S
Platforma środowiska uruchomieniowego i orkiestracji agentów C M M
Polityka akceptowalnego użytkowania i odpowiedzialność za działania C C C

1 Klient, jeśli samodzielnie hostujesz model na IaaS; Microsoft, jeśli korzystasz z hostowanego API modelu od swojego agenta hostowanego w IaaS.

Obowiązki, które zawsze zachowujesz

Bez względu na model wdrożenia, zawsze jesteś odpowiedzialny za:

  • Dane, w tym wszystko, co zapisane w pamięci agenta i przekazane narzędziom.
  • Tożsamość i najmniejsze przywileje: tożsamość agenta oraz zakres każdego poświadczenia lub tokena, z którego może korzystać.
  • Autoryzacja działań: co agent może robić, zwłaszcza operacje nieodwracalne lub wrażliwe.
  • Nadzór ludzki: które działania wymagają aprobaty i kto ponosi odpowiedzialność za zachowanie agenta.
  • Akceptowalne użytkowanie i zarządzanie: polityki, edukacja użytkowników oraz zgodność z autonomicznym zachowaniem.

Najważniejsze ryzyka specyficzne dla agentów, przed którymi należy zabezpieczyć się na etapie projektowania

Te ryzyka odpowiadają klasyfikacjom OWASP Top 10 dla aplikacji LLM, OWASP Top 10 dla Agentic AI, MITRE ATLAS oraz klasyfikacji ważności podatności Centrum zabezpieczeń firmy Microsoft (MSRC) dla systemów AI. Podkreślają wymiar działania , który jest unikalny dla agentów.

Ryzyko Mitigation
Szybkie wprowadzenie do działania. Nieufne treści, takie jak strona internetowa, dokument, e-mail czy inny agent, przewlekają agenta do złośliwego korzystania z narzędzi. Traktuj wszystkie dane wyjściowe narzędzi, wyszukiwania i agentów jako niezaufane. Odizoluj instrukcje od danych. Ogranicz działania o dużym znaczeniu.
Nadmierna sprawczość. Agent ma więcej narzędzi, uprawnień lub autonomii, niż zadanie wymaga od niego. Stosuj dla każdego narzędzia minimalny zakres funkcji oraz najmniejsze uprawnienia, a także ograniczaj zakres instrukcji.
Zagubiony zastępca lub zbyt szerokie delegowanie. Agent wykorzystuje swoją uprzywilejowaną tożsamość, aby zrobić coś, czego użytkownik żądający nie może zrobić. Używaj tokenów „on-behalf-of” i autoryzacji dla każdej akcji. Unikaj stałej szerokiej tożsamości.
Zatrucie pamięcią. Wstrzyknięta treść utrzymuje się i jest ponownie wyzwalana później lub między sesjami. Izoluj i weryfikuj pamięć, śledź proweniencję i wymuszaj retencję.
Nieograniczone pętle, koszty i wyczerpanie zasobów. Planowanie ucieczki. Egzekwuj limity kroków, iteracji i budżetu oraz wykrywaj pętle.
Awarie zaufania wieloagentowego. Przejęty agent lub agent mający halucynacje skaża współpracujące z nim agenty. Ponownie zastosuj zabezpieczenia wejściowe na każdej granicy międzyagentowej. Sprawdzaj, nie ufaj.
Nieautoryzowani lub podszywający się agenci. Nieautoryzowany agent działa w środowisku lub jego tożsamość jest podszywana. Wymuszaj silną tożsamość agenta, atestację oraz wykrywanie i monitorowanie.

Konfiguruj przed dostosowaniem

Ta sama zasada, którą Microsoft zaleca dla AI, dotyczy agentów, a jest silniejsza dla agentów, ponieważ autonomia zwiększa koszty błędów.

  1. Zacznij od agentów SaaS (Microsoft 365 Copilot, Microsoft Security Copilot lub publikowani agenci Microsoft Copilot Studio). Microsoft odpowiada za orkiestrację, bezpieczeństwo i zabezpieczenia większości narzędzi. Konfigurujesz zakres i tożsamość danych.
  2. Przechodź do agentów PaaS (Microsoft Foundry Agent Service, Azure SRE Agent, niestandardowych agentów Microsoft Copilot Studio lub Microsoft Agent Framework w zarządzanym czasie uruchomieniowym) tylko wtedy, gdy gotowe rozwiązania nie pasują. Przejmujesz się logiką agenta, narzędziami, uprawnieniami, pamięcią i tożsamością.
  3. Buduj agentów IaaS wyłącznie z głęboką wiedzą w zakresie bezpieczeństwa AI, tożsamości i ryzyka systemów autonomicznych. Kontrolujesz niemal cały stos technologiczny.

Zasada: Im więcej autonomii i szerszy zestaw narzędzi oraz uprawnień, które przyznajesz agentowi, tym większa część matrycy odpowiedzialności przechodzi na ciebie, niezależnie od modelu wdrożenia. Autonomia nigdy nie zmniejsza odpowiedzialności.

Następne kroki

  • Last updated on