October 28, 2025

Bedrock'n'role: Annoying trust relationships in Bedrock service roles

Written by

Daniel Grzelak

Hey besties, you alive?

I am. Barely. I’ve been playing with Amazon Bedrock (distinct from AWS Bedrock which isn’t a thing), and I’ve found something small and annoying and niche, that I want to warn you about.

In an effort to make building AI stuff easy, AWS has built some helpers into the AWS console that create execution roles for various Bedrock functions. For example, when you want to create a new Agent, you can use the “Agent builder” UI and it will be less painful than trying to figure it out command line style.

Unfortunately, the execution roles they create have trust policies that are just scoped enough to be good enough but not scoped enough to be least privilege.

The trust policy allows any agent in the account to assume and use the created role. See the aws:SourceArn wildcard condition below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicyProd",
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:agent/*"
                }
            }
        }
    ]
}

Why is that less than ideal and somewhat annoying? Well, We’ve gone to the trouble to create a tightly scoped role for an agent that says it can only invoke a specific set of models:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicyProd",
            "Effect": "Allow",
            "Action": "bedrock:InvokeModel",
            "Resource": [
                "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-premier-v1:0",
                "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2:1"
            ]
        }
    ]
}

Yet if we have more agents in the account, or previously had more agents whose roles weren’t cleaned up, their roles can be attached to and assumed by our agent. This approach is similar to (but not exactly the same as) saying ‘an agent can invoke any model used by any agent ever created in the account’. The caveat being that an actor (annoyed developer?) still has to be able to change the configuration of their agent to point it to the correct role.

What the console helper (Agent builder in this case) should do instead is modify the trust policy to specify the full and exact ARN of the agent once it is created, so only that specific agent can invoke the models in the role’s resource policy. Something like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicyProd",
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:agent/abcdef-quick-start-f5cs9"
                }
            }
        }
    ]
}

This isn’t a huge deal. It’s not like an external attacker can easily abuse this issue but it’s one of those things that should be tightened just in case. Broken windows theory anyone? I’m sure some cloud security tool will rate this issue, “HIGH: risk not acceptable” but they will be wrong.

Bedrock Knowledge Base execution roles face a similar problem:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AmazonBedrockKnowledgeBaseTrustPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:knowledge-base/*"
                }
            }
        }
    ]
}

Funnily enough, other parts of Bedrock don’t have this issue. Bedrock Flow roles have this trust policy template where the aws:SourceArn is fully qualified:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:flow/ABCDEF01234"
                }
            }
        }
    ]
}

What should you do about this?

Normally I’d say “cry in the corner,” but this time you probably have more pressing problems to cry about, like injuring yourself in your sleep because you are old. Or is that just me?

Anyway, the Plerion cloud security platform has checks for these issues and Pleri our AI cloud security teammate can help you fix them in no time, if you’re the type of person to want everything buttoned up.

Blog

Learn cloud security with our research blog

X
Stay ahead in cloud security
Sign up for the Plerion newsletter and get:
🔸Expert strategies for securing your cloud
🔸Invitations to exclusive events and workshops
🔸Updates on Plerion’s latest features
🔸Early access to cloud security research
Check - Elements Webflow Library - BRIX Templates
Thanks for joining our newsletter.
Oops! Something went wrong while submitting the form.