Investigating the Cause of access_denied Errors with GPT-5.6 on Amazon Bedrock

Introduction

In July 2026, Amazon Bedrock added support for OpenAI GPT-5.6 (Sol / Terra / Luna). In August, it also became possible to call it from the bedrock-runtime endpoint.

https://dev.classmethod.jp/articles/bedrock-openai-gpt56-sol-terra-luna/

https://dev.classmethod.jp/articles/bedrock-runtime-openai-gpt56/

However, depending on the account, you may not be able to call GPT-5.6 in its initial state. I actually confirmed a state where calling it returns access_denied.

There are two factors to distinguish here: the case where the model has not been released to the account on the AWS side, and the case where the organization's SCP denies the use of Bedrock. For the former, you have no choice but to have AWS release it; for the latter, you need to ask the in-house AWS Organizations administrator who manages the SCP. Neither can be resolved by fixing your local IAM policies or model access settings.

I had an opportunity to distinguish between these two, so I'm sharing it here. I verified whether they can be distinguished from the error message alone, across five routes including the OpenAI-compatible API. I also organized who to tell what for each cause.

Investigation

In us-east-1, I called GPT-5.6 Luna through the following five routes.

• The OpenAI-compatible API of bedrock-mantle (model ID openai.gpt-5.6-luna)
• The OpenAI-compatible API of bedrock-runtime (US Geo us.openai.gpt-5.6-luna)
• The OpenAI-compatible API of bedrock-runtime (Global global.openai.gpt-5.6-luna)
• Converse of bedrock-runtime (US Geo)
• InvokeModel of bedrock-runtime (US Geo)

The first three were called from the OpenAI SDK, and the latter two from boto3.

To reproduce a state where the use of Bedrock is restricted by AWS Organizations, I created an SCP for verification and attached it directly to the target member account.

When the model has not been released on the AWS side

These are the errors when the model had not been released. I obtained them from the three OpenAI-compatible routes.

[
  {
    "target": "mantle / base id",
    "model": "openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "AuthenticationError",
    "error": "Error code: 401 - {'error': {'code': 'access_denied', 'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'param': None, 'type': 'permission_denied_error'}}"
  },
  {
    "target": "runtime / us. geo",
    "model": "us.openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "PermissionDeniedError",
    "error": "Error code: 403 - {'error': {'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}"
  },
  {
    "target": "runtime / global",
    "model": "global.openai.gpt-5.6-luna",
    "status": "error",
    "error_type": "PermissionDeniedError",
    "error": "Error code: 403 - {'error': {'message': 'openai.gpt-5.6-luna is not available for this account. You can explore other available models on Amazon Bedrock. For additional access options, contact AWS Sales at https://aws.amazon.com/contact-us/sales-support/', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}"
  }
]

On all three routes, the code was access_denied and the type was permission_denied_error, and the message did not include a policy ARN. The status was 401 for mantle and 403 for the two runtime routes.

At the point when the call failed, I checked the model's availability with bedrock get-foundation-model-availability.

{
    "modelId": "openai.gpt-5.6-luna",
    "agreementAvailability": {
        "status": "NOT_AVAILABLE"
    },
    "authorizationStatus": "AUTHORIZED",
    "entitlementAvailability": "AVAILABLE",
    "regionAvailability": "AVAILABLE"
}

Only the status of agreementAvailability was NOT_AVAILABLE; the other three items were AVAILABLE / AUTHORIZED.

Seeing this result, I concluded the model access agreement with bedrock create-foundation-model-agreement. The agreement succeeded, and the status of agreementAvailability changed to AVAILABLE. All four items became normal values. Even so, the state of being unable to call the model did not change.

This account had an AWS Enterprise Support contract, so I could open a support case. I therefore requested the release of the model. In the case, I included the target account, region, model ID, and the full error text of the three routes. I also noted that Service Quotas were at their default values, that the model was ACTIVE, and that I was calling with an administrator role. The day after I opened the case, the model was released, and I could call it from the same account.

When denied by the organization's SCP

With the SCP for verification attached, I called through the same five routes. The policy denies both bedrock:* and bedrock-mantle:*.

{
    "Policy": {
        "PolicySummary": {
            "Id": "p-xxxxxxxxx",
            "Arn": "arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx",
            "Type": "SERVICE_CONTROL_POLICY",
            "AwsManaged": false
        },
        "Content": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyBedrockForVerification\",\"Effect\":\"Deny\",\"Action\":[\"bedrock:*\",\"bedrock-mantle:*\"],\"Resource\":\"*\"}]}"
    }
}

