I investigated the cause of access_denied being returned 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 became possible to invoke them from the bedrock-runtime endpoint as well.

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, GPT-5.6 cannot be invoked in its initial state. We actually confirmed a state where invoking it returns access_denied.

There are two factors to distinguish here. One is when the model has not been released to that account on the AWS side, and the other is when Bedrock usage is denied by the organization's SCP. The former requires asking AWS to release it, while the latter requires contacting the in-house AWS Organizations administrator who manages the SCP. Neither can be resolved by fixing your local IAM policies or model access settings.

We had an opportunity to distinguish between these two, so we'll introduce it here. We verified whether the distinction could be made from error messages alone across 5 routes including the OpenAI-compatible API. We also organized who should be contacted and what information should be communicated for each cause.

Investigation Details

We invoked GPT-5.6 Luna in us-east-1 via the following 5 routes.

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

The first three were invoked from the OpenAI SDK, and the last two from boto3.

To reproduce a state where Bedrock usage is restricted by AWS Organizations, we created a verification SCP 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 it had not been released. Retrieved via the 3 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'}}"
  }
]

Across all 3 routes, the code was access_denied and the type was permission_denied_error, and no policy ARN appeared in the messages. The status was 401 for mantle and 403 for the 2 runtime routes.

At the point when invocation failed, we checked the model release status with bedrock get-foundation-model-availability.

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

Only the agreementAvailability status was NOT_AVAILABLE, while the other 3 items were AVAILABLE / AUTHORIZED.

Upon seeing this result, we concluded a model access agreement using bedrock create-foundation-model-agreement. The agreement succeeded and the agreementAvailability status also changed to AVAILABLE. All 4 items became normal values. Nevertheless, the state of being unable to invoke it did not change.

This account had AWS Enterprise Support contracted, making it possible to file support cases. So we requested the release of the model. The case included the target account, region, model ID, and the full error text from all 3 routes. We also noted that the Service Quotas were at default values, that the model was ACTIVE, and that we were invoking with an admin role. The model was released the day after filing the case, and it became possible to invoke it from the same account.

When Denied by the Organization's SCP

We invoked via the same 5 routes with the verification SCP attached. 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\":\"*\"}]}"
    }
}

Full error text for 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'}}

For bedrock-runtime's OpenAI-compatible API (US Geo), the following error occurred.

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 model ID; the message body and status were the same as US Geo. For the native API's Converse and InvokeModel, the message body was the same as US Geo, but the status was 403. Across all 5 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 5 routes responded normally in both cases. They were executed on the same account with the same script, and the only thing that changed the results was the presence or absence of the SCP.

The update that caused the ARN to appear in messages was on January 21, 2026. This is limited to cases within the same account and same organization. In addition to service control policies (SCPs) and resource control policies (RCPs), it also covers identity-based policies, session policies, and permission boundaries.

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

Previously, only the policy type could be identified, and when multiple policies of the same type existed, it was impossible to narrow down the cause. This additional information is provided to AWS services incrementally. With the ARN, administrators can open the relevant policy directly, eliminating the need to check potentially relevant policies one by one.

Comparison of 5 Routes

Results across the 5 routes with the SCP applied.

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

Placing the AWS-side unreleased case and SCP denial side by side looks like the following.

The code and type matched between both cases across the 3 OpenAI-compatible routes. For the native APIs, both were 403 AccessDeniedException in both cases. For the OpenAI-compatible API, the appearance of status codes 401 and 403 was reversed between cases. Looking at the status code alone leads to misreading.

What remains as a distinguishing factor is the message body. If with an explicit deny in a service control policy and a policy ARN are present, it is SCP-derived. If it says is not available for this account, it is an AWS-side unreleased model. The return value of get-foundation-model-availability cannot be used for distinction. Even when all 4 items are normal, invocation may still fail.

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

Who to Contact and What to Communicate

The contact and information to provide differ depending on the cause.

AWS-side Unreleased

When the message contains is not available for this account.

• Contact: AWS Support (Amazon Bedrock case)
• Information to provide: Target account, region, model ID, full error text, confirmation results showing no issues on your side's configuration

SCP-derived

When the message contains with an explicit deny in a service control policy and a policy ARN.

• Contact: In-house AWS Organizations administrator
• Information to provide: Full message text (including the policy ARN and the referenced action and resource), invoked model ID and region, route used

Summary

For SCP-based denial, the ARN of the denying policy and the explicit deny wording appeared in the message body. This information was not lost even in OpenAI-compatible API error responses. For AWS-side unreleased models, no ARN appeared in any of the 5 routes' messages observed this time. What was returned was only the wording stating that the model is not available for this account. The code and type matched between both cases, and the 401 and 403 status codes are reversed depending on the 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 and a policy ARN indicate SCP-derived, while is not available for this account is a clue indicating an AWS-side unreleased model.

Please communicate the information contained in the error message, along with the target account, region, model ID, route used, and confirmed configuration status to the appropriate contact. This will make it easier to proceed with the investigation toward resolving the usage restriction.