Databricks: niewinny, dopóki połączona polityka nie zablokuje ryzyka agenta w punkcie połączenia

Databricks opublikował nowy wzorzec bezpieczeństwa Omnigent, który blokuje agenta dopiero wtedy, gdy trzy pojedynczo zwyczajne możliwości tworzą niebezpieczny łańcuch. Podejście Databricks „niewinny, dopóki nie zostanie połączony” koncentruje się na chwili, gdy prywatne dane, niezaufana treść i komunikacja zewnętrzna stają się dostępne w ramach jednej sesji.

To połączenie jest znane jako śmiercionośna trifecta. Agent może bezpiecznie odczytać wewnętrzny plik, przeanalizować publiczną stronę internetową lub wysłać wiadomość, gdy każde z tych działań występuje osobno. Gdy jednak wszystkie trzy możliwości znajdą się na jednej ścieżce wykonania, wstrzyknięta instrukcja może zamienić legalny dostęp w kradzież danych.

Istotna zmiana nie polega na kolejnym ostrzeżeniu przed prompt injection. Databricks przenosi decyzję o egzekwowaniu zasad poza model, do Omnigent — swojego otwartoźródłowego meta-harnessu do uruchamiania agentów i zarządzania nimi. Warstwa polityk pamięta, z czym zetknęła się sesja, a następnie zmienia sposób traktowania późniejszych działań.

Statyczne uprawnienia pytają, czy agent może wywołać narzędzie. Polityki kontekstowe pytają również, co wydarzyło się przed tym wywołaniem. Ta różnica wywiera presję na zespoły korzystające z szerokiego, trwałego dostępu do narzędzi za pośrednictwem agentów programistycznych, agentów przeglądarkowych i integracji Model Context Protocol.

Co Databricks zmienił w Omnigent

Databricks traktuje historię agenta jako część jego efektywnego zestawu uprawnień.

Firmowe studium przypadku dotyczące bezpieczeństwa rozwija serię wpisów o politykach kontekstowych w Omnigent. Wcześniejsze przykłady koncentrowały się na stanie sesji, atakach rozwijających się powoli oraz autoryzacji powiązanej z pierwotną intencją użytkownika.

Najnowszy przykład stosuje ten model do śmiercionośnej trifecty. Badacz bezpieczeństwa Simon Willison zdefiniował ten wzorzec w czerwcu 2025 roku jako dostęp do prywatnych danych, kontakt z niezaufaną treścią oraz zewnętrzny kanał komunikacji. Jego model zagrożeń ostrzega, że połączenie wszystkich trzech elementów daje wstrzykniętym instrukcjom drogę do kradzieży informacji.

Omnigent znajduje się ponad agent harness, czyli środowiskiem uruchomieniowym zarządzającym modelem, narzędziami i pętlą wykonania. Projekt obsługuje uznane środowiska agentów programistycznych oraz niestandardowych agentów, umożliwiając wspólnej warstwie polityk obserwowanie ich aktywności.

To położenie ma znaczenie, ponieważ polityka nie potrzebuje, by model rozpoznawał każdą złośliwą frazę. Może regulować użycie narzędzi na podstawie faktów zapisanych podczas sesji.

Rozważmy agenta, któremu zlecono przejrzenie wewnętrznego dokumentu produktu. Odczytanie tego dokumentu jest oczekiwane. Wysłanie zatwierdzonego podsumowania na firmowy kanał również może być oczekiwane.

Załóżmy teraz, że agent odwiedza publiczne zgłoszenie, stronę internetową lub repozytorium zawierające ukryte instrukcje. Późniejsze żądanie wychodzące ma inne znaczenie dla bezpieczeństwa, ponieważ sesja przekroczyła kolejną granicę zaufania.

Tradycyjna lista dozwolonych operacji widzi te same zatwierdzone narzędzia przez cały proces. Polityka kontekstowa widzi sekwencję, której ryzyko zmieniało się w czasie.

