Agenci AI potrzebują granic danych. Nowe kontrole VPC Service Controls

Agent AI może działać w imieniu człowieka, wywoływać narzędzia i sięgać do danych w wielu projektach chmurowych. To przyspiesza pracę, ale sprawia też, że jeden zbyt szeroki dostęp może być używany szybciej i na większą skalę niż przez pojedynczego pracownika. Google Cloud ogłosił 15 października nowe możliwości VPC Service Controls, które mają ułatwić budowę i utrzymanie granic danych w rozbudowanych środowiskach.

Najważniejsza zmiana to możliwość objęcia perymetrem całego folderu Google Cloud. Projekty i zagnieżdżone foldery dziedziczą wtedy ochronę, a nowy projekt trafiający do właściwej części hierarchii nie wymaga ręcznego dopisania. Do reguł wejścia i wyjścia można też odnosić się do folderów i organizacji, zamiast wymieniać długą listę projektów.

Wniosek Breachroad: jest to użyteczna warstwa przeciw wynoszeniu danych, ale nie „ochrona agenta AI” w jednym przełączniku. Perymetr nie zastępuje IAM, minimalnych uprawnień narzędzi, kontroli promptów, zatwierdzania ryzykownych akcji, rejestrowania działań ani testów bezpieczeństwa. Powinien działać razem z nimi.

Co w praktyce się zmienia

Google opisuje kilka elementów, które pomagają zastąpić ręczne listy bardziej trwałą polityką:

• foldery mogą należeć do perymetru, więc ochrona podąża za hierarchią projektów;
• foldery i całe organizacje mogą być wskazywane w regułach ingress i egress;
• endpoint Private Service Connect dla interfejsów Google API może stać się atrybutem reguły, wiążąc zezwolenie z konkretną prywatną ścieżką;
• wzorce usług w VPC accessible services pozwalają ograniczać dostęp do wybranych wzorców adresów API używanych przez prywatny VIP;
• Violation Analyzer może proponować wąsko zdefiniowaną zmianę po blokadzie, a administrator może najpierw ocenić ją w trybie dry run.

Dokumentacja folder membership wyjaśnia, że projekty dodane później do chronionego folderu automatycznie trafiają do tego samego perymetru. Przeniesienie projektu lub folderu zmienia jednak efektywną ochronę. Hierarchia zasobów przestaje być tylko sposobem porządkowania rachunków — staje się częścią mechanizmu bezpieczeństwa.

Statusy funkcji trzeba sprawdzać osobno w dokumentacji i release notes VPC Service Controls. Folder membership oraz obsługa folderów i organizacji w regułach zostały udostępnione ogólnie, natomiast niektóre sąsiednie możliwości, w tym automatyczne sugestie remediacji, mogą mieć inny etap dostępności. Organizacja powinna potwierdzić status funkcji w swoim zakresie, zanim oprze na niej kontrolę produkcyjną.

Dlaczego ma to znaczenie dla agentów AI

Klasyczna aplikacja zwykle wykonuje zestaw przewidywalnych operacji. Agent wybiera kolejne kroki na podstawie celu, kontekstu i wyników narzędzi. Może odczytać dokument, wywołać wyszukiwarkę, zapisać plik, uruchomić zadanie analityczne i przesłać wynik do innej usługi. Nawet jeżeli każda czynność jest dozwolona osobno, ich nieprzewidziana kombinacja może przekroczyć intencję właściciela procesu.

Perymetr danych dodaje granicę niezależną od samej decyzji modelu. Jeżeli agent lub przejęte poświadczenie próbuje wysłać dane do zasobu poza dozwolonym obszarem, VPC Service Controls może zablokować obsługiwany przepływ. Ma to znaczenie zwłaszcza wtedy, gdy konto posiada formalne uprawnienie IAM, ale żądanie pochodzi z niewłaściwego kontekstu lub zmierza poza właściwą granicę.

Nie wszystkie dane i usługi są jednak objęte VPC Service Controls. Agent może korzystać z zewnętrznego SaaS, publicznego internetu, firmowego API albo narzędzia działającego poza wspieranym zakresem. Dlatego pierwszy krok to mapa rzeczywistych przepływów, a nie założenie, że nazwa „perymetr” obejmuje wszystko.

