Bezpieczeństwo agentów AI zaczyna się od tożsamości, ale przedsiębiorstwa potrzebują czegoś więcej niż poświadczeń

Google News zwróciło uwagę 2 września na ostrzeżenie dotyczące agentów AI, lecz problem wykracza daleko poza kolejną listę kontrolną bezpieczeństwa. Artykuł twierdzi, że zanim agenci rozpowszechnią się szerzej, przedsiębiorstwa muszą odpowiedzieć na trzy pytania: Gdzie się znajdują, z czym mogą się łączyć i co mogą robić?

Takie ujęcie pojawiło się w gościnnym artykule GuidePoint Security autorstwa Ariela Zommera, specjalisty ds. marketingu produktów bezpieczeństwa w Okta. Jego główna teza jest prosta. Agent staje się problemem tożsamościowym, gdy może się uwierzytelniać, uzyskiwać dostęp do systemów firmowych lub działać bez stałego nadzoru człowieka.

Moment jest istotny. NIST opublikował odrębne ostrzeżenie dotyczące tożsamości 27 sierpnia, mniej niż tydzień przed ukazaniem się artykułu GuidePoint. Microsoft, Okta i inni dostawcy tożsamości również przekształcają tożsamości agentów w formalne obiekty produktowe.

Ta zbieżność zmienia debatę w przedsiębiorstwach. Kluczowe pytanie nie brzmi już, czy model potrafi wygenerować trafną odpowiedź. Chodzi o to, czy każde wynikające z niej działanie ma widocznego wykonawcę, ograniczone uprawnienia, odpowiedzialnego właściciela i połączenie, które można unieważnić.

Argument brzmi znajomo, ponieważ zarządzanie tożsamością już reguluje dostęp pracowników, aplikacji i tradycyjnych obciążeń. Agenci komplikują ten model, ponieważ ich działania są probabilistyczne, ich połączenia się zmieniają, a jedno żądanie może uruchomić wiele operacji następujących po sobie.

Tożsamość jest więc konieczna, ale niewystarczająca. Poświadczenie może identyfikować agenta, nie dowodząc, że jego bieżące działanie jest bezpieczne. Rzeczywista rywalizacja toczy się między odpowiedzialną autonomią a wygodnym dostępem, którego organizacje nie potrafią w pełni prześledzić.

Co faktycznie pokazało Google News

Ta informacja nie dotyczy ujawnienia nowej podatności. To skoordynowane ostrzeżenie, że wdrażanie agentów wyprzedza mechanizmy kontroli tożsamości w przedsiębiorstwach.

Oryginalny argument dotyczący tożsamości został opublikowany przez GuidePoint Security 2 września 2026 r. Napisał go pracownik Okta, a tekst przedstawiono jako perspektywę partnera.

To rozróżnienie ma znaczenie. Czytelnicy powinni traktować ten artykuł jako analizę wspieraną przez dostawcę, a nie niezależny dowód, że jedna platforma komercyjna rozwiązuje każdy problem bezpieczeństwa agentów. Jego trzy pytania pozostają użyteczne, ponieważ opisują mierzalne luki w kontroli.

Pierwsze pytanie dotyczy tego, gdzie istnieją agenci organizacji. Inwentaryzacja musi obejmować agentów tworzonych wewnętrznie, funkcje osadzone w produktach SaaS, agentów hostowanych w chmurze, narzędzia autoryzowane przez pracowników oraz systemy eksperymentalne.

Tradycyjne inwentaryzacje zasobów często pomijają te kategorie. Deweloper może stworzyć agenta na zatwierdzonym koncie chmurowym, nie rejestrując go jako odrębnej aplikacji biznesowej. Pracownik może także autoryzować zewnętrzne narzędzie przez OAuth.

OAuth to standard autoryzacji, który pozwala jednej aplikacji uzyskać ograniczony dostęp do innej usługi. Jego wygoda może ukrywać trwałe relacje zaufania przed zespołami, które nigdy nie zatwierdziły podstawowego agenta.

Wykrywanie wymaga zatem czegoś więcej niż skanowania repozytoriów kodu. Zespoły bezpieczeństwa potrzebują także inwentaryzacji chmury, rejestracji aplikacji, przyznań OAuth, kont usługowych, sygnałów z przeglądarek, zapisów bram API i połączeń Model Context Protocol.

Model Context Protocol, czyli MCP, umożliwia aplikacjom AI łączenie się z narzędziami i danymi za pośrednictwem wspólnego interfejsu. Może upraszczać integrację, jednocześnie rozszerzając zbiór osiągalnych systemów.