This is the full error text of the mantle route.

Error code: 403 - {'error': {'code': 'access_denied', 'message': 'User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock-mantle:CreateInference on resource: arn:aws:bedrock-mantle:us-east-1:123456789012:project/default with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx', 'param': None, 'type': 'permission_denied_error'}}

The OpenAI-compatible API of bedrock-runtime (US Geo) produced the following error.

Error code: 401 - {'error': {'message': 'User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.openai.gpt-5.6-luna with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx', 'type': 'permission_denied_error', 'param': None, 'code': 'access_denied'}}

The Global route differed only in the model ID; the message body and status were the same as US Geo. For the native APIs Converse and InvokeModel, the message body was the same as US Geo, but the status was 403. On all five routes, the ARN of the denying policy appeared at the end of the message.

AccessDeniedException (HTTP 403)
User: arn:aws:sts::123456789012:assumed-role/OrganizationAccountAccessRole/scp-verify3 is not authorized to perform: bedrock:InvokeModel on resource: arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.openai.gpt-5.6-luna with an explicit deny in a service control policy: arn:aws:organizations::111122223333:policy/o-xxxxxxxxxx/service_control_policy/p-xxxxxxxxx

Before applying the SCP, and after detaching and deleting it, all five routes responded normally. I ran everything on the same account with the same script, so the only thing that changed the result was the presence of the SCP.

ARNs began appearing in messages with the update on January 21, 2026. This applies only to the same account and the same organization. The targets are service control policies (SCPs) and resource control policies (RCPs), as well as identity-based policies, session policies, and permissions boundaries.

https://aws.amazon.com/about-aws/whats-new/2026/01/additional-policy-details-access-denied-error/

Previously, only the type of policy was shown, so when there were multiple policies of the same type, you couldn't narrow down the cause. This additional information is being rolled out gradually to AWS services. With the ARN, administrators can open the relevant policy directly, so they don't need to check likely policies one by one.

Comparison of the five routes

These are the results of the five routes with the SCP applied.

The referenced action and resource differed by route. The mantle error cited bedrock-mantle:CreateInference as the action and project/default as the resource. The runtime error cited bedrock:InvokeModel as the action and the inference profile as the resource.

Putting the AWS-side non-release and the SCP denial side by side gives the following.

The code and type matched between the two cases on the three OpenAI-compatible routes. For the native APIs, both were 403 AccessDeniedException. On the OpenAI-compatible APIs, the status codes 401 and 403 appeared in opposite ways. If you look only at the status code, you will misread it.

What remains as a distinguishing clue is the message body. If it has with an explicit deny in a service control policy and a policy ARN, it comes from an SCP. If it says is not available for this account, the model has not been released on the AWS side. The return value of get-foundation-model-availability cannot be used for this determination. Even when all four items are normal, calls can still fail.

Even in the error responses of the OpenAI-compatible API, the IAM message was placed as-is in error.message, with the ARN at the end. The information needed for the determination was not lost.

Who to tell what

The party to ask and the information to convey differ by cause.

Not released on the AWS side

This is when the message contains is not available for this account.

• Who to ask: AWS Support (an Amazon Bedrock case)
• Information to convey: The target account, region, and model ID, the full error text, and the results of confirming that there is no problem on your side's settings

Caused by an SCP

This is when the message contains with an explicit deny in a service control policy and a policy ARN.

• Who to ask: The in-house AWS Organizations administrator
• Information to convey: The full message (including the policy ARN and the referenced action and resource), the model ID and region you called, and the route you used

Summary

With SCP denials, the ARN of the denying policy and the wording of explicit deny appeared in the message body. This information was not lost even in the error responses of the OpenAI-compatible API. With AWS-side non-release, no ARN appeared in the messages of any of the five routes observed this time. All that came back was wording saying the model is not available in this account. The code and type matched between the two, and the status codes 401 and 403 reversed by route, so what you should look at is the message body.

If you cannot use GPT-5.6, first check the error message body. with an explicit deny in a service control policy together with a policy ARN indicates an SCP origin, and is not available for this account is a clue that the model has not been released on the AWS side.

Please convey to the party you are asking the information contained in the error message, the target account, region, and model ID, the route you used, and the settings you have already confirmed. This makes it easier for them to proceed with the investigation toward lifting the usage restriction.