Polityki Omnigent mogą zwrócić decyzję allow, ask lub deny. Allow zezwala na działanie, ask przekierowuje je do człowieka, a deny je blokuje. Odpowiedź może więc stawać się bardziej restrykcyjna, w miarę jak sesja gromadzi dostęp do wrażliwych danych lub ryzykowne zdarzenia.

Ten model egzekwowania zasad nie wymaga, by każde źródło, narzędzie lub działanie było samo w sobie niebezpieczne. Zamiast tego polityka obserwuje kombinacje, które tworzą niebezpieczną ścieżkę danych.

Databricks oferuje także Omnigent jako zarządzaną betę połączoną z tożsamością obszaru roboczego i usługami modeli. Jego zarządzane wdrożenie obsługuje obecnie wbudowane moduły obsługi polityk kontekstowych, podczas gdy dowolne niestandardowe funkcje polityk pozostają tam niedostępne.

To ograniczenie oddziela otwartoźródłowy projekt od produktu zarządzanego. Zespoły oceniające to ogłoszenie muszą rozróżniać zademonstrowany wzorzec polityki od mechanizmów kontroli dostępnych w wybranym wdrożeniu.

Mimo to centralna zmiana jest jasna. Autoryzacja agentów staje się zależna od sesji, zamiast być stała w momencie logowania lub rejestracji narzędzia.

Dlaczego podejście Databricks „niewinny, dopóki nie zostanie połączony” zmienia granicę bezpieczeństwa

Ryzykownym obiektem nie jest już pojedyncze wywołanie narzędzia, lecz ścieżka łącząca kilka dozwolonych wywołań.

Tradycyjna kontrola dostępu ocenia tożsamości, zasoby i działania. Konto usługi może odczytać jedną bazę danych, zapisać dane w jednym bucketcie lub wywołać jedno API. Te reguły pozostają konieczne, ponieważ agenci nadal działają za pośrednictwem zwykłych poświadczeń.

Nie są jednak wystarczające, gdy niezaufany język wpływa na sposób wykorzystania tych poświadczeń. Atakujący może nigdy nie potrzebować ukraść tokena ani wykorzystać kodu aplikacji. Wystarczy, że złośliwa treść dotrze do modelu, który może uzyskać dostęp do danych i działać na zewnątrz.

Pierwszym elementem są prywatne dane. Ta kategoria obejmuje wewnętrzne dokumenty, kod źródłowy, poświadczenia, dane klientów, e-maile, wyniki z baz danych oraz wszelkie informacje poza zakresem uprawnień atakującego.

Drugim elementem jest niezaufana treść. Strona internetowa, zgłoszenie wsparcia, pull request, e-mail, współdzielony plik, odpowiedź narzędzia lub obraz mogą zawierać instrukcje kontrolowane przez osobę spoza granicy zaufania agenta.

Trzecim elementem jest komunikacja zewnętrzna. E-mail i żądania HTTP są oczywistymi przykładami, lecz ta kategoria jest szersza. Opublikowanie komentarza, wypchnięcie kodu, załadowanie zdalnego zasobu lub zapis w systemie współdzielonym mogą utworzyć kanał wychodzący.

Żadna z tych możliwości nie jest niezwykła. To właśnie ich użyteczność sprawia, że połączenie tak często pojawia się w projektach agentów.

Agent badawczy potrzebuje źródeł zewnętrznych i wewnętrznego kontekstu. Agent programistyczny może odczytać prywatne repozytorium, konsultować publiczną dokumentację i wypchnąć gałąź. Asystent e-mailowy odczytuje niezaufane wiadomości, przeszukuje prywatną korespondencję i wysyła odpowiedzi.

Trwałe usunięcie którejkolwiek możliwości może znacznie ograniczyć użyteczność agenta. Ciągłe prośby o zatwierdzenie tworzą inny problem, ponieważ użytkownicy mogą przywyknąć do akceptowania rutynowych żądań.