Drugie pytanie dotyczy tego, z czym każdy wykryty agent może się połączyć. Ta mapa powinna obejmować aplikacje biznesowe, wewnętrzne API, bazy danych, systemy współpracy, sekrety, konta usługowe i innych agentów.

Połączenie nie ujawnia pełnego ryzyka. Zespoły bezpieczeństwa potrzebują również informacji o metodzie autoryzacji, zakresie uprawnień, czasie życia poświadczeń, właścicielu biznesowym, historii zatwierdzeń i ścieżce unieważnienia dostępu.

Trzecie pytanie dotyczy tego, co agent może zrobić po połączeniu. Dostęp do odczytu, modyfikacja rekordów, wykonywanie kodu, transfer środków i podszywanie się pod użytkownika niosą bardzo różne konsekwencje.

Te uprawnienia mogą się również łączyć. Agent, który odczytuje e-maile i tworzy zgłoszenia wsparcia, wydaje się ograniczony, gdy każde połączenie ocenia się osobno. Staje się bardziej znaczący, gdy może wyodrębniać instrukcje i uruchamiać działania zewnętrzne.

Google News pomogło przedstawić ostrzeżenie szerszemu gronu odbiorców. Jednak istotne wydarzenie miało miejsce pod warstwą agregacji. Dostawcy tożsamości i publiczne organy normalizacyjne zbliżają się do traktowania agentów jako pełnoprawnych uczestników środowiska przedsiębiorstwa.

Ta zmiana daje liderom bezpieczeństwa wyraźniejszy punkt wyjścia. Wywiera też presję, by odróżniać tożsamość agenta od użytkownika, aplikacji lub konta usługowego, które go uruchomiło.

Pożyczony token pracownika nie zapewnia tego rozróżnienia w przejrzysty sposób. Nie zapewnia go też jeden współdzielony klucz API używany przez kilku agentów. Oba rozwiązania osłabiają możliwość przypisania działań podczas audytów i dochodzeń dotyczących incydentów.

Bezpośrednia zmiana jest konceptualna, ale operacyjna. Przedsiębiorstwa potrzebują teraz odrębnych zapisów cyklu życia agentów, obejmujących utworzenie, własność, autoryzację, przegląd, zawieszenie i wycofanie.

Tożsamość stała się płaszczyzną kontroli AI

Agent potrzebuje odrębnej tożsamości, ponieważ uprawnienia bez możliwości przypisania działań zamieniają rutynową automatyzację w nieograniczony problem dochodzeniowy.

Zarządzanie tożsamością i dostępem, czyli IAM, określa, kto może uzyskać dostęp do zasobu i na jakich warunkach. Istniejące systemy IAM zapewniają już katalogi, silniki polityk, przeglądy dostępu, usługi tokenów i zapisy audytowe.

Te komponenty dają przedsiębiorstwom praktyczny fundament. Mogą zarejestrować agenta, powiązać go z właścicielem, przyznać określone uprawnienia i cofnąć je, gdy agent się zmieni lub zostanie wycofany.

NIST wzmocnił to stanowisko w swojej niedawnej analizie dotyczącej fundamentów tożsamości. Agencja ostrzegła, że wczesne wdrożenia przedkładają funkcje i natychmiastową wartość nad ugruntowane praktyki zarządzania tożsamością.

NIST wskazał również współdzielenie poświadczeń jako kluczowy problem. Współdzielone poświadczenia podważają odpowiedzialność, ponieważ osoby prowadzące dochodzenie nie mogą wiarygodnie ustalić, która osoba, usługa lub agent wykonał transakcję.

Problem staje się wyraźniejszy, gdy agenci delegują zadania. Użytkownik może poprosić jednego agenta o przygotowanie prezentacji sprzedażowej. Ten agent może wywołać inny system po dane o kliencie i trzecią usługę w celu przeprowadzenia analizy konkurencji.

Każde przekazanie tworzy decyzję autoryzacyjną. Przedsiębiorstwo musi zachować informacje o pierwotnym użytkowniku, działającym agencie, żądanym zasobie i celu stojącym za żądaniem.

Bez tego łańcucha logi mogą pokazać, że konto usługowe uzyskało dostęp do bazy danych. Nie potrafią jednak wyjaśnić, który agent zainicjował działanie, który użytkownik o nie poprosił ani czy działanie odpowiadało zatwierdzonemu procesowi.

Pełnoprawna tożsamość może przywrócić część tego kontekstu. Każdy agent otrzymuje unikalny identyfikator zamiast pożyczać konto ogólnego przeznaczenia. Polityki mogą wtedy być kierowane do konkretnego agenta.

