Bedrock Permission Boundary

bedrock-pb.md

What do we need to control or features we need permission boundary for:

1. Short lived and Long lived API keys in bedrock
   1. so long lived API keys always create an IAM user, which means during the time of investigation, we could check those users in IAM and find out if any API key has been created or not.
   2. User or malicious actor can add these API keys to their local running claude agent or codex or anything that supports bedrock
2. Playground
   1. user can communicate with higher cost LLM models, can send images, generate code or communicate in such a way that'd incur a huge cost on the organisation.
   2. The models from "Model catalogue" opens up in the play ground for communication as well.
3. Knowledge base
4. Build Agents
5. Guardrails
6. Prompt management - what kind of prompt is allowed, restrict the ones with explicit language and statements.

IAM Changes: Source

Actions:

1. iam:CreateServiceSpecificCredential - allows generation of a service-specific keys such as the long term API key in aws bedrock, if used with condition called "iam:ServiceSpecificCredentialServiceName", restricts the access to bedrock only.
2. bedrock:CallWithBearerToken - allows usage of a API keys generated

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyCreationOfBedrockAPIKeys",
            "Effect": "Deny",
            "Action": [
                "iam:CreateServiceSpecificCredential"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringEquals": {
                    "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
                }
            }
        },
        {
            "Sid": "DenyUsageOfShortNLongTermAPIKeys",
            "Effect": "Deny",
            "Action": [
                "bedrock:CallWithBearerToken"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringEquals": {
                    "bedrock:bearerTokenType": [
                        "LONG_TERM",
                        "SHORT_TERM"
                    ]
                }
            }
        }
    ]
}

Other use-cases:

1. Direct model invocation - most probably while creating agents or initiating conversation in the playground etc.

  {
    "Sid": "RestrictInvokeToApprovedModels",
    "Effect": "Deny",
    "Action": [
      "bedrock:InvokeModel",
      "bedrock:InvokeModelWithResponseStream",
      "bedrock:Converse",
      "bedrock:ConverseStream"
    ],
    "NotResource": [
      "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5*",
      "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4*",
      "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:inference-profile/us.anthropic.claude-haiku-4-5*"
    ] // NotResource element in IAM policy means, the action would work on any resources except the ones given in "NotResource"
  }

2. Cross-region inference profile - (have to read about this but this is different from what an inference in LLM)
3. Provisioned Throughput - Basically, this means reserving a specific model capacity. Usually, pay-per-go pricing model is used with all these LLM models, however if you wanna set specific capacity to your models, you can use provisioned throughput, and it costs a lot, once registered, can't go back.

{
    "Sid": "DenyProvisionedThroughput",
    "Effect": "Deny",
    "Action": [
      "bedrock:CreateProvisionedModelThroughput",
      "bedrock:UpdateProvisionedModelThroughput",
      "bedrock:DeleteProvisionedModelThroughput" // this can be removed, since we are already applying the create and update.
    ],
    "Resource": "*"
}

4. Use of Distillation, fine-tuning and continued-training
   1. Distillation - means, compressing a larger models' behaviour into a smaller one.
   2. fine-tuning - tune with custom dataset
   3. continued-training - training for a specific period of time.

// All three needs s3 bucket in order to continue with them
{
    "Sid": "DenyModelCustomization",
    "Effect": "Deny",
    "Action": [
      "bedrock:CreateModelCustomizationJob",
      "bedrock:StopModelCustomizationJob",
      "bedrock:CreateModelCopyJob",
      "bedrock:CreateModelImportJob",
      "bedrock:DeleteCustomModel",
      "bedrock:DeleteImportedModel"
    ],
    "Resource": "*"
  }

5. Batch Inference Job - this also requires an s3 bucket, however a malicious user can provide a huge s3 file to the batch job and run it async.

{
    "Sid": "DenyBatchInference",
    "Effect": "Deny",
    "Action": [
      "bedrock:CreateModelInvocationJob",
      "bedrock:StopModelInvocationJob"
    ],
    "Resource": "*"
}

---

Not related to bedrock tho
EC2 permission boundary, where a user can not create instances other than the ones mentioned in the IAM policy and volumes that are not encrypted.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictEC2InstanceType",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "ec2:InstanceType": [
                        "t3.micro",
                        "t3.small",
                        "t3.medium"
                    ]
                }
            }
        },
        {
            "Sid": "RestrictUnencryptedVolumes",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*"
            ],
            "Condition": {
                "Bool": {
                    "ec2:Encrypted": "false"
                }
            }
        }
    ]
}