Najważniejszym szczegółem nowego projektu TOLAP od AWS nie jest sam skrót. Kluczowe jest miejsce, w którym egzekwowane są reguły.

Bezpieczne narzędzie agenta AI filtruje dane z baz danych i API przez warstwę kontroli dostępu na poziomie obiektów, zanim trafią one do kontekstu agenta.

AWS Labs opublikowało TOLAP, czyli Tool-Object Level Access Protocol, jako otwartoźródłową warstwę bezpieczeństwa dla narzędzi agentów AI. Projekt ma rozstrzygać, jakie dane mogą opuścić narzędzie po jego wywołaniu przez agenta: które wiersze są widoczne, które pola należy ukryć lub zamaskować, jakie punkty końcowe są dozwolone, ile wyników można zwrócić oraz czy żądane działanie mieści się w celu delegowanych uprawnień. Pierwsze publiczne wydanie pokazuje, że bezpieczeństwo agentów odchodzi od prostego pytania: „czy ta tożsamość może wywołać to API?”, i zmierza ku trudniejszemu: „co dokładnie może ujawnić lub zmienić to konkretne wywołanie?”.

To rozróżnienie ma znaczenie dla zespołów budujących agentów nad bazami danych, wewnętrznymi API, bazami wiedzy, pamięcią obiektową i serwerami MCP. Zwykła kontrola uprawnień może autoryzować połączenie, a jednocześnie pozostawić narzędziu możliwość zwrócenia znacznie większej ilości danych, niż potrzebuje użytkownik lub dany proces. Propozycja TOLAP polega na umieszczeniu obudowy z polityką wokół funkcji, która faktycznie pobiera albo zmienia dane, a następnie egzekwowaniu tej polityki, zanim wynik trafi do kontekstu agenta.

Projekt nie zastępuje zarządzania tożsamością, kontroli sieciowej, uprawnień baz danych ani zatwierdzania przez człowieka. To węższy mechanizm, którego zadaniem jest zamknięcie luki między dostępem do narzędzia a ekspozycją obiektów danych.

Co wydało AWS

AWS Open Source opisuje TOLAP jako warstwę egzekwowania reguł w punkcie źródłowym. Repozytorium jest dostępne na licencji Apache 2.0 i zawiera schemat polityki, biblioteki egzekwowania dla .NET, Pythona i TypeScriptu, referencyjny serwer polityk, przykłady, dokumentację oraz integracje z popularnymi frameworkami agentów i narzędzi.

Centralny model ma charakter deklaratywny. Polityka może wskazywać dozwolone obiekty i działania, ukrywać wybrane pola, maskować wartości, filtrować wiersze, ograniczać prefiksy pamięci lub metody API, nakładać limity wyników i dołączać informacje audytowe. W przykładach użyto zbioru danych stylizowanego na dane medyczne: agent może mieć prawo do wyszukiwania kart pacjentów, ale nie do otrzymywania numerów Social Security; adresy e-mail mogą być zwracane jako skróty, a wiersze mogą być ograniczone do określonych regionów.

To coś innego niż przekazanie agentowi danych dostępowych do bazy z szerokim prawem odczytu i oczekiwanie, że model będzie zachowywał się odpowiedzialnie. W modelu TOLAP agent nadal może zbudować zapytanie za pośrednictwem narzędzia, lecz obudowa nakłada skuteczną politykę na wynik. Dane odrzucone przez politykę są usuwane, zanim staną się częścią kontekstu modelu.

AWS podaje, że zestawy SDK korzystają ze wspólnego, wersjonowanego schematu polityki i wspólnych zestawów testów, aby implementacje zachowywały się tak samo w różnych językach. Repozytorium obejmuje również integracje z SDK MCP, Strands, LangChain, LangChain.js, Vercel AI SDK, Mastra, OpenAI Agents, Pydantic AI, Semantic Kernel i Bedrock Agents. Integracje te nie zmieniają TOLAP w serwer MCP. Projekt opakowuje funkcję używaną przez warstwę narzędzi, natomiast aplikacja nadal odpowiada za pobranie danych.