Model ten wspiera zasadę najmniejszych uprawnień, która ogranicza tożsamość do minimalnego dostępu wymaganego do realizacji przypisanego zadania. Umożliwia też cofnięcie dostępu bez zakłócania działania niepowiązanych aplikacji lub pracy pracowników.

Krótkotrwałe tokeny wzmacniają ten model. Token to podpisane poświadczenie reprezentujące przyznane uprawnienia w ograniczonym zakresie i czasie. Krótkie terminy ważności zmniejszają wartość skradzionych poświadczeń.

Poświadczenia federacyjne stanowią kolejne usprawnienie. Pozwalają zaufanemu obciążeniu żądać tokenu bez przechowywania wielokrotnego sekretu w kodzie, plikach konfiguracyjnych lub pamięci agenta.

Własność uzupełnia podstawowy zapis. Każdy agent produkcyjny potrzebuje wskazanej osoby lub odpowiedzialnego zespołu, który odpowiada za jego cel, uprawnienia, przeglądy i wycofanie.

Właścicielem nie może być jedynie deweloper, który stworzył pierwszy prototyp. Własność biznesowa ma znaczenie, ponieważ ktoś musi zdecydować, czy dostęp agenta nadal jest konieczny.

Status cyklu życia również ma znaczenie. Agent eksperymentalny nie powinien zachowywać uprawnień produkcyjnych po zakończeniu testu. Zastąpiony agent nie powinien pozostawać aktywny tylko dlatego, że jego klucz API nadal działa.

Ta struktura przypomina zarządzanie pracownikami i aplikacjami. Agenci wymagają jednak częstszej oceny, ponieważ ich narzędzia, instrukcje, modele i delegowane zadania mogą zmieniać się niezależnie.

Przedsiębiorstwa powinny zatem traktować katalog tożsamości jako płaszczyznę kontroli, a nie statyczną książkę adresową. Rejestracja rozpoczyna zarządzanie, ale ciągłe egzekwowanie polityk nadaje mu znaczenie.

To rozróżnienie chroni również uzasadnione eksperymenty. Deweloperzy mogą otrzymać określoną ścieżkę rejestracji agenta, zamiast czekać na długą ocenę bezpieczeństwa po wdrożeniu.

Użyteczny proces rejestracji powinien obejmować cel, właściciela, środowisko, narzędzia, klasy danych, uprawnienia i oczekiwane granice działania. Powinien także przypisywać datę wygaśnięcia lub przeglądu.

Jeśli zatwierdzona ścieżka jest wolniejsza niż utworzenie niezarejestrowanego agenta, zespoły będą ją omijać. Program tożsamościowy musi więc sprawiać, że bezpieczne wdrożenie jest łatwiejsze niż ukryte uruchomienie.

W tym miejscu praktyki zarządzania wiedzą mogą wspierać zarządzanie. Zespoły potrzebują przeszukiwalnych zapisów łączących decyzje, właścicieli, wymagania, zatwierdzenia i późniejsze zmiany.

Sama inwentaryzacja odpowiada na pytanie, gdzie agent został zarejestrowany. Powiązana wiedza operacyjna wyjaśnia, dlaczego istnieje i czy jego obecne zachowanie nadal odpowiada temu celowi.

Trzy pytania ujawniają trzy różne rodzaje niepowodzeń

Wykrywanie, kontrola połączeń i zarządzanie działaniami to odrębne dyscypliny, a powodzenie w jednej z nich nie rekompensuje porażki w innej.

„Gdzie są moi agenci?” sprawdza widoczność. Zespoły bezpieczeństwa nie mogą zarządzać agentem, który istnieje wyłącznie na koncie dewelopera, w przeglądarce pracownika lub konfiguracji administratora SaaS.

Użyteczna inwentaryzacja musi obejmować wdrożenia zatwierdzone i niezatwierdzone. Musi również odróżniać aktywnych agentów od szablonów, porzuconych eksperymentów, wyłączonych instancji i zwykłych aplikacji korzystających z funkcji AI.

Inwentaryzacja powinna identyfikować środowisko i stan operacyjny każdego agenta. Agenci rozwojowi, testowi i produkcyjni nie powinni podlegać tym samym założeniom dotyczącym zatwierdzania.

Zespoły bezpieczeństwa muszą również zdecydować, co uznaje się za agenta. Chatbot, który wyłącznie zwraca tekst, ma inny profil uprawnień niż system wywołujący narzędzia lub zmieniający rekordy.

