Kiedy AI dostaje dostęp: OAuth, connectory i agentic AI

jak AI zdobywa dostęp

Narzędzia AI docierają do twoich danych tymi samymi mechanizmami połączeń co każde inne oprogramowanie. Pod spodem nie ma nic egzotycznego. Nowe jest to, jak szerokie bywają żądania i jak rzadko są przeglądane. Są trzy typowe ścieżki.

Grant OAuth. Kiedy narzędzie AI łączy się z Google Workspace albo Microsoft 365, prosi o zgodę na konkretne działania na danych firmowych. Czytanie poczty. Wgląd w pliki i ich edycję. Dostęp do kalendarza. Pracownik klika Zezwól, a narzędzie otrzymuje token. Ten token to stały dostęp do danych firmowych, powiązany z tożsamością pracownika, trzymany przez narzędzie AI, dopóki ktoś go nie cofnie. Dostęp, jaki niesie, definiują jego scope'y. Scope taki jak Mail.Read albo gmail.readonly daje dostęp do odczytu całej skrzynki pocztowej. Scope taki jak Files.ReadWrite.All albo drive daje dostęp do odczytu i zapisu w całym zakresie, do którego dociera użytkownik. Asystenci AI często proszą o te szerokie, bo ogólny asystent jest zbudowany tak, żeby dotykać wielu rzeczy naraz.

Integracja z aplikacją SaaS albo repozytorium. Narzędzie AI zostaje dodane do repozytorium kodu, systemu ticketowego, CRM-u albo platformy czatowej. Integracja dostaje dostęp do odczytu, a czasem zapisu, wewnątrz tego systemu. Asystent kodowania podłączony do repozytorium źródłowego może czytać kod i, zależnie od grantu, otwierać pull requesty. AI dodana do systemu obsługi klienta może czytać rekordy i na nich działać.

Token API. Narzędzie AI albo workflow dostaje klucz API albo dane uwierzytelniające serwisowe, żeby wywoływać system bezpośrednio. Token niesie takie uprawnienia, z jakimi został wydany, i nie należy do żadnej osoby. Leży poza twoją polityką haseł i MFA, i trwa, dopóki nie zostanie rotowany albo usunięty.

We wszystkich trzech przypadkach wzorzec jest ten sam. Grant to stały dostęp pod tożsamością użytkownika albo danymi uwierzytelniającymi serwisowymi. Często jest szeroko wydzielony, bo narzędzie jest zbudowane tak, żeby być użyteczne w wielu zadaniach naraz. I często jest nieprzeglądany, bo połączenie zachodzi wewnątrz własnego procesu narzędzia, nie wewnątrz procesu IT. Dział IT często dowiaduje się o istnieniu integracji AI dopiero, kiedy robi inwentaryzację.

agentic AI i blast radius

Tam, gdzie copilot czeka, aż człowiek zaakceptuje jego podpowiedź, agent po prostu wykonuje pracę. To zmiana, którą warto zrozumieć. Agent AI jest zbudowany tak, żeby przeprowadzać wieloetapową pracę bez zatwierdzania każdego kroku przez człowieka. Czyta system, decyduje, co zrobić, zapisuje w innym systemie i idzie dalej. Żeby to zrobić, trzyma dostęp do systemów, w których działa, albo przez własne dane uwierzytelniające, albo przez grant delegowany mu przez użytkownika.

Dostęp, jaki trzyma agent, to suma jego scope'ów. Jeśli agent potrafi czytać twoją skrzynkę, zapisywać w magazynie plików, odpytywać CRM i publikować na platformie czatowej, to jego zasięg to wszystko to naraz. Ten połączony zasięg to jego blast radius. To, czego agent może dotknąć, kiedy działa zgodnie z zamierzeniem, i to samo, czego może dotknąć atakujący, jeśli agent zostanie przejęty albo zmanipulowany.

Dwie cechy sprawiają, że agent z nadmiernie szerokim scope'em zasługuje na szczególną uwagę. To cel wysokiej wartości: agent trzymający szeroki, stały dostęp do kilku systemów to pojedyncze dane uwierzytelniające, które otwierają wiele drzwi, a atakujący, który dotrze do tych danych, dociera do wszystkiego, co za nimi stoi. I to pojedynczy punkt awarii: bo agent działa samodzielnie, błąd albo manipulacja propaguje się bez human-in-the-loop, który mógłby to wyłapać. Agenta, którym da się sterować przez jego dane wejściowe, na przykład przez treść, którą czyta w ramach zadania, można skłonić do działania poza zamierzonym zakresem, wykorzystując właśnie ten dostęp, który mu nadałeś. Szkoda jest ograniczona jego scope'ami, nie jego instrukcjami.