Podejście Databricks „niewinny, dopóki nie zostanie połączony” oferuje inną opcję. Pozwalać na operacje niskiego ryzyka, lecz eskalować sprawę, gdy stan sesji domyka zabronioną kombinację.

Przenosi to granicę bezpieczeństwa z pojedynczego konektora na cały proces. Przeglądarka nie jest po prostu zaufana ani niezaufana. Jej znaczenie zależy od tego, czy ta sama sesja ma również wrażliwe informacje i drogę wyjścia.

Model ten przypomina kontrolę przepływu informacji, w której system śledzi, jak dane przemieszczają się między poziomami zaufania. Gdy poufne informacje trafią do kontekstu, późniejsze zapisy do mniej chronionego miejsca docelowego są traktowane bardziej restrykcyjnie.

Opublikowany katalog polityk Omnigent zawiera już powiązany mechanizm kontroli Google Drive. Gdy sesja odczyta zadeklarowany plik poufny, polityka może zapobiec zapisom poza zbiorem poufnym.

Katalog obejmuje również politykę oceny ryzyka. Gromadzi ona punkty z wywołań narzędzi i etykiet danych wrażliwych, a następnie eskaluje chronione narzędzia po osiągnięciu skonfigurowanego progu.

Te przykłady pokazują, dlaczego stan jest kluczowy. Żądanie zapisu nie zmienia swojego kształtu API po tym, jak agent odczyta wrażliwy dokument. Jego znaczenie zmienia się z powodu historii sesji.

Ta sama zasada dotyczy śmiercionośnej trifecty. Polityka szuka niebezpiecznej kompozycji, a nie operacji zakazanej w każdych okolicznościach.

To rozróżnienie powinno interesować zespoły platformowe bardziej niż kolejny filtr promptów. Filtry próbują zdecydować, czy tekst wygląda na złośliwy. Egzekwowanie kontekstowe może nadal zablokować niebezpieczne działanie, gdy model lub filtr nie rozpozna wstrzyknięcia.

Statyczne uprawnienia tracą sekwencję

Statyczna lista dozwolonych operacji może opisać dostępne możliwości, ale nie potrafi wyjaśnić, jak agent doszedł do danego działania.

Załóżmy, że programista upoważnia agenta do odczytu prywatnego repozytorium, przeglądania dokumentacji i otwierania pull requestów. Każde z tych uprawnień wspiera normalny proces programistyczny.

Atakujący umieszcza następnie instrukcję w zgłoszeniu, dokumencie zależności lub pobranej stronie internetowej. Instrukcja nakazuje agentowi zebrać sekret i umieścić go w opisie publicznego pull requesta.

Odczyt repozytorium jest dozwolony. Pobranie zasobu z internetu jest dozwolone. Otwarcie pull requesta jest dozwolone. Mechanizm kontroli, który ocenia każde żądanie niezależnie, może zatwierdzić cały łańcuch.

Filtr treści może wykryć instrukcję. Może też przeoczyć pośrednie żądanie, zakodowane dane, nieznany język lub payload zaprojektowany pod konkretny model docelowy.

Badania uzasadniają ostrożność wobec polegania wyłącznie na zachowaniu modelu. Benchmark WASP testował realistyczne ataki prompt injection przeciwko systemom agentów internetowych, wykorzystując kilka modeli i scaffoldów.

Badacze stwierdzili, że agenci zaczynali wykonywać instrukcje przeciwnika w od 16 do 86 procent przypadków w testowanych konfiguracjach. Kompleksowy sukces atakującego był niższy i wynosił od zera do 17 procent.

Ta różnica jest zachęcająca, ale nie uspokajająca. Obecni agenci często zawodzą, zanim ukończą złożony atak, lecz poprawa niezawodności agentów może również ułatwić dokończenie złośliwych procesów.