Definicja powinna koncentrować się na zachowaniu. Jeśli oprogramowanie wybiera działania, wywołuje połączone narzędzia lub deleguje pracę przy ograniczonym przeglądzie człowieka, należy do populacji objętej zarządzaniem.

„Z czym mogą się łączyć?” sprawdza graf zaufania organizacji. Graf zaufania rejestruje relacje między tożsamościami, poświadczeniami, aplikacjami, zasobami i delegowanymi usługami.

Ten graf powinien pokazywać zasięg bezpośredni i pośredni. Agent może nie mieć dostępu do bazy danych, lecz posiadać uprawnienie do wywołania usługi, która może odpytować tę samą bazę danych.

Połączenia między agentami utrudniają mapowanie. Jeden agent może przekazywać kontekst lub uprawnienia innemu, tworząc łańcuch przekraczający platformy i granice administracyjne.

Przedsiębiorstwa muszą zapisywać, czy każde połączenie wykorzystuje stały dostęp, czy autoryzację specyficzną dla zadania. Stały dostęp pozostaje dostępny między zadaniami, zwiększając ekspozycję, jeśli agent zostanie przejęty.

„Co mogą zrobić?” — to pytanie testuje kontrolę w czasie działania. Odpowiedź nie może być listą zakresów API skopiowanych z rejestracji aplikacji.

Zakres może zezwalać na modyfikację plików, ale polityka powinna nadal odróżniać rutynową edycję od usunięcia repozytorium. To samo techniczne uprawnienie może obejmować działania o różnych konsekwencjach biznesowych.

Autoryzacja w czasie działania ocenia proponowane działanie w chwili jego wykonania. Może uwzględniać działającego agenta, użytkownika inicjującego, wrażliwość zasobu, żądaną operację, lokalizację i bieżące sygnały ryzyka.

Niektóre decyzje powinny pozostać automatyczne. Wymaganie ludzkiej zgody dla każdego wyszukiwania o niskim ryzyku zniweczyłoby obiecywaną przez agentów wartość produktywności.

Działania o dużym wpływie zasługują na silniejsze zabezpieczenia. Zmiany w systemach produkcyjnych, transfery pieniędzy, ujawnianie informacji regulowanych i nieodwracalne usunięcia wymagają wyraźnych środków ochronnych.

Zatwierdzanie z udziałem człowieka jest jedną z opcji. Umieszcza człowieka w określonym punkcie decyzyjnym, zanim agent wykona wrażliwe działanie.

Zgoda musi zawierać istotny kontekst. Komunikat „zezwól na działanie”, który nie wskazuje zasobu, danych, celu i oczekiwanego skutku, staje się ceremonialnym polem wyboru.

Organizacje potrzebują też niezawodnego mechanizmu dezaktywacji. Wyłącznik awaryjny powinien cofać aktywny dostęp agenta we wszystkich połączonych systemach, zamiast wyłączać wyłącznie jego widoczny interfejs.

Ta możliwość zależy od architektury poświadczeń. Centralne cofanie dostępu działa słabo, gdy agenci korzystają z rozproszonych kluczy API, tokenów zapisanych w pamięci podręcznej lub poświadczeń skopiowanych do zewnętrznych usług.

Te trzy pytania tworzą więc sekwencję. Odkrywanie ustala podmiot, mapowanie połączeń definiuje potencjalny zasięg, a zarządzanie działaniami kontroluje wykorzystywane uprawnienia.

Pominięcie tej sekwencji tworzy fałszywe poczucie bezpieczeństwa. Organizacja może prowadzić kompletny katalog agentów, pozostawiając każdemu z nich nadmierne uprawnienia.

Może też wydawać tokeny o wąskim zakresie, nie zauważając agentów utworzonych przez pracowników. Alternatywnie może rejestrować działania agentów bez zachowania wystarczającego kontekstu tożsamości, aby je przypisać.

Wartość tego modelu leży w tych granicach awarii. Każde pytanie daje audytorom i liderom bezpieczeństwa konkretną tezę do sprawdzenia, zamiast ogólnego zapewnienia o „odpowiedzialnej AI”.

Kontrole tożsamości nie potrafią ocenić, czy działanie jest rozsądne

Prawidłowa tożsamość odpowiada na pytanie, kto działa, ale nie gwarantuje, że agent zrozumiał prośbę ani wybrał bezpieczne działanie.

To ograniczenie definiuje centralny kompromis omawiany w artykule. Przedsiębiorstwa potrzebują kontroli opartych na tożsamości, jednak agenci pozostają mniej przewidywalni niż tradycyjne aplikacje korzystające z tych samych poświadczeń.

