# Why might my Bedrock request be failing with an AccessDenied or unauthorized error, even though I've set up what I believe are the correct permissions?

Source: https://zilliz.com/ai-faq/why-might-my-bedrock-request-be-failing-with-an-accessdenied-or-unauthorized-error-even-though-ive-set-up-what-i-believe-are-the-correct-permissions
Author: zilliz

**Direct Answer** 
Your Bedrock request might fail with `AccessDenied` or unauthorized errors due to misconfigured IAM policies, incorrect resource-based permissions, or issues with service activation. Even if permissions appear correct, subtle oversights in policy scoping, resource ARNs, or service-level restrictions can block access. Let’s break this down systematically.

**Policy Configuration Issues** 
First, verify the IAM policies attached to your user, role, or service account. A common mistake is granting `bedrock:*` permissions without explicitly allowing the specific action (e.g., `bedrock:InvokeModel`). For example, if your policy uses a wildcard resource (`Resource: "*"`) but lacks action granularity, AWS might still deny the request. Check for explicit `Deny` statements in other policies that override your intended permissions. Use the [IAM Policy Simulator](https://aws.amazon.com/blogs/security/iam-policy-simulator-now-supports-testing-for-multiple-aws-services/) to validate whether your policies actually grant access to Bedrock actions. Also, ensure the policy’s `Condition` blocks (e.g., IP restrictions or MFA requirements) aren’t unintentionally blocking the request.

**Resource and Service-Level Restrictions** 
Bedrock models often require explicit resource-based permissions. For example, if you’re invoking a model like `anthropic.claude-v2`, ensure the IAM policy specifies the correct model ARN (e.g., `arn:aws:bedrock:us-east-1::model/anthropic.claude-v2`). Cross-account access adds complexity: if your role is in Account A but the model is in Account B, Account B must grant access via a resource policy. Additionally, AWS Organizations might enforce Service Control Policies (SCPs) that block Bedrock usage at the organization level, even if your account’s IAM policies seem correct. Check for SCPs if your account is part of an AWS Organization.

**Service Activation and Region Compatibility** 
Bedrock requires explicit service activation in some AWS regions. For example, if you’re using `us-west-2`, ensure Bedrock is enabled in the AWS Management Console or via the `bedrock:ListFoundationModels` API call. If the service isn’t activated, requests will fail with authorization errors. Also, verify that your SDK or CLI is configured to use a region where Bedrock is available. For example, Bedrock isn’t supported in `ap-southeast-3` (Jakarta) as of 2023. Finally, check for credential issues: expired temporary tokens or misconfigured AWS profiles can masquerade as authorization failures. Use `aws sts get-caller-identity` to confirm the active credentials.