System nie powinien liczyć na to, że agent pomyli się we właściwym momencie. Potrzebuje mechanizmu kontroli, który pozostanie skuteczny, gdy modele będą lepiej wykonywać wieloetapowe zadania.

Statyczne uprawnienia mają też trudności z opóźnionymi atakami. Wstrzyknięta instrukcja może nie wywołać natychmiastowego działania wychodzącego. Może wpłynąć na późniejszy plan, delegowane zadanie, wygenerowany plik lub wywołanie narzędzia.

Polityka świadoma sesji może zachować istotne dla bezpieczeństwa fakty mimo tego opóźnienia. Nie potrzebuje, by każde podejrzane zdarzenie znajdowało się obok końcowego działania w aktywnym kontekście modelu.

Ta trwałość rozwiązuje praktyczną słabość długotrwałych agentów. Historia rozmowy może zostać skompresowana, podsumowana lub podzielona między workerów. Model może zapomnieć o wcześniejszym ograniczeniu, nawet gdy jego narzędzia i poświadczenia pozostają dostępne.

Stan polityki powinien więc znajdować się poza oknem tekstowym. Warstwa egzekwowania zasad potrzebuje własnego trwałego zapisu wrażliwych odczytów, niezaufanych danych wejściowych, miejsc docelowych, zatwierdzeń i zmian ryzyka.

Ta architektura ogranicza również zależność od samoopisu agenta. Pytanie modelu, czy zetknął się z niezaufaną treścią, jest słabsze niż zarejestrowanie, który konektor dostarczył tę treść.

Najsilniejsze sygnały pochodzą z infrastruktury. System dokumentów zna klasyfikację pliku. Brama sieciowa zna miejsce docelowe. Warstwa tożsamości zna użytkownika i obszar roboczy. Broker narzędzi wie, o jaką operację poproszono.

Omnigent może łączyć te sygnały, ponieważ otacza środowisko wykonawcze. Agent proponuje działanie, lecz polityka decyduje, czy to działanie pozostaje akceptowalne w zarejestrowanym kontekście.

To jest punkt nacisku dla konkurencyjnych platform agentowych. Zatwierdzenia na poziomie narzędzi łatwiej wyjaśnić i wdrożyć. Stają się mniej wiarygodne, gdy agenci prowadzą dłuższe sesje obejmujące więcej konektorów.

Dostawcy będą musieli pokazać, czy ich mechanizmy kontroli śledzą dane i przejścia zaufania między narzędziami. Długa lista uprawnień nie odpowiada już na centralne pytanie dotyczące bezpieczeństwa.

Polityki kontekstowe przerywają łańcuch, zanim dane opuszczą system

Użytecznym punktem kontroli jest przejście, które domyka ścieżkę ataku — zwykle wrażliwy odczyt lub działanie wychodzące.

Polityka kontekstowa zaczyna się od obserwowalnych zdarzeń. Mogą one obejmować wywołanie narzędzia, wynik działania narzędzia, etykietę danych, miejsce docelowe, żądanie modelu lub zgodę użytkownika.

Polityka przechowuje wybrane fakty w stanie sesji. Może odnotować, że agent wykorzystał niezaufaną treść, uzyskał dostęp do obiektu poufnego lub próbował komunikacji poza zatwierdzoną granicą.

Późniejsze zdarzenia są oceniane w odniesieniu do tego stanu. Jeśli kolejna operacja tworzy niedozwoloną kombinację, polityka może wymagać zgody lub odrzucić żądanie.

Kolejność może być różna. Agent może odczytać prywatne dane przed odwiedzeniem niezaufanej strony. Może też najpierw zetknąć się z wstrzykniętą treścią, a następnie zażądać dostępu do wewnętrznego pliku.

Solidna implementacja musi wykrywać obie ścieżki. Zagrożenie wynika z połączenia możliwości, a nie z jednego, stałego porządku zdarzeń.