Konwencjonalna usługa wykonuje kod napisany dla znanego przepływu pracy. Agent może interpretować instrukcje, wybierać narzędzia, generować parametry i dostosowywać swoje działania na podstawie zwróconych informacji.

Ta elastyczność tworzy wartość. Oznacza też, że pomyślne uwierzytelnienie nie może być dowodem, iż kolejna decyzja odpowiada intencjom użytkownika.

Prompt injection ilustruje tę lukę. Agent może napotkać złośliwe instrukcje w dokumencie, e-mailu, na stronie internetowej lub w pobranym rekordzie i uznać je za część swojego zadania.

Atakujący nie musi kraść tożsamości agenta. Może próbować zmanipulować prawidłowo uwierzytelnionego agenta, aby nadużył swoich legalnych uprawnień.

OWASP wymienia nadużycia tożsamości i uprawnień wśród swoich zagrożeń bezpieczeństwa agentów. Kategoria obejmuje manipulowanie łańcuchami delegowania, dziedziczonymi rolami, poświadczeniami przechowywanymi w pamięci podręcznej i kontekstem agenta.

Niewłaściwe użycie narzędzi stwarza kolejny problem. Agent może wywołać zatwierdzone narzędzie z niebezpiecznymi argumentami lub na niewłaściwym etapie przepływu pracy.

Kontrole tożsamości mogą odmówić dostępu do niezatwierdzonego narzędzia. Nie są jednak w stanie samodzielnie określić, czy każde dozwolone wywołanie wspiera rzeczywisty cel użytkownika.

Architektura bezpieczeństwa musi zatem traktować model jako niezaufany komponent decyzyjny. Deterministyczne kontrole powinny pozostawać poza modelem wszędzie tam, gdzie konsekwencje mają znaczenie.

Kontrola deterministyczna stosuje jawne reguły zamiast generować probabilistyczną odpowiedź. Przykłady obejmują sprawdzanie uprawnień, walidację schematów, limity transakcji i obowiązkowe bramki zatwierdzania.

Silnik polityk powinien oceniać to, co proponuje agent, a nie polegać na tym, że agent sam się kontroluje. Agent nie powinien mieć możliwości przepisywania reguł kontrolujących jego uprawnienia.

Walidacja danych wejściowych i wyjściowych pozostaje istotna. Parametry narzędzi powinny być zgodne z oczekiwanymi schematami, limitami zasobów, klasyfikacjami danych i zatwierdzonymi miejscami docelowymi.

Kontrole sieciowe mogą dodatkowo ograniczyć zasięg. Agent, który nigdy nie potrzebuje dostępu do publicznego internetu, nie powinien otrzymywać go domyślnie.

Kontrole danych mają znaczenie, ponieważ tożsamość nie zapobiega nieodpowiedniemu ujawnieniu danych zatwierdzonemu odbiorcy. Polityki muszą uwzględniać również wrażliwość danych, cel i retencję.

Monitoring musi koncentrować się na zachowaniu, a nie tylko na logowaniach. Pomyślne uwierzytelnienie, po którym następuje nietypowe wyliczanie zasobów, masowe pobieranie danych lub powtarzające się odmowy działania, zasługuje na zbadanie.

W tym miejscu teza „najpierw tożsamość” wymaga ostrożnego sformułowania. Tożsamość zapewnia fundament odpowiedzialności, cofania dostępu i polityk. Nie jest kompletnym systemem bezpieczeństwa agentów.

Komercyjna platforma tożsamości może centralizować rejestrację i tokeny. Nie może zagwarantować, że każdy podłączony model oprze się manipulacji lub prawidłowo zinterpretuje niejednoznaczne cele.

Neutralność wobec dostawców również pozostaje niepewna. Agenci będą obejmować Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, wewnętrzne frameworki i wyspecjalizowane produkty SaaS.

Każda platforma może reprezentować agentów inaczej. Tożsamość międzyplatformowa wymaga interoperacyjnych tokenów, spójnych oświadczeń, zaufanych wystawców i polityk, które przetrwają przekazanie kontroli.

MCP dodaje kolejną granicę. Przedsiębiorstwo może zarządzać agentem, jednocześnie polegając na zewnętrznym serwerze, który musi poprawnie udostępniać narzędzia i chronić własne poświadczenia.

Warstwa tożsamości także potrzebuje ochrony przed przejęciem. Scentralizowane katalogi i usługi tokenów stają się wartościowymi celami, ponieważ mogą jednocześnie wpływać na wielu agentów.