Jak zaprojektować granicę dla konkretnego procesu

Zacznij od jednej wartości biznesowej, na przykład agenta wspierającego dział obsługi klienta. Zapisz, kto uruchamia proces, jakiej tożsamości używa agent, jakie źródła może czytać, które narzędzia może wywołać, gdzie trafia odpowiedź i które działanie wymaga zgody człowieka.

Następnie podziel dane według konsekwencji ujawnienia. Baza publicznych instrukcji, dokumentacja wewnętrzna, zgłoszenia klientów i dane uwierzytelniające nie powinny automatycznie trafić do jednego obszaru tylko dlatego, że jeden agent może ich potrzebować. Osobne projekty lub foldery mają sens dopiero wtedy, gdy odpowiadają rzeczywistej polityce właścicieli i przepływów.

Proponowana kolejność wdrożenia wygląda następująco:

1. Zinwentaryzuj projekty, dane, usługi, tożsamości agenta i jego narzędzia.
2. Zdefiniuj foldery zgodne z granicami danych, a nie wyłącznie strukturą zespołów.
3. Uruchom planowany perymetr w trybie dry run i obserwuj legalny ruch.
4. Każde żądanie wyjątku oceniaj według źródła, tożsamości, usługi, metody i celu.
5. Wymuś politykę dopiero po rozliczeniu potrzebnych przepływów i przygotowaniu obsługi blokad.
6. Monitoruj przenoszenie projektów oraz tworzenie nowych integracji i narzędzi agenta.

Google zaleca przy migracji z jawnie wymienionych projektów do folderu zachować stare wpisy co najmniej 48 godzin, aby hierarchia zasobów zdążyła się rozpropagować. To fakt z dokumentacji producenta. Sposób grupowania danych i wymagane akceptacje wyjątków należy już dopasować do ryzyka konkretnej organizacji.

Nie akceptuj automatycznie proponowanej poprawki

Sugestia wygenerowana przez Violation Analyzer może skrócić diagnozę blokady, ale nadal jest zmianą polityki bezpieczeństwa. Przed zatwierdzeniem sprawdź, czy proponowana reguła nie rozszerza dostępu na cały folder, metodę lub zbiór danych większy niż zamierzony. Porównaj ją z właścicielem procesu i przetestuj w dry run.

Najgorszy wzorzec operacyjny to powtarzające się poszerzanie perymetru tylko po to, aby agent „zaczął działać”. Blokada bywa sygnałem złej architektury integracji, zbyt szerokiego celu albo niekontrolowanego narzędzia. Czasem właściwą odpowiedzią będzie osobna usługa pośrednicząca, ograniczony zestaw danych lub asynchroniczny eksport zamiast nowej reguły.

Pytania dla firmy przed uruchomieniem agenta

• Czy właściciel biznesowy potrafi wskazać dane, których agent nie może nigdy opuścić?
• Czy tożsamość agenta jest osobna od konta człowieka i ma minimalne uprawnienia?
• Czy wiadomo, które działania są wykonywane automatycznie, a które wymagają zatwierdzenia?
• Czy logi łączą decyzję agenta z wywołaniem narzędzia i zmianą danych?
• Czy wyjątki od perymetru mają właściciela, uzasadnienie i termin przeglądu?
• Czy zespół umie bezpiecznie obsłużyć blokadę bez otwierania dostępu „na chwilę”?

Odpowiedzi łączą architekturę chmury z odpowiedzialnością ludzi. Fakty o nowych możliwościach i ich działaniu pochodzą z materiałów Google Cloud. Traktowanie hierarchii jako granicy danych, model oceny wyjątków i pytania kontrolne są rekomendacjami Breachroad. Więcej kontekstu daje nasz przewodnik po bezpieczeństwie AI i LLM w firmie, a zespoły biznesowe, cloud i security mogą przećwiczyć taki projekt podczas warsztatów z bezpiecznych wdrożeń AI.