Egzekwowanie zasad może również następować w więcej niż jednym punkcie. Polityka może zablokować odczyt wrażliwych danych po tym, jak do sesji trafi niezaufana treść. Inny projekt może zezwolić na analizę, ale uniemożliwić późniejszą komunikację zewnętrzną.

Blokowanie ruchu wychodzącego często pozwala zachować większą użyteczność lokalną. Agent może nadal czytać i tworzyć szkice, nie uzyskując jednocześnie kanału do ujawnienia informacji. Kontrole ruchu wychodzącego muszą jednak obejmować więcej niż oczywiste funkcje wysyłania.

Wygenerowany link może kodować dane. Zdalne żądanie obrazu może przekazywać parametry zapytania. Wysłanie zmian do kontroli wersji, komentarz do zgłoszenia, wywołanie analityczne lub zapis w udostępnionym dokumencie mogą przekroczyć granicę zaufania.

Istotny jest również kontekst miejsca docelowego. Wysłanie podsumowania do zatwierdzonego wewnętrznego kanału różni się od opublikowania go w publicznym repozytorium. Traktowanie wszystkich zapisów jednakowo powodowałoby niepotrzebne przerwy.

Zgoda człowieka jest wartościowa, gdy kontekst i miejsce docelowe są jasne. Przydatny komunikat powinien wyjaśniać, że sesja odczytała poufne dane, później wykorzystała niezaufaną treść, a teraz chce skontaktować się z określonym zewnętrznym punktem końcowym.

Ogólny komunikat „zezwól na to narzędzie” ukrywa powód eskalacji. Sprzyja zmęczeniu zatwierdzaniem, ponieważ osoba oceniająca musi ręcznie odtworzyć przebieg pracy.

Kategoryczna odmowa pasuje do kombinacji, których organizacja nigdy nie akceptuje. Na przykład polityka może uniemożliwić każdej sesji mającej kontakt z publiczną treścią wysyłanie informacji ze zbioru danych o ograniczonym dostępie poza jego wydzielony obszar.

Silnik polityk musi działać bezpiecznie, gdy brakuje wymaganego kontekstu. Brakująca etykieta danych, nieobsługiwane narzędzie lub niezaobserwowana ścieżka sieciowa mogą stworzyć martwy punkt.

Szersze podejście Omnigent łączy polityki z sandboxingiem. Sandbox ogranicza dostęp do systemu plików i sieci na granicy systemu operacyjnego, zmniejszając zakres zasobów, do których agent może dotrzeć, nawet jeśli model o nie poprosi.

Te warstwy służą różnym celom. Sandbox ogranicza surowe możliwości. Polityka kontekstowa dostosowuje uprawnienia na podstawie skumulowanego stanu sesji.

Żadna z nich nie zastępuje standardowych mechanizmów kontroli tożsamości, autoryzacji konektorów, rejestrowania zdarzeń ani zapobiegania utracie danych. Ogłoszenie jest najbardziej użyteczne, gdy interpretuje się je jako jedną warstwę egzekwowania zasad w ramach tego stosu.

Raport OWASP dotyczący bezpieczeństwa agentów wskazuje prompt injection jako jedną z głównych technik ataku na systemy AI. Jego szerszy przekaz jest taki, że bezpieczeństwo agentów wymaga kontroli wokół wykonywania działań, narzędzi, tożsamości i przepływu danych.

To wspiera kierunek architektoniczny Databricks. Model probabilistyczny może sugerować działanie, ale deterministyczna granica powinna decydować, czy działanie jest dozwolone.

Czego polityka Databricks nie rozstrzyga

Egzekwowanie kontekstowe zawęża ścieżkę ataku, ale jego niezawodność zależy od pełnej widoczności i wiarygodnej klasyfikacji.

Pierwszą nierozstrzygniętą kwestią jest zakres pokrycia. Polityka nie może zablokować kanału, którego nie obserwuje.

