Simplified model access in Amazon Bedrock

Amazon Bedrock has simplified how you access foundation models, streamlining the integration of AI capabilities into your applications. Here’s what’s changed and how to maintain control over model access in your organization.

Amazon Bedrock now provides automatic access to the serverless models in your AWS Region, eliminating the previous requirement for manual enablement of each individual model. This change brings Amazon Bedrock in line with other AWS services by relying on standard AWS access controls rather than requiring customers to enable each model through a model access dashboard. This simplification effort has retired the Model Access page along with the PutFoundationModelEntitlement AWS Identity and Access Management (IAM) permission and its corresponding API call. IAM statements with the PutFoundationModelEntitlement permission no longer have an effect.

The change delivers immediate benefits for developers and organizations. You can now access models through the AWS Management Console for Amazon Bedrock, AWS SDK, or Amazon Bedrock API without additional setup steps, dramatically accelerating your development timeline. Previously enabled models continue to work exactly as before, so that there are no disruptions to existing applications. Most importantly, any models currently blocked through IAM policies or service control policies (SCPs) remain restricted, preserving your existing security posture. You can review model end user license agreements (EULAs) any time. EULAs can also be accessed on the model card in the Model Catalog.

IAM policies provide account-level control over foundation model access. You can use these policies to permit or deny Invoke* actions for specific foundation models within individual AWS accounts.

SCPs offer organizational-level governance for AWS Organizations users. You can use SCPs to implement model restrictions across multiple accounts in your organization simultaneously, providing consistent governance policies regardless of how your teams are structured. Similar to IAM policies, SCP policies can block entire families of models through pattern matching, providing centralized governance that scales with your organizational structure.

SCP and IAM policies work together seamlessly, and you can use them to establish broad organizational controls while giving individual accounts access that they can use to implement more specific restrictions based on their particular use cases and requirements.

You can use IAM policies to implement granular permissions, giving your builders access to a single, specific model. The following example demonstrates how to explicitly allow only the Anthropic Sonnet 4.5.

{

  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Sid”: “AllowAnthropicModelsOnly”,
      “Effect”: “Allow”,
      “Action”: [
        “bedrock:InvokeModel”,
        “bedrock:InvokeModelWithResponseStream”,
        “bedrock:CreateModelInvocationJob”,
        “bedrock:Converse”,
        “bedrock:ConverseStream”
      ],
    “Resource”: "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
   }
  ]
}

You can also implement comprehensive control strategies using wildcard patterns. By using an asterisk (*) for the model ID in your policies, you can enable access to a broader set of foundation models by default and then create separate deny policies for select models that aren’t approved in your organization.

The following is an IAM policy example using NotResource that denies the models except Amazon Nova models and Claude 4.5 Sonnet models.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BroadBedrockAllow",
      "Effect": "Allow",
      "Action": "bedrock:*",
      "Resource": "*"
    },
    {
      "Sid": "DenyInferenceExceptApprovedModels",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
     ],
     "NotResource": [
        "arn:aws:bedrock:*::foundation-model/amazon.nova-*",
        "arn:aws:bedrock:*::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
     ]
   }
  ]
}

When you deny InvokeModel access in your policies, actions such as Converse will not work either. This is because Converse relies on Invoke.

While IAM supports a high level of precision, it’s not always used in larger organizations, which might use SCP policies instead. SCPs can be attached to entire organizations or organizational units (OUs) and used to simplify permissions management at scale. Organizations that use SCPs can restrict families of models on organization or OU levels. The following is an example of SCP policy that blocks specific models (or model families) across an entire organization.

{
  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Sid”: “DenyDeepseekEverywhere”,
      “Effect”: “Deny”,
      “Action”: “bedrock:*”,
      “Resource”: 
        “arn:aws:bedrock:*::foundation-model/deepseek.*”
      }
    ]
}

This approach requires ongoing maintenance; explicitly specifying blocked models isn’t practical because you would have to maintain the policy to include new models as they become available. By using the recently introduced NotResource property for SCP policies, a more elegant solution is to block all models except allowed ones. The following example shows how it’s done:

{
  “Version”: “2012-10-17”,
   “Statement”: [
  {
    “Sid”: “Statement1”,
    “Effect”: “Deny”,
    “Action”: “bedrock:*”,
      “NotResource”: [
        “arn:aws:bedrock:*::foundation-model/amazon.nova*”
     ]
    }
  ]
}

Considerations for Anthropic models