The iam: PassRole Nightmare - 3 Weeks of My Life I Will Never Get Back

Let me tell you the story of three weeks of my life I will never get back.

We were building an AI agent on AMAZON Bedrock — an autonomous system that manages infrastructure lifecycle operations. The agent worked perfectly in our sandbox. Time to deploy it to the enterprise environment. Should take an afternoon, right?

It took three weeks.

The Setup

To deploy a Bedrock Agent, you need to attach an IAM role — the execution role that the agent assumes when it invokes foundation models. This requires the iam:PassRole permission. Simple enough.

In our enterprise environment, there is a managed policy attached to every developer role. Let's call it OrgDenyEscalation. This policy contains an explicit deny on iam:PassRole:

{
    "Effect": "Deny",
    "Action": [
        "iam:PassRole",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:DeleteRole"
    ],
    "Resource": "*"
}

The critical thing about IAM evaluation: explicit deny always wins. It does not matter if you have AdministratorAccess. It does not matter if you create a custom policy that allows iam:PassRole. An explicit deny on any policy attached to your identity overrides every allow, period.

So we could not deploy the agent via CLI. The aws bedrock-agent create-agent command returned:

AccessDeniedException: User is not authorized to perform iam:PassRole

We spent three days trying to figure out why. Read every IAM doc, every blog post, every Stack Overflow answer. Added broader permissions. Tried different roles. Nothing worked.

The Root Cause Nobody Talks About

Enterprise IAM is not "add permissions until it works." It is a policy evaluation chain with multiple layers:

Request -> SCP (Organization level)
       -> Permission Boundary (Account level)
       -> Managed Policies (Role/User level)
       -> Inline Policies (Role/User level)
       -> Resource Policies (Bucket/Queue/etc. level)

Our organization has:

1. Service Control Policies (SCPs): Org-level restrictions. Immovable.
2. Permission Boundaries: Account-level caps on maximum permissions a role can have.
3. Managed Policies: Enterprise-wide policies attached to all developer roles. These deny dangerous actions (iam:PassRole, iam:CreateRole). You cannot modify or detach them.
4. Your Custom Policies: Only effective for actions not explicitly denied by layers 1-3.

We were fighting layer 3. You cannot win that fight by adding more permissions.

The CloudFormation Escape Hatch

The non-obvious solution: CloudFormation uses a service role, not your user identity. When CloudFormation creates resources, it assumes a role (like cloudformation-service-role) that has the necessary permissions. If that service role has iam:PassRole — and it typically does for infrastructure provisioning — the explicit deny on your developer role does not apply.

# This works even when your CLI identity has explicit deny on iam:PassRole
Resources:
  BedrockAgent:
    Type: AWS::Bedrock::Agent
    Properties:
      AgentName: my-agent
      AgentResourceRoleArn: !Ref AgentExecutionRole
      FoundationModel: anthropic.claude-sonnet-4-20250514

The catch: someone on the cloud platform team needs to have already configured the CloudFormation service role with the right permissions. In our case, this required a change request, a security review, and a 5-business-day SLA.

A colleague on the platform team finally pointed us at the managed policy with the explicit deny. Three weeks later (after the change request process ground through), the CloudFormation service role was updated, and the deployment worked in 30 seconds.

The Permissions You Will Actually Need

For anyone building Bedrock Agents in enterprise, here is the full list of permissions that will cause problems and where:

Action	Why You Need It	Enterprise Blocker
iam:PassRole	Attach execution role to agent	Explicit deny in managed policy
bedrock:CreateAgent	Create the agent	Usually allowed, but may need SCP update
kms:CreateGrant	Use KMS key for Bedrock encryption	Key policy must allow your role
s3:PutObject	Store state files	Bucket policy + VPC endpoint policy
lambda:InvokeFunction	Call action group Lambdas	Function resource policy must allow agent

How to Work With Platform Teams (Without Losing Your Mind)

Your ability to deploy agents depends on your relationship with the platform team. After two failed attempts, here is what actually moves the needle:

1. Come with a specific ask: Not "I need more permissions" but "I need iam:PassRole scoped to arn:aws:iam::*:role/BedrockExecRole* for the CloudFormation service role."

2. Provide the policy JSON: Do not make them write it. Draft the policy, explain each permission, justify the scope.

3. Show the error: Share the exact AccessDeniedException with the request ID. This helps the security team trace the denial.

4. Schedule an architecture review BEFORE you start building: A 30-minute meeting upfront saves three weeks of tickets later.

5. Never ask for "Resource": "*": Always scope to specific ARN patterns. Least privilege is not optional — it is what gets your request approved.

The Lesson

In enterprise environments, the IAM model is not "add permissions until it works." It is "understand the full policy evaluation chain — managed policies, permission boundaries, SCPs, resource policies — and find the path through the maze." Sometimes that path is CloudFormation. Sometimes it is assuming a different role. Sometimes it is waiting for a change request.

Nobody tells you this in the Bedrock quickstart guide. The 5-minute demo assumes you have AdministratorAccess. In enterprise, that assumption is the first thing that breaks.

---

This is one of 13 chapters from my book *Enterprise AI Agents: From POC to Production on AWS*.

The book covers the full architecture, IAM patterns, state management, observability, and 12 more war stories from going POC -> production. Use code **DEVTO50* for 50% off (launch pricing, next 20 days only).*

Found this helpful? Follow me here on Dev.to — I post weekly about enterprise AI engineering on AWS.