Agent może komunikować się przez konektor, polecenie powłoki, żądanie przeglądarki, osadzony zasób lub wygenerowany artefakt. Każda ścieżka, która może przenieść dane poza granicę, musi być ujęta w modelu polityki albo ograniczona gdzie indziej.

Drugą kwestią jest klasyfikacja. System musi wiedzieć, która treść jest niezaufana, a które dane są wrażliwe.

Proste reguły mogą klasyfikować publiczne strony internetowe jako niezaufane, a nazwane dokumenty jako poufne. Środowiska przedsiębiorstw obejmują trudniejsze przypadki, takie jak współdzielone dyski, konta wykonawców, skopiowany tekst, wygenerowane pliki oraz dane zestawione z kilku źródeł o niskiej wrażliwości.

Fałszywe wyniki negatywne pozostawiają niebezpieczną kombinację niewykrytą. Fałszywe wyniki pozytywne przerywają zwykłą pracę i mogą przyzwyczaić użytkowników do zatwierdzania ostrzeżeń bez ich sprawdzania.

Trzecią kwestią jest zakres stanu. Sesja jest wygodną jednostką, ale informacje mogą przemieszczać się między sesjami przez pliki, magazyny pamięci, pamięci podręczne, subagentów i kopiowane podsumowania.

Jeśli jeden worker odczyta poufne dane, a inny wyśle wynik, śledzenie per sesja może nie wykryć połączonego przepływu. Systemy wieloagentowe potrzebują reguł propagacji, które zachowują istotne etykiety podczas delegowania zadań.

Czwartą kwestią jest integralność polityki. Warstwa egzekwowania zasad, konfiguracja i strumień zdarzeń stają się infrastrukturą krytyczną dla bezpieczeństwa. Atakujący mogą celować w luki w politykach, nieprawidłowe metadane narzędzi, niejednoznaczne miejsca docelowe lub zachowanie typu fail-open.

Zespoły powinny testować rzeczywistą granicę polityki, a nie tylko model. Oceny odpornościowe muszą obejmować alternatywne drogi ruchu wychodzącego, opóźnione działania, transfery między agentami i niekompletne metadane.

Piątą kwestią jest użyteczność. Kontrola, która zbyt często prosi o zgodę, może odtworzyć słabość, którą miała rozwiązać.

Eskalacja oparta na ryzyku wymaga starannie dobranych progów i informacyjnych komunikatów. Zespoły bezpieczeństwa powinny mierzyć częstotliwość próśb o zgodę, dokładność odmów, wskaźniki nadpisywania decyzji oraz powody, dla których użytkownicy akceptują wyjątki.

Zarządzana wersja beta Omnigent wprowadza kolejne praktyczne ograniczenie. Databricks obecnie dokumentuje obsługę wbudowanych handlerów, a nie dowolnego niestandardowego kodu polityk, w środowisku zarządzanym.

Organizacje ze specjalistycznymi klasyfikacjami lub własnościowymi konektorami powinny sprawdzić, czy dostępne polityki udostępniają wystarczający kontekst. Elastyczność open source nie przekłada się automatycznie na równoważność w usłudze zarządzanej.

Nie ma również jeszcze podstaw, by traktować jedną demonstrację jako uniwersalne potwierdzenie skuteczności. Artykuł Databricks wyjaśnia wzorzec bezpieczeństwa i podejście implementacyjne. Nie dowodzi, że każda konfiguracja Omnigent blokuje każdą technikę prompt injection.

Właściwe twierdzenie jest węższe. Egzekwowanie zasad świadome sesji może przerwać ścieżkę lethal trifecta, nawet gdy każde pojedyncze narzędzie pozostaje uzasadnione.

To nadal ma znaczenie. Architektura bezpieczeństwa często odnosi sukces przez usunięcie jednego koniecznego warunku ataku, a nie przez uczenie aplikacji rozpoznawania każdej wiadomości atakującego.