Nic z tego nie przekreśla sensu używania agentów. To argument za tym, żeby świadomie wydzielać im dostęp. Agent, który potrafi tylko odczytać dostępność w kalendarzu i przygotować szkic zaproszenia na spotkanie, ma mały blast radius. Agent z pełną skrzynką, pełnym dyskiem i odczytem katalogu ma duży. Różnica to decyzja projektowa, którą podejmujesz w momencie podłączania go, i dużo łatwiej zrobić to wąsko od początku niż cofać się później. Jest tu szerszy wzorzec: atakujący już korzystają z AI we własnych operacjach. W jednej z analiz 16% naruszeń dotyczyło atakujących korzystających z AI (IBM, 2025). W miarę jak agenci AI przejmują stały dostęp wewnątrz firm, stają się częścią powierzchni ataku, obok tego, że są narzędziem w rękach atakującego.

zarządzanie dostępem AI: metoda praktyczna

Dostępem narzędzia AI zarządzasz tak samo, jak dostępem każdej aplikacji firmy trzeciej. Aktor jest inny. Dyscyplina nie. Oto metoda, którą możesz przeprowadzić za pomocą konsol administracyjnych, które już masz.

Krok pierwszy: znajdź, co trzymają narzędzia AI. Wypisz asystentów AI, copiloty i integracje podłączone do twojego środowiska, i zapisz scope'y, jakie trzyma każdy z nich. W Google Workspace podłączone aplikacje i ich scope'y widać w Security, potem API controls, potem App access control. W Microsoft Entra są pod Enterprise applications, gdzie możesz otworzyć każdą aplikację i przeczytać jej uprawnienia. Zapisz nazwę narzędzia, jego scope'y, liczbę użytkowników, którzy je autoryzowali, i wydawcę. Jeden wiersz na narzędzie wystarczy na początek.

Krok drugi: przeczytaj scope'y na tle zadania. Dla każdego narzędzia AI zapytaj, czy jego dostęp pasuje do tego, do czego służy. Asystent spotkań musi czytać kalendarze. Nie musi czytać każdego e-maila. Asystent dokumentów potrzebuje pliku, nad którym pracuje. Nie potrzebuje dostępu do zapisu w całym dysku. Kiedy scope jest dużo szerszy niż zadanie, to sygnał ostrzegawczy, niezależnie od tego, jak znany jest dostawca. Zwróć największą uwagę na scope'y danych, te, które czytają albo zmieniają pocztę, pliki i katalog, oraz na każdy grant, który obejmuje offline access, pozwalający narzędziu działać dalej po odejściu użytkownika.

Krok trzeci: zastosuj least privilege. Tam, gdzie narzędzie AI ma więcej dostępu, niż potrzebuje, zawęź go. Wybieraj wąsko wydzielone połączenie zamiast szerokiego, kiedy oba wykonają zadanie. Tam, gdzie narzędzie oferuje wersję read-only i read-write połączenia, wybieraj read-only, chyba że zapis jest naprawdę potrzebny. Celem jest dopasowanie zasięgu każdego narzędzia AI do jego przeznaczenia, żeby jego blast radius był tak mały, jak pozwala na to praca.

Krok czwarty: ogranicz, kto może nadawać szeroki dostęp. Skonfiguruj swój tenant tak, żeby połączenia żądające szerokich scope'ów danych wymagały zatwierdzenia przez administratora. Pozwól pracownikom samodzielnie wyrażać zgodę tylko na scope'y na poziomie logowania od rozpoznanych wydawców. To utrzymuje łatwą ścieżkę otwartą dla narzędzi niskiego ryzyka i kieruje szerokie granty AI przez osobę, która może je zobaczyć, zanim dostęp zacznie działać. Połącz to ograniczenie z prostą ścieżką zgłoszeń, żeby pracownik, który chce narzędzia AI, mógł poprosić i szybko dostać decyzję, zamiast obchodzić kontrolę.