Przedsiębiorstwa powinny rozdzielać obowiązki administracyjne, chronić zmiany o wysokich uprawnieniach i monitorować nietypowe modyfikacje polityk. Zarządzanie agentami nie może opierać się na jednym, szeroko uprzywilejowanym koncie konsoli.

Dzienniki audytowe zasługują na taki sam sceptycyzm. Duża liczba zdarzeń nie oznacza automatycznie użytecznych dowodów.

Osoby prowadzące dochodzenie potrzebują zapisów łączących żądanie użytkownika, tożsamość agenta, delegowanych agentów, wybrane narzędzie, decyzję autoryzacyjną, zasób, którego dotyczy działanie, oraz wynik końcowy.

Polityki retencji muszą zachowywać ten łańcuch wystarczająco długo na potrzeby dochodzeń i przeglądów regulacyjnych. Wrażliwe prompty i wyniki mogą wymagać minimalizacji lub ograniczonego dostępu.

Właściwy wniosek jest węższy niż przekaz dostawców. Tożsamość jest początkiem bezpieczeństwa agentów, ponieważ kontrola potrzebuje znanego podmiotu.

Bezpieczeństwo nadal wymaga warstwowej ochrony wokół tego podmiotu. Warstwy te obejmują ograniczone narzędzia, zewnętrzne polityki, chronione poświadczenia, kontrole danych, monitoring i przegląd przez człowieka.

Microsoft i Okta zamieniają model w produkty

Idea „najpierw tożsamość” przechodzi z języka konferencji do katalogów, przepływów tokenów, systemów odkrywania i kontroli cofania dostępu.

Microsoft Entra Agent ID pokazuje, jak duża platforma obecnie bezpośrednio reprezentuje agentów. Microsoft opisuje tożsamość agenta jako wyspecjalizowaną jednostkę usługi z unikalnym identyfikatorem.

Jednostka usługi reprezentuje aplikację lub obciążenie robocze w dzierżawie tożsamości. Wersja dla agenta pozwala politykom i dziennikom odróżniać agenta od jego bazowego planu.

Microsoftowy przepływ autonomicznego uwierzytelniania oddziela tożsamość agenta od wielokrotnie wykorzystywanych sekretów produkcyjnych. Dokumentacja zaleca tożsamości zarządzane lub certyfikaty zamiast sekretów klienta.

Autonomiczni agenci mogą żądać tokenów aplikacji dla własnej tożsamości. Agenci interaktywni mogą korzystać z przepływów delegowanych, gdy działają w imieniu uwierzytelnionego użytkownika.

Ta różnica jest kluczowa. Autonomiczny agent tworzący nocne raporty nie powinien wyglądać identycznie jak asystent wykonujący jedno działanie dla zalogowanego pracownika.

Autoryzacja on-behalf-of zachowuje relację z użytkownikiem podczas delegowania. Wynikowy token może identyfikować użytkownika jako podmiot, a agenta jako wykonawcę.

Taki projekt dostarcza serwerom zasobów więcej kontekstu do autoryzacji. System może zapytać, czy dany użytkownik, działając za pośrednictwem tego agenta, może wykonać żądaną operację.

Microsoft dokumentuje również specjalne konta użytkowników agentów dla zasobów wymagających obiektów podobnych do użytkowników. Takie konta mogą obsługiwać skrzynki pocztowe lub funkcje współpracy bez używania zwykłych ludzkich poświadczeń.

Konta te podlegają ograniczeniom. Microsoft podaje, że nie mogą otrzymywać uprzywilejowanych ról administratora, co tworzy granicę przeciwko niektórym formom eskalacji.

Okta realizuje ten sam rynek z neutralnej wobec platform perspektywy tożsamości. Jej kwietniowe uruchomienie tożsamości agentów opisywało odkrywanie, rejestrację, zarządzane połączenia, zarządzanie i dezaktywację.

Firma twierdzi, że jej katalog może importować agentów z zewnętrznych platform i rejestrować niestandardowych agentów. Opisuje również wykrywanie nieautoryzowanych agentów za pośrednictwem sygnałów zgody OAuth.

Okta przedstawia swój produkt wokół tych samych trzech pytań powtórzonych w artykule gościnnym GuidePoint. To podobieństwo potwierdza komercyjny kontekst artykułu.

Przekaz produktowy zasługuje na krytyczną ocenę, ale kategorie wdrożeniowe są konkretne. Przedsiębiorstwa potrzebują katalogów agentów, wąskich tokenów dla połączeń i egzekwowania polityk dla działań.

