W przykładzie AWS kontrola dostępu agenta AI odbywa się na kilku poziomach: Okta wydaje delegowany token ID-JAG, AgentCore Gateway go weryfikuje, Cedar ocenia dostęp agenta do narzędzi, a serwer MCP osobno sprawdza uprawnienia użytkownika. Każda warstwa kontroluje więc inny element wywołania.
Ograniczenie pojedynczego wywołania nie wystarczy, jeśli agent może połączyć wyniki kilku dozwolonych zapytań.
Jak Gateway, Cedar i MCP dzielą kontrolę dostępu?
W rozwiązaniu opisanym przez AWS agent przekazuje token ID-JAG do własnego Amazon Bedrock AgentCore Gateway. Gateway sprawdza wystawcę tokena, odbiorcę, dozwolonego klienta i zakresy, a następnie wymienia delegowane uprawnienie na token dla docelowej usługi. Zakresy skonfigurowane dla celu muszą odpowiadać zakresom ID-JAG; przykład AWS używa xaa:read i xaa:write.
Następnie Cedar ocenia, czy dany agent może wyświetlić narzędzie albo go użyć. W opisanej konfiguracji polityki zezwalające działają w trybie domyślnej odmowy: jeśli reguła nie przyznaje dostępu, wywołanie jest blokowane. Serwer MCP nadal sprawdza grupy użytkownika i przypisany mu zakres. Zgoda dla agenta nie zastępuje zatem kontroli uprawnień osoby, w której imieniu agent działa.
AWS opisuje osobny Gateway i dostawcę poświadczeń dla każdego agenta. W przykładzie drugi agent, działający w Amazon EKS, ma własną rejestrację Okta, a jego połączenie z zasobem dopuszcza tylko xaa:read.
W teście AWS Agent A wyświetlał sześć narzędzi, a Agent B cztery, ponieważ Cedar ukrył narzędzia zapisu tego drugiego agenta. Agent A nie mógł utworzyć zadania dla Alice ani Carol, ale utworzył je dla Boba. Agent B nie miał narzędzia do zapisu nawet dla Boba.
XAA i zgoda OAuth: kto przyznaje dostęp i co dzieje się po zawieszeniu?
Cross App Access (XAA) pasuje do celu, którego serwer autoryzacji akceptuje ID-JAG. W opisanym przez AWS modelu administrator Okta określa, który agent może działać w imieniu użytkowników; użytkownik nie widzi prośby o zgodę, a Okta ocenia politykę przy każdym żądaniu tokena. AWS podaje, że wydane tokeny ID-JAG wygasają po około pięciu minutach.
Dla aplikacji z własnym serwerem autoryzacji, takiej jak GitHub w przykładzie AWS, opisano osobną ścieżkę z indywidualną zgodą OAuth użytkownika. W teście Alice miała token wejściowy ważny przez godzinę i zapisaną zgodę. Zawieszenie jej konta w Okta nie unieważniło od razu tego tokena ani zgody, choć nowe logowanie zostało odrzucone. Po odwieszeniu dostęp wrócił bez ponownego wyrażania zgody. Odłączenie zgody sprawiło natomiast, że cel zgłaszał brak połączenia.
| Model dostępu | Kto przyznaje dostęp? | Czy użytkownik wyraża zgodę? | Wynik testu AWS po zawieszeniu lub odłączeniu |
| XAA dla celu akceptującego ID-JAG | Administrator Okta określa, który agent może działać w imieniu użytkowników; Okta sprawdza politykę przy żądaniu tokena. | Nie pojawia się prośba o zgodę. | Zawieszenie zatrzymało wydawanie kolejnych ID-JAG; wydane tokeny wygasały po około pięciu minutach. |
| Zgoda OAuth użytkownika, na przykład dla GitHub | Użytkownik łączy konto z aplikacją i udziela jej zgody. | Tak. | W teście zawieszenie Alice nie unieważniło od razu godzinnego tokena ani zapisanej zgody. Nowe logowanie odrzucono; odłączenie zgody uniemożliwiło połączenie z celem. |
To zachowanie dotyczy testu opisanego przez AWS, a wybór ścieżki zależy od tego, czy serwer autoryzacji konkretnej aplikacji akceptuje ID-JAG.
Co mówią pomiary AWS?
AWS podał medianę (p50) i 90. percentyl (p90) czasów z 24 godzin obserwacji Gateway A. Czas spanów autoryzacji wejściowej wynosił 34 ms przy p50 i 69 ms przy p90. Dla wywołania Policy.AuthorizeAction wartości wyniosły odpowiednio 47 i 56 ms. AWS podał też około 0,2 sekundy łącznie dla spanów tożsamości i polityki przy medianie; osobny span Gateway.TargetInvocation miał p50 wynoszące 5 565 ms i p90 wynoszące 6 273 ms.
Są to pomiary AWS z konkretnego wdrożenia testowego, nie uniwersalne czasy działania. Gateway i polityka to tylko część drogi: span wywołania celu obejmuje osobny etap przekazania żądania do serwera MCP.
Wdrożenie wymaga też uwagi przy konfiguracji narzędzi. AWS informuje, że w jego testach polityki odwołujące się do nazw narzędzi nie mogły zostać przypięte do celów z dynamicznie pobieraną listą narzędzi. Gateway stronicuje odpowiedzi tools/list według celu, więc klient musi odczytać kolejne strony, aby zobaczyć dalsze narzędzia. AWS określa swoje fragmenty jako koncepcyjne, nie jako kompletne rozwiązanie do wdrożenia, a przykładowy kod jako przeznaczony do użytku nieprodukcyjnego.
Gdy dozwolone wyniki można połączyć
Uczestnik dyskusji w r/LLMDevs przedstawił hipotetyczny przykład: jedno dozwolone narzędzie zwraca sumę wynagrodzeń w zespole, a drugie jego liczebność. Jeśli zespół liczy jedną osobę, połączenie tych wyników może ujawnić jej pensję, mimo że każde zapytanie osobno przeszło kontrolę.
To odrębna kwestia niż sprawdzanie, czy agent może wykonać pojedyncze wywołanie. Uczestnik sugeruje, by kontrolować łączne zapytanie w jednym narzędziu objętym polityką albo uniemożliwić łączenie wyników poza tym narzędziem. Przykład jest ilustracją zagrożenia, nie wynikiem testu AWS.