Krok piąty: traktuj dane uwierzytelniające agenta jak tożsamość uprzywilejowaną. Agent AI z własnymi danymi uwierzytelniającymi i stałym dostępem to tożsamość uprzywilejowana i zasługuje na takie samo traktowanie. Nadaj mu najwęższe scope'y, które pozwolą mu działać. Rotuj jego dane uwierzytelniające. Wiedz, kto jest jego właścicielem i kto odpowiada za to, że nadal trzyma dostęp. Zapisz, do czego może dotrzeć. Dane uwierzytelniające agenta, których nikt nie jest właścicielem i nikt nie rotuje, to dokładnie ten rodzaj stałego dostępu, który później staje się problemem.

Krok szósty: ustaw rytm przeglądów. Narzędzia AI i ich granty kumulują się nieustannie, więc jednorazowy przegląd szybko się dezaktualizuje. Kwartalny przegląd szeroko wydzielonych, powszechnie używanych narzędzi AI, z półrocznym przejściem przez resztę, to obronny punkt wyjścia. Wpleć sprawdzenie grantów AI też w offboarding, żeby podłączone narzędzia AI odchodzącego pracownika były przeglądane w momencie wyłączenia jego konta, a nie miesiące później.

To ten sam workflow, który przeprowadziłbyś dla każdej podłączonej aplikacji. To, co zmienia się dla AI, to akcent. Narzędzia AI mają tendencję do żądania szerokich scope'ów, rozprzestrzeniają się szybko, bo są użyteczne, a agenci dokładają stały dostęp, który działa samodzielnie. Więc test scope kontra zadanie i rytm przeglądów liczą się bardziej, nie mniej.

uczciwa uwaga o zakresie

Przegląd katalogu i OAuth daje jasny obraz, i dla większości firm pokrywa część powierzchni dostępu AI, na którą nikt wcześniej nie spojrzał. Warto być precyzyjnym co do tego, co widzi, a czego nie.

Widok katalogu i OAuth pokazuje aplikacje AI podłączone przez OAuth i przez twoje single sign-on, oraz scope'y, jakie trzymają. To obejmuje asystentów i integracje wpięte w Google Workspace albo Microsoft 365, czyli miejsce, gdzie mieszka duża część stałego dostępu. Nie widzi wszystkiego. Nie widzi osobistego konta AI, którego pracownik używa poza katalogiem, bo nic nie zostało podłączone do twojego tenanta. Nie widzi rozszerzenia przeglądarki działającego na czyimś laptopie, bo to żyje na endpoincie, nie w twoim katalogu. Do tego potrzebne są inne sygnały: zarządzanie endpointami albo urządzeniami mobilnymi daje widoczność tego, co działa na firmowych urządzeniach, a narzędzie bezpieczeństwa przeglądarki daje widoczność rozszerzeń i tego, do czego ludzie się logują w przeglądarce.

Przegląd OAuth mówi ci, jakie narzędzia AI trzymają stały dostęp przez twój katalog. Nie mówi ci o AI, której ktoś używa na osobistym koncie albo przez rozszerzenie. Znajomość tej granicy oznacza, że nie mylisz czystej listy OAuth z pełnym obrazem każdego używanego narzędzia AI.

związek z dyscypliną tożsamości

Warto zapamiętać, że nic z tego nie jest nową kategorią problemu. Narzędzie AI z grantem OAuth to aplikacja firmy trzeciej ze stałym dostępem do twoich danych. Agent AI z delegowanym dostępem to tożsamość maszynowa ze scope'ami. Dla obu masz już dyscyplinę. To zarządzanie dostępem.

To pytania, które już zadajesz o każdą podłączoną aplikację. Co trzyma. Czy scope pasuje do zadania. Kto go zatwierdził. Kto jest właścicielem. Kiedy był ostatnio przeglądany. Pytania zostają te same. AI zasługuje na uwagę, bo narzędzia AI rozprzestrzeniły się szybko, mają tendencję do proszenia o szeroki dostęp, bo to właśnie czyni je użytecznymi, a agenci dokładają rodzaj aktora, który działa samodzielnie. Te cechy sprawiają, że istniejąca dyscyplina staje się cenniejsza, zastosowana do szybko rosnącej części twojej powierzchni dostępu.

To mieści się w szerszym wzorcu, który nie jest specyficzny dla AI. Udział firm trzecich pojawił się w 48% naruszeń, wobec 30% rok wcześniej (Verizon Data Breach Investigations Report 2026). Podpięte aplikacje to jedna z najbardziej bezpośrednich form dostępu firm trzecich do twoich danych, a narzędzia AI to dziś ich rosnący udział. Traktowanie dostępu AI jako części zarządzania tożsamością i dostępem, a nie osobnego problemu AI, to sposób, żeby mieć to pod kontrolą.