Do zastosowań produkcyjnych repozytorium zawiera serwer polityk oparty na PostgreSQL, niezmienne wersje polityk, operacje publikowania i wycofywania, ślad audytowy, administrację uwierzytelnianą przez Cognito oraz rotację kluczy podpisujących z okresem nakładania się kluczy. Są to elementy infrastruktury referencyjnej, a nie dowód, że każda organizacja powinna wdrożyć cały ten stos.

Dlaczego zwykła autoryzacja narzędzia nie wystarcza

Większość architektur agentowych ma już kilka warstw uprawnień. Użytkownik uwierzytelnia się w aplikacji. Aplikacja przekazuje agentowi tożsamość usługi albo delegowany token. Brama sprawdza token. Narzędzie wywołuje bazę danych lub API. Każda z tych warstw jest cenna, ale żadna nie odpowiada automatycznie na pytanie dotyczące poziomu obiektu.

Wyobraźmy sobie wewnętrznego agenta wsparcia z uprawnieniem do odpytywania tabeli klientów. Kontrola roli może prawidłowo stwierdzić, że aplikacja wsparcia może wywołać narzędzie wyszukiwania klientów. Nie musi jednak rozstrzygać:

  • których klientów może zobaczyć pracownik składający żądanie;
  • które kolumny należy pominąć;
  • czy wynik może obejmować klientów spoza regionu pracownika;
  • czy adres można zwrócić w pełnej postaci;
  • czy zapytanie może zwrócić 5000 wierszy;
  • czy operacja odczytu nie stała się po cichu operacją eksportu.

Brama może autoryzować punkt końcowy. Baza danych może egzekwować nadania. Aplikacja może filtrować odpowiedzi. Jeśli jednak decyzje są rozproszone po niestandardowym kodzie, skuteczna granica staje się trudna do zinwentaryzowania i przetestowania. Im więcej frameworków, konektorów i środowisk agentowych dodaje organizacja, tym łatwiej o ścieżkę, na której zabraknie jednej kontroli.

Argument architektoniczny TOLAP brzmi następująco: narzędzie jest ostatnim wiarygodnym miejscem, w którym można zatrzymać dane przed wejściem do kontekstu agenta. Instrukcje w promptach nie są granicą bezpieczeństwa. Model może źle zrozumieć regułę, wykonać złośliwą instrukcję osadzoną w pobranej treści albo połączyć osobno dozwolone wyniki w ujawnienie, którego projektant nie przewidział. Jeśli wrażliwe pole nigdy nie przejdzie przez obudowę, model nie może odzyskać go z własnego kontekstu.

Nie oznacza to, że narzędzie automatycznie staje się godne zaufania. Obudowa musi być jedyną drogą do chronionego źródła, a aplikacja musi uniemożliwiać alternatywnym danym uwierzytelniającym lub nieopakowanemu kodowi dostęp do tych samych danych. Egzekwowanie w punkcie źródłowym ma sens tylko wtedy, gdy ten punkt rzeczywiście jest kontrolowany.

Wydanie obejmuje więcej niż filtrowanie wierszy i pól

Kontrole na poziomie obiektów w pierwszej wersji są najbardziej zrozumiałą częścią projektu. Nowsze materiały opisują również kontrolę celu i kolejności działań agenta.

Polityki TOLAP mogą zawierać profile celu, które zawężają politykę stosowaną do żądania. Walidacja działania sprawdza następnie, czy wywołanie narzędzia należy do dozwolonego zestawu działań. Jeśli występuje działanie zabronione, wywołanie zostaje odrzucone; jeśli istnieje lista dozwolonych działań, a żądane działanie nie znajduje się na tej liście, ono również zostaje odrzucone.

Projekt opisuje także walidację łańcucha delegowania. Jest to istotne, gdy jeden agent wywołuje innego agenta albo gdy przepływ pracy przekazuje uprawnienia przez kilka usług. Komponent niższego poziomu nie powinien po cichu otrzymać szerszych uprawnień niż te przyznane wyżej. W dobrze zaprojektowanym łańcuchu każda delegacja zachowuje zakres albo go zawęża, a wynik decyzji pozostaje możliwy do przypisania pierwotnej władzy.

