Logo
AWS Bedrock AgentCore agenci AI GenAI

AWS Bedrock AgentCore Identity: agent dostaje AccessDenied, działając w imieniu użytkownika

Napraw błędy AccessDenied w AgentCore Identity, gdy agent działa w imieniu użytkownika: propagacja tożsamości, sejf tokenów OAuth (2LO/3LO), workload identity oraz niedopasowanie zakresu least-privilege.

Jerzy Kopaczewski ·
Twój agent na Amazon Bedrock AgentCore działa z własnymi uprawnieniami, ale kończy się błędem AccessDenied, gdy tylko zaczyna działać w imieniu użytkownika - wołając API downstream, czytając dane użytkownika albo wywołując narzędzie przez Gateway. Przyczyną prawie zawsze jest propagacja tożsamości: agent używa albo złej tożsamości, albo przedstawia token z niewłaściwym zakresem. Ten runbook pokazuje, jak je rozróżnić i naprawić.

Ten runbook dotyczy błędów dostępu AgentCore Identity. Gdzie Identity mieści się w platformie, opisaliśmy w artykule Amazon Bedrock AgentCore: architektura i cennik. W sprawie projektu warstwy tożsamości i least-privilege agenta umów konsultację.

Objawy

Błąd przyjmuje jedną z dwóch postaci. Najpierw ustal, którą, bo sposób rozwiązania się różni.

# 1. Odmowa autoryzacji po stronie AWS
An error occurred (AccessDeniedException) when calling the <Operation>
operation: User: arn:aws:sts::...:assumed-role/... is not authorized to
perform: <action> on resource: <arn>

# 2. Odmowa autoryzacji downstream (OAuth)
HTTP 401 Unauthorized  /  HTTP 403 Forbidden
# ...zwrócone przez zewnętrzne API, które agent wywołał tokenem z sejfu.

Widoczny wpływ:

  • Własne akcje agenta się udają, ale wykonane przez konkretnego użytkownika zawodzą
  • Jeden użytkownik działa, a inny nie (brak tokenu per użytkownik lub zgody)
  • To samo wywołanie narzędzia udaje się przy teście z rolą agenta, ale zawodzi wewnątrz sesji użytkownika

Przyczyna

AgentCore Identity oddziela workload identity agenta od tożsamości użytkownika, w imieniu którego agent działa, a dostęp może się załamać na którejkolwiek z tych warstw.

  1. Zła tożsamość po stronie AWS. Rola wykonawcza agenta (workload identity) może nie mieć uprawnienia IAM do akcji, albo projekt zakłada, że wywołanie niesie zakresowane uprawnienia użytkownika, a faktycznie działa z szeroką rolą agenta (lub odwrotnie). AccessDeniedException z API AWS to problem IAM, nie OAuth.
  2. Brak tokenu lub token o złym zakresie po stronie downstream. Dla zewnętrznych API AgentCore Identity pośredniczy w tokenach OAuth przez sejf tokenów (token vault), używając przepływów dwunożnych (2LO, maszyna-do-maszyny) lub trójnożnych (3LO, w imieniu użytkownika). 401/403 z API downstream oznacza, że token dla tego użytkownika nie istnieje, użytkownik nie ukończył zgody 3LO albo token wydano z węższymi zakresami niż wymaga operacja.

Częste przyczyny:

  • Rola wykonawcza bez akcji - polityka IAM workload identity nie zezwala na wołane API AWS
  • Użytkownik nigdy nie wyraził zgody (3LO) - przepływ w imieniu użytkownika nie został ukończony, więc w sejfie nie ma tokenu użytkownika
  • Zbyt wąski zakres - token OAuth nadano z mniejszą liczbą zakresów, niż wymaga operacja
  • Pomylenie tożsamości - agent używa własnej szerokiej tożsamości tam, gdzie powinien propagować tożsamość użytkownika, co niweczy least-privilege i czasem trafia na politykę zasobu, na której dozwolony jest tylko użytkownik