Konkurencja powinna przynieść korzyści kupującym, jeśli platformy udostępnią interoperacyjne kontrole. Model Microsoft może odpowiadać organizacjom skoncentrowanym na Entra i Microsoft Graph.

Okta kładzie nacisk na zarządzanie w wielu chmurach, aplikacjach i frameworkach agentowych. Dostawcy chmurowi będą naturalnie integrować swoje usługi agentowe z istniejącymi systemami tożsamości obciążeń roboczych.

Zagrożeniem jest fragmentacja. Przedsiębiorstwo może skończyć z jednym inwentarzem agentów na każdą chmurę, kolejnym u swojego dostawcy tożsamości i kilkoma w portalach administracyjnych SaaS.

Te inwentarze będą się różnić, jeśli organizacja nie zdefiniuje kanonicznego procesu własności i cyklu życia. Narzędzia wykrywania powinny zasilać ten proces, zamiast tworzyć równoległe źródła prawdy.

Kolejną kwestią jest zgodność tokenów. OAuth może standaryzować mechanikę autoryzacji, ale dostawcy mogą różnić się pod względem oświadczeń tożsamości, dowodów delegowania i kontroli polityk w czasie działania.

Komunikacja agent-agent podnosi stawkę. Pierwszy agent może przenosić delegowane uprawnienia użytkownika, podczas gdy agent downstream działa autonomicznie w ramach uprawnień aplikacji.

Łańcuch autoryzacji musi pokazywać, gdzie zmieniły się uprawnienia. W przeciwnym razie zatwierdzone żądanie użytkownika może stać się szerokim działaniem maszyny bez widocznej eskalacji.

Zespoły zakupowe powinny testować produkty na rzeczywistych przepływach pracy. Dopracowany interfejs katalogu ma mniejsze znaczenie niż to, czy platforma potrafi cofnąć dostęp we wszystkich objętych działaniem konektorach.

Powinny również testować możliwość eksportu. Dane audytowe muszą pozostać dostępne na potrzeby reagowania na incydenty, zgodności i migracji, bez zależności od jednego zastrzeżonego widoku dochodzeniowego.

Zespoły bezpieczeństwa powinny unikać przyznawania nowej platformie agentowej nieograniczonego dostępu wyłącznie po to, by poprawić widoczność. Architektura odkrywania potrzebuje własnego przeglądu pod kątem zasady najmniejszych uprawnień.

Rynek zmierza więc w kierunku tożsamości jako wspólnej infrastruktury. Zwycięzcy nie będą jedynie rejestrować agentów.

Będą zachowywać atrybucję między platformami, ograniczać stałe poświadczenia, wspierać szczegółowe unieważnianie dostępu i ujawniać decyzje polityk w rejestrach, które narzędzia zewnętrzne mogą oceniać.

Co przedsiębiorstwa powinny zweryfikować przed skalowaniem agentów

Kolejny etap będzie mierzony dowodami z wdrożeń, a nie liczbą dostawców powtarzających hasło „tożsamość pierwszej klasy”.

Pierwszym sygnałem będzie to, czy przedsiębiorstwa tworzą kompletne inwentaryzacje obejmujące agentów działających poza oficjalnym nadzorem. Katalog zasilany wyłącznie poprzez formalne wdrożenia pominie najbardziej ryzykowne wdrożenia.

Organizacje powinny porównywać rejestry tożsamości z przyznanymi uprawnieniami OAuth, zasobami chmurowymi, telemetrią przeglądarek, użyciem API i konfiguracjami SaaS. Duże rozbieżności osłabiłyby obietnicę podejścia identity-first.

Drugim sygnałem będzie to, czy krótkotrwała, ograniczona zakresem autoryzacja zastępuje statyczne sekrety. Liczba migracji ma większe znaczenie niż zdolność platformy do wydawania nowoczesnych tokenów dla nowych agentów.

Zespoły powinny zidentyfikować istniejących agentów korzystających z osadzonych kluczy API, współdzielonych kont usługowych i długotrwałych tokenów odświeżania. Następnie powinny mierzyć, jak szybko te poświadczenia znikają.

Dokumentacja Microsoft daje przedsiębiorstwom jeden techniczny punkt odniesienia. Jej wytyczne produkcyjne preferują poświadczenia federacyjne i zarządzane tożsamości zamiast przechowywanych sekretów klienta.

Trzecim sygnałem będzie to, czy kontrole środowiska wykonawczego przetrwają delegowanie między platformami. To zdecyduje, czy tożsamość agentów stanie się prawdziwą infrastrukturą, czy kolejną odizolowaną kategorią produktów.