Kolejność ma znaczenie. Filtrowanie celu wybiera właściwą politykę. Walidacja działania sprawdza, o co narzędzie jest proszone. Egzekwowanie na poziomie obiektu kontroluje następnie, jakie dane można zwrócić lub zmienić. Każdy etap opisano jako działający w trybie fail-closed i możliwy do niezależnego testowania.

AWS dokumentuje również opcjonalną warstwę zgodności semantycznej z użyciem sędziego LLM. To najbardziej delikatny element projektu. Reguły deterministyczne mogą sprawdzić tabelę, pole, filtr wierszy, działanie lub punkt końcowy. Nie zawsze potrafią jednak ustalić, czy sekwencja pojedynczo poprawnych zapytań pozostaje zgodna z zadeklarowanym celem. Sędzia może przeanalizować opis celu, bieżące wywołanie narzędzia i okno niedawnej historii, a następnie zezwolić, zablokować albo eskalować sprawę zgodnie z progami pewności.

Projekt umieszcza sędziego po egzekwowaniu deterministycznym, a nie przed nim. Taka kolejność jest rozsądna: model nie powinien móc przekonać drugiego modelu do ujawnienia pola, którego strukturalna polityka już zabroniła. Sędzia jest opcjonalny i domyślnie wyłączony, a prompt kontroluje administrator i agent nie może go edytować.

Organizacje powinny traktować sędziego jako dodatkowy sygnał, a nie zamiennik deterministycznej kontroli dostępu. Jego wynik jest probabilistyczny, konfigurację trzeba oceniać, a niejednoznaczne przypadki powinny mieć wyraźną ścieżkę przeglądu. Najmocniejsza granica w tym wydaniu pozostaje zwyczajna: nie zwracać danych, których zabrania polityka.

Co to zmienia dla zespołów MCP i narzędzi agentowych

Praktyczny wpływ będzie największy w zespołach, które dodają narzędzia szybciej, niż projektują dla nich autoryzację.

MCP ułatwia wystawianie możliwości modelowi. Pytanie bezpieczeństwa nie brzmi wyłącznie, czy serwer wymaga uwierzytelnienia. Trzeba również sprawdzić, czy każde narzędzie ma wąski kontrakt danych i czy serwer filtruje wynik, zanim zobaczą go klient lub model. Narzędzie zwracające nieograniczony wynik z bazy pozostaje szerokie, nawet gdy połączenie MCP korzysta z krótkotrwałego tokenu.

Ten sam problem występuje poza MCP. Narzędzie OpenAI Agents, retriever LangChain, grupa działań Bedrock Agent, punkt końcowy function calling czy niestandardowa obudowa w Pythonie mogą stać się przypadkową granicą ujawnienia. Podejście TOLAP celowo znajduje się poniżej frameworka modelu: politykę należy umieścić wokół funkcji rozmawiającej ze źródłem, a następnie utrzymać ten sam model egzekwowania po zmianie warstwy orkiestracji.

Taki podział przynosi korzyść operacyjną. Zespoły mogą testować zachowanie bezpieczeństwa bez testowania tego, czy model potrafi wykonywać instrukcje. Test polityki może sprawdzać, że zabroniona kolumna jest nieobecna, filtr wierszy został zastosowany, limit wyników jest respektowany, a zabronione działanie kończy się niepowodzeniem. To zwykłe testy programistyczne i bezpieczeństwa. Model można następnie oceniać pod kątem użyteczności na ograniczonym zbiorze wyników.

Istnieje jednak kompromis. Obudowa na granicy narzędzia widzi to, co narzędzie zwraca, ale może nie rozumieć każdego znaczenia biznesowego danych. Polityka może ukryć pole i odfiltrować region. Trudniej może być wyrazić regułę, że „tych pięć dozwolonych zapytań razem tworzy zabronione wnioskowanie”, bez przechowywania historii albo dodania semantycznego etapu oceny. Dlatego deterministyczne i semantyczne warstwy wydania należy traktować jako uzupełniające się, a nie wymienne.