Naprawa

Krok 1: Ustal, która warstwa odmawia dostępu

Odczytaj klasę błędu. AccessDeniedException z usługi AWS to warstwa 1 (IAM). 401/403 z zewnętrznego API osiągniętego przez Gateway lub token z sejfu to warstwa 2 (OAuth).

# Warstwa 1: jaka tożsamość faktycznie wykonuje wywołanie AWS?
# Zaloguj tożsamość wołającego z wnętrza agenta, aby zobaczyć, która rola działa.
aws sts get-caller-identity --region us-west-2

Jeśli efektywna tożsamość to szeroka rola agenta tam, gdzie zamierzałeś zakresowany dostęp użytkownika (albo rola po prostu nie ma akcji), przejdź do kroku 2. Jeśli to downstream 401/403, przejdź do kroku 3.

Krok 2: Napraw tożsamość i uprawnienia po stronie AWS

Zdecyduj świadomie, czy wywołanie ma działać jako workload identity agenta, czy propagować tożsamość użytkownika, a potem dopasuj uprawnienia do tej decyzji.

  • Jeśli akcja jest zasadnie akcją agenta, dodaj konkretną akcję do roli wykonawczej - zakresowaną do dokładnego ARN zasobu, nie do wildcardu
  • Jeśli akcja musi być zakresowana do użytkownika, propaguj tożsamość użytkownika zamiast wracać do szerokiej roli agenta
  • Utrzymuj rolę wykonawczą w least-privilege: nadaj pojedynczą akcję na pojedynczym zasobie i preferuj osobne wąskie role zamiast jednej szerokiej współdzielonej między agentami

Krok 3: Napraw token OAuth downstream (sejf, zgoda, zakres)

Dla zewnętrznych API błąd tkwi w tokenie z sejfu. Sprawdź po kolei: czy token dla tego użytkownika istnieje, czy użytkownik ukończył zgodę i czy token niesie wymagane zakresy.

  • 2LO (maszyna-do-maszyny): potwierdź, że dane klienta OAuth są zarejestrowane w sejfie tokenów, a klient jest autoryzowany do zadań, których wymaga operacja
  • 3LO (w imieniu użytkownika): potwierdź, że użytkownik ukończył przepływ autoryzacji/zgody, więc istnieje token per użytkownik; użytkownik, który nigdy nie wyraził zgody, nie ma tokenu i zawsze dostaje 401
  • Zakres: wydaj token ponownie (lub zaktualizuj rejestrację dostawcy) z zakresami wymaganymi przez operację; token wydany z zakresem tylko do odczytu zwróci 403 przy zapisie

Krok 4: Przetestuj dokładnie ścieżkę użytkownika, nie ścieżkę agenta

Wywołanie narzędzia, które działa z rolą agenta, ale zawodzi w sesji użytkownika, to charakterystyczny objaw pomylenia tożsamości. Zawsze odtwarzaj błąd wewnątrz prawdziwej sesji użytkownika (poprawny actorId + token użytkownika), a nie z poświadczeniami samego agenta, bo inaczej “naprawisz” niewłaściwą warstwę.

Weryfikacja

Potwierdź, że ścieżka w imieniu użytkownika udaje się teraz od początku do końca.

# Warstwa 1: efektywna tożsamość to ta, którą zamierzałeś dla tego wywołania
aws sts get-caller-identity --region us-west-2
# Oczekuj roli/tożsamości zakresowanej do użytkownika tam, gdzie wymaga tego projekt,
# i potwierdź, że wcześniej odrzucana akcja zwraca teraz sukces.

Dla ścieżki downstream wywołaj narzędzie wewnątrz prawdziwej sesji użytkownika (z tokenem użytkownika z sejfu) i potwierdź, że zewnętrzne API zwraca 200 zamiast 401/403. Oczekiwane: własne akcje agenta nadal działają, a akcja zakresowana do użytkownika udaje się teraz dla tego samego użytkownika, który wcześniej zawodził.

Powiązane