Przydatny test zaczyna się od jednego żądania człowieka, które uruchamia kilku agentów i narzędzia. Osoby prowadzące analizę powinny odtworzyć cały łańcuch bez ręcznego korelowania niepowiązanych logów.

Rejestr powinien wskazywać osobę inicjującą, każdego uczestniczącego agenta, każdą wymianę tokenów, zastosowaną politykę oraz każdy zasób, którego dotyczyło działanie.

Unieważnianie dostępu powinno działać w całym tym samym łańcuchu. Wyłączenie agenta inicjującego nie może pozostawiać aktywnych delegowanych poświadczeń ani sesji podrzędnych.

Przedsiębiorstwa powinny również przeprowadzać testy adversarialne. Zespół red team może umieścić złośliwe instrukcje w treści, którą upoważniony agent ma pobrać.

Test powinien wykazać, czy zewnętrzna polityka blokuje niebezpieczne działania po tym, jak model zaakceptuje instrukcje. Sama tożsamość nie zapewni takiego rezultatu.

Liderzy biznesowi potrzebują ram decyzyjnych określających dopuszczalny poziom autonomii. Nie każdy agent wymaga identycznego przeglądu, ponieważ konsekwencje znacznie się różnią.

Asystent badawczy, który czyta publiczne dokumenty, wiąże się z innym ryzykiem niż agent edytujący kod produkcyjny. Agent obsługujący zobowiązania wobec dostawców tworzy jeszcze inną kategorię.

Przeglądy dostępu powinny odzwierciedlać te różnice. Agenci o dużym wpływie potrzebują krótszych cykli certyfikacji, ściślejszych limitów, silniejszego monitorowania oraz określonych punktów zatwierdzania przez człowieka.

Plany reagowania na incydenty muszą uwzględniać agentów jako podmioty działania. Zespoły powinny wiedzieć, jak zawiesić tożsamość, unieważnić tokeny, odizolować konektory, zachować logi i zidentyfikować dane, których dotyczy incydent.

Plan powinien obejmować także skompromitowanych agentów zewnętrznych. Wstępnie przyznane zaufanie OAuth może pozostać niebezpieczne nawet wtedy, gdy wewnętrzny kod przedsiębiorstwa nigdy nie został naruszony.

Zespoły bezpieczeństwa powinny pytać dostawców, jak szybko ujawniają kompromitację konektorów i unieważniają wydany dostęp. Zapisy umowne powinny regulować kwestie logów, powiadomień i wsparcia w dochodzeniu.

Deweloperzy potrzebują jaśniejszych standardów już na etapie projektowania. Każdy nowy agent powinien deklarować swojego właściciela, narzędzia, klasy danych, model autoryzacji oraz maksymalny dopuszczalny skutek działania.

Informacje te mogą stać się częścią wewnętrznego rejestru AI workflow. Zespoły produktowe, bezpieczeństwa i inżynieryjne mogą następnie oceniać zmiany względem pierwotnego celu.

Materiał w Google News stanowi użyteczny punkt kontrolny, lecz powtarzania nie należy mylić z rozwiązaniem problemu. Dostawcy tożsamości zdefiniowali problem wyraźniej, niż przedsiębiorstwa wdrożyły odpowiedź.

Te trzy pytania tworzą praktyczny pierwszy przegląd. Czy organizacja potrafi nazwać każdego agenta? Czy potrafi zmapować każdy osiągalny system? Czy potrafi ograniczyć i odtworzyć każde istotne działanie?

Odpowiedź „tak” wymaga dowodów z katalogów, tokenów, polityk i logów. Arkusz kalkulacyjny utrzymywany na potrzeby audytu nie dowodzi kontroli nad środowiskiem wykonawczym.

Zacznij od jednego produkcyjnego przepływu pracy i prześledź go od ludzkiej intencji do końcowego efektu. Usuń współdzielone poświadczenia, zawęź każde połączenie i określ, gdzie automatyczne działanie musi się zatrzymać.

Następnie przetestuj unieważnianie dostępu i odtwarzanie przebiegu pod presją. Jeśli któreś z nich zawiedzie, agent ma większą autonomię, niż organizacja może bezpiecznie wyjaśnić.

Google News przejdzie do kolejnego nagłówka. Luka w tożsamości pozostanie, dopóki przedsiębiorstwa nie będą w stanie powiązać każdego działania agenta z ograniczonymi uprawnieniami, jasną odpowiedzialnością i egzekwowalną polityką.