Granice, za które nadal odpowiada aplikacja

TOLAP nie eliminuje potrzeby stosowania konwencjonalnych kontroli bezpieczeństwa.

Tożsamość nadal ma znaczenie. Polityka potrzebuje wiarygodnego podmiotu, grupy, roli, konta usługi albo delegowanego podmiotu. Jeśli każde żądanie przychodzi z tej samej, nadmiernie uprzywilejowanej tożsamości usługi, reguły na poziomie obiektu mogą mieć zbyt mało kontekstu, by podejmować sensowne decyzje.

Projektowanie poświadczeń również ma znaczenie. Opakowane narzędzie nie powinno mieć poświadczeń pozwalających ominąć obudowę i uzyskać bezpośredni dostęp do źródła. Krótkotrwałe poświadczenia, ograniczone role, restrykcje sieciowe, rotacja sekretów oraz osobne tożsamości dla środowisk programistycznych i produkcyjnych pozostają podstawowymi kontrolami.

Znaczenie ma także system źródłowy. Bezpieczeństwo na poziomie wierszy w bazie danych, autoryzacja API, polityki pamięci oraz reguły biznesowe aplikacji powinny nadal egzekwować własne granice. TOLAP może ograniczyć to, co otrzymuje agent, ale nie powinien być jedyną ochroną krytycznej bazy ani nieodwracalnej operacji.

Projektowanie zatwierdzeń również pozostaje ważne. Ukrycie pól nie czyni destrukcyjnego działania bezpiecznym. Usunięcie rekordu, zmiana płatności, rotacja klucza lub wdrożenie kodu może wymagać akceptacji człowieka, zasady dwóch osób, podglądu transakcji albo odwracalnego przepływu pracy. Walidacja działania w TOLAP może odrzucać wywołania spoza zakresu, lecz dozwolone działanie nadal może być zbyt konsekwentne, by uruchamiać je automatycznie.

Obserwowalność nadal ma znaczenie. Użyteczne zdarzenie audytowe to nie tylko „wywołano narzędzie”. Powinno łączyć człowieka lub usługę delegującą uprawnienia, tożsamość agenta, cel, narzędzie, skuteczną wersję polityki, zakres danych, rozmiar wyniku, decyzję i ewentualne zatwierdzenie. Bez tego kontekstu osoby reagujące na incydent mogą wiedzieć, że zapytanie zostało wykonane, ale nie dlaczego na to pozwolono.

Na koniec pozostaje zarządzanie. Polityki potrzebują właścicieli, dat wygaśnięcia, wyzwalaczy przeglądu, kontroli wersji, wycofywania i testów uruchamianych po zmianie konektora. Obudowa polityki może stworzyć złudne poczucie bezpieczeństwa, jeśli nikt nie sprawdza, czy narzędzie źródłowe zyskało nowy parametr albo nową drogę omijającą funkcję egzekwowania.

Rozsądny plan oceny

Nie trzeba przyjmować całego stosu TOLAP, aby wyciągnąć wnioski z tego wydania. Opisana konstrukcja sugeruje praktyczny przegląd istniejących narzędzi agentowych.

Zacznij od zinwentaryzowania rzeczywistych ścieżek danych. Dla każdego narzędzia agenta wskaż funkcję, która odczytuje lub zmienia źródło, używane poświadczenie, alternatywne drogi dostępu oraz moment, w którym wynik staje się widoczny dla modelu. Narysuj ścieżkę od żądania użytkownika przez wywołanie narzędzia do odpowiedzi źródła. Jeśli zespół nie potrafi wskazać punktu egzekwowania, prawdopodobnie nie potrafi też udowodnić, gdzie znajduje się granica.

Następnie oddziel autoryzację możliwości od autoryzacji danych. „Agent może używać wyszukiwania klientów” to stwierdzenie o możliwości. „Agent może widzieć klientów przypisanych do tego pracownika, bez daty urodzenia i z zamaskowanym adresem e-mail” to polityka danych. Oba stwierdzenia powinny mieć postać możliwą do przetestowania.