Najsilniejsze wdrożenia połączą politykę kontekstową z ograniczonymi poświadczeniami, listami dozwolonych miejsc docelowych, sandboxingiem, dziennikami audytowymi i niezależnymi testami. Będą też traktować definicje polityk jako wersjonowany kod bezpieczeństwa.

Trzy sygnały pokażą, czy model się sprawdzi

Kolejny test pokaże, czy polityka kontekstowa stanie się mierzalną infrastrukturą, a nie tylko przekonującą demonstracją.

Pierwszym sygnałem będzie szersze pokrycie narzędzi i środowisk uruchomieniowych agentów. Databricks musi wykazać, że etykiety bezpieczeństwa i stan sesji przetrwają typowe przepływy pracy z udziałem przeglądarek, repozytoriów kodu, systemów dokumentów, powłok i delegowanych agentów.

Obsługa na liście funkcji nie wystarczy. Zespoły potrzebują dowodów, że równoważne działania otrzymują równoważne egzekwowanie zasad w różnych środowiskach uruchomieniowych i implementacjach konektorów.

Spójne pokrycie wzmocniłoby argument za wspólnym meta-harnessem. Istotne różnice między środowiskami wykonawczymi osłabiłyby obietnicę jednej warstwy nadzoru dla agentów.

Drugim sygnałem będzie ocena odpornościowa. Omnigent potrzebuje powtarzalnych testów próbujących opóźnionej eksfiltracji, pośredniego ruchu wychodzącego, transferu między sesjami i manipulacji metadanymi.

Przydatne wyniki powinny rozdzielać wykrycie, zgodę, odmowę i skuteczne przemieszczenie danych. Powinny też raportować ukończenie łagodnych zadań, ponieważ polityka blokująca każdy przepływ pracy jest bezpieczna, lecz bezużyteczna.

Publiczne zestawy testowe pozwoliłyby zespołom bezpieczeństwa odtwarzać wyniki względem własnej konfiguracji. Niezależna ocena miałaby większą wagę niż scenariusz wybrany przez dostawcę.

Trzecim sygnałem będzie wdrożenie operacyjne w zarządzanych środowiskach Databricks. Warto obserwować rozszerzone wsparcie polityk, bardziej przejrzystą telemetrię, mechanizmy administracyjne i udokumentowane integracje z klasyfikacjami danych przedsiębiorstwa.

Wdrożenie powinno przynosić mierzalne rezultaty. Zespoły muszą wiedzieć, jak często uruchamiają się polityki, które kombinacje możliwości powodują eskalację oraz czy osoby oceniające cofają czy zatwierdzają decyzję.

Te sygnały są istotne, ponieważ podstawowy problem bezpieczeństwa będzie narastał wraz z użytecznością agentów. Lepsze agenty będą wykonywać dłuższe zadania, korzystać z większej liczby narzędzi i przekraczać więcej granic zaufania bez stałego nadzoru.

Podejście Databricks „niewinny, dopóki nie zostanie połączony” oferuje wiarygodną zasadę projektową: zezwalać na użyteczne komponenty, jednocześnie blokując niebezpieczną kompozycję. Przenosi uwagę z pytania, czy model rozumie atak, na pytanie, czy otaczający system pozwala atakowi się zakończyć.

Deweloperzy powinni zmapować, które sesje mogą uzyskiwać dostęp do prywatnych danych, pobierać treści kontrolowane przez atakującego i komunikować się na zewnątrz. Nabywcy korporacyjni powinni pytać, czy platforma śledzi te warunki w czasie, między narzędziami i delegowanymi workerami.

Jeśli wszystkie trzy pozostają dostępne bez egzekwowania kontekstowego, dopracowany ekran zatwierdzania nie rozwiązuje problemu. Praktycznym kolejnym krokiem jest wskazanie, gdzie trzecia możliwość pojawia się w każdym przepływie pracy, a następnie umieszczenie na tej granicy testowalnej polityki.