Logo
AWS Bedrock AgentCore AI agents GenAI

AWS Bedrock AgentCore Identity: agent gets AccessDenied acting on behalf of a user

Fix AgentCore Identity AccessDenied errors when an agent acts on behalf of a user by diagnosing identity propagation, the OAuth 2LO/3LO token vault, workload identity, and least-privilege scope mismatches.

Jerzy Kopaczewski ·
Your agent on Amazon Bedrock AgentCore works with its own permissions but fails with AccessDenied the moment it acts on behalf of a user - calling a downstream API, reading a user's data, or invoking a tool through Gateway. The cause is almost always identity propagation: the agent is either using the wrong identity or presenting a token with the wrong scope. This runbook shows how to tell those apart and fix each.

This runbook covers AgentCore Identity access failures. For where Identity fits in the platform, see Amazon Bedrock AgentCore architecture and pricing. For designing an agent’s identity and least-privilege layer, book a consulting session.

Symptoms

The failure shows up in one of two shapes. Identify yours first, because the fix differs.

# 1. AWS-side authorization failure
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. Downstream (OAuth) authorization failure
HTTP 401 Unauthorized  /  HTTP 403 Forbidden
# ...returned by the third-party API the agent called via a vaulted token.

Observable impact:

  • The agent’s own actions succeed, but anything scoped to a specific user fails
  • One user works and another does not (per-user token or consent missing)
  • The same tool call succeeds when tested with the agent’s role directly, but fails inside a user session

Cause

AgentCore Identity separates the agent’s workload identity from the user identity it acts on behalf of, and access can break at either layer.

  1. Wrong identity on the AWS side. The agent’s execution role (workload identity) may lack the IAM permission for the action, or the design expects the call to carry the user’s scoped permissions but it is actually running with the agent’s broad role (or vice versa). An AccessDeniedException from an AWS API is an IAM problem, not an OAuth one.
  2. Missing or wrong-scope token on the downstream side. For third-party APIs, AgentCore Identity brokers OAuth tokens through a token vault, using two-legged (2LO, machine-to-machine) or three-legged (3LO, on-behalf-of-user) flows. A 401/403 from the downstream API means the vaulted token is missing for that user, the user has not completed the 3LO consent, or the token was issued with narrower scopes than the operation needs.

Common triggers:

  • Execution role missing the action - the workload identity’s IAM policy does not allow the AWS API being called
  • User never consented (3LO) - the on-behalf-of-user flow was never completed, so no user token exists in the vault
  • Scope too narrow - the OAuth token was granted fewer scopes than the operation requires
  • Identity confusion - the agent uses its own broad identity where it should propagate the user’s, defeating least-privilege and sometimes hitting a resource policy that only the user is allowed on

Fix

Step 1: Confirm which layer is denying access

Read the error class. An AccessDeniedException from an AWS service is layer 1 (IAM). A 401/403 from a third-party API reached via Gateway or a vaulted token is layer 2 (OAuth).

# Layer 1: what identity is actually making the AWS call?
# Log the caller identity from inside the agent to see which role is in effect.
aws sts get-caller-identity --region us-west-2

If the effective identity is the agent’s broad role where you intended the user’s scoped access (or the role simply lacks the action), go to Step 2. If it is a downstream 401/403, go to Step 3.

Step 2: Fix the AWS-side identity and permissions

Decide deliberately whether the call should run as the agent’s workload identity or propagate the user’s identity, then make the permissions match that decision.

  • If the action is legitimately the agent’s, add the specific action to the execution role - scoped to the exact resource ARN, not a wildcard
  • If the action must be scoped to the user, propagate the user’s identity rather than falling back to the agent’s broad role
  • Keep the execution role least-privilege: grant the single action on the single resource, and prefer separate narrow roles over one broad role shared across agents

For third-party APIs, the failure is in the vaulted token. Check, in order: does a token exist for this user, did the user complete consent, and does the token carry the required scopes.

  • 2LO (machine-to-machine): confirm the OAuth client credentials are registered in the token vault and the client is authorised for the scopes the operation needs
  • 3LO (on-behalf-of-user): confirm the user has completed the authorisation/consent flow so a per-user token exists; a user who never consented has no token and always gets 401
  • Scope: re-issue the token (or update the provider registration) with the scopes the operation requires; a token minted with read-only scope will 403 on a write

Step 4: Re-test the exact user path, not the agent path

A tool call that works with the agent’s role but fails in a user session is the tell-tale sign of identity confusion. Always reproduce the failure inside a real user session (correct actorId + user token), not with the agent’s own credentials, or you will “fix” the wrong layer.

Validation

Confirm the on-behalf-of-user path now succeeds end to end.

# Layer 1: the effective identity is the one you intended for this call
aws sts get-caller-identity --region us-west-2
# Expect the user-scoped role/identity where the design calls for it,
# and confirm the previously-denied action now returns success.

For the downstream path, invoke the tool inside a real user session (with the user’s vaulted token) and confirm the third-party API returns 200 rather than 401/403. Expected: the agent’s own actions still work, and the user-scoped action now succeeds for the same user that previously failed.