Potem utwórz testy negatywne. Sprawdź, czy obudowa blokuje zabronioną tabelę, usuwa ograniczone pole, filtruje wiersze spoza zakresu, maskuje wrażliwe wartości, ogranicza niezwykle szerokie odpowiedzi, odrzuca niezatwierdzone działanie i przechodzi w tryb fail-closed, gdy rozwiązanie polityki lub podpisywanie kończy się błędem. Testuj bezpośredni dostęp z użyciem poświadczenia narzędzia oraz dostęp przez zwykłą ścieżkę agenta.

Testuj kompozycję, a nie tylko pojedyncze wywołania. Model może uzyskać wrażliwą informację za pomocą kilku pozornie nieszkodliwych zapytań albo przekazać uprawnienia od jednego agenta do drugiego. Rejestruj i przeglądaj sekwencje, zmiany delegowania oraz powtarzające się eksporty. Jeśli znaczenie ma cel biznesowy, określ, kiedy sekwencja wymaga przeglądu człowieka, zamiast próbować zakodować każdą interpretację w promptcie.

Na koniec zmierz obciążenie deweloperów. Warstwa bezpieczeństwa zbyt trudna do integracji będzie omijana. Właściwe pytanie nie brzmi, czy obudowa potrafi wyrazić każdą możliwą politykę. Chodzi o to, czy organizacja może uczynić bezpieczną ścieżkę najłatwiejszą dla każdego obsługiwanego konektora i frameworka.

Dlaczego warto obserwować to wydanie

TOLAP jest wczesną otwartoźródłową odpowiedzią na problem, który wiele wdrożeń agentów rozwiązuje obecnie za pomocą rozproszonego middleware'u i konwencji. Najbardziej użyteczny wkład projektu ma charakter pojęciowy: dostęp do narzędzia nie jest tym samym co autoryzacja dostępu do każdego obiektu, do którego narzędzie może dotrzeć.

To rozróżnienie staje się pilniejsze, gdy agenci przechodzą od konwersacyjnego wyszukiwania do przepływów pracy, które odpytują systemy produkcyjne, podsumowują prywatne rekordy, wywołują API i delegują zadania innym agentom. Istniejące platformy tożsamości nadal są potrzebne, a dostawcy dodają tożsamości agentów, dostęp warunkowy i kontrole polityk. Tożsamość w zewnętrznej warstwie nie ogranicza jednak automatycznie kształtu wyniku w warstwie wewnętrznej.

Projekt należy oceniać jako infrastrukturę, a nie jako gotową odznakę bezpieczeństwa. Przeczytaj model zagrożeń. Sprawdź, czy każda ścieżka do źródła jest opakowana. Przejrzyj schemat polityki i zachowanie w sytuacji błędu. Uruchom przykłady na reprezentatywnych danych. Zweryfikuj, czy licencja, zależności, obsługiwane środowiska uruchomieniowe i model operacyjny pasują do organizacji. Opcjonalnego sędziego LLM traktuj jako pomoc przy przeglądzie, która wymaga własnej walidacji.

Bezpośrednia rada dla zespołów platformowych i bezpieczeństwa jest prosta: dla każdego narzędzia agenta dotykającego wrażliwych danych określ najmniejszy użyteczny wynik, zanim zobaczy go model. Egzekwuj tę definicję w kodzie na granicy danych, nie pozwól, aby poświadczenie ją omijało, i zapisuj, która polityka doprowadziła do decyzji. Wydanie TOLAP od AWS daje zespołom konkretny projekt otwartoźródłowy do przeanalizowania, a przy okazji ułatwia rozmowę o tej architekturze.

To jest zasadnicza zmiana: granicą bezpieczeństwa agenta AI nie jest wyłącznie tożsamość rozpoczynająca żądanie. Jest nią również funkcja decydująca, co może przedostać się do kontekstu agenta.

Źródła