企业级云部署最折磨人的不是技术难题，而是权限迷宫。一位工程师在AWS Bedrock上部署AI代理，本地测试一切正常，迁移到生产环境却花了整整三周——问题出在一行几乎所有企业都会设置的IAM策略上。

核心冲突在于iam:PassRole权限。Bedrock代理需要执行角色来调用基础模型，这要求创建者拥有传递该角色的权限。但企业安全团队普遍通过托管策略显式拒绝这一操作，防止权限提升风险。IAM的评估逻辑是：显式拒绝永远优先，无论用户是否拥有AdministratorAccess，无论是否附加了自定义允许策略。

打开网易新闻 查看精彩图片

工程师尝试了CLI直接部署、扩大权限范围、更换角色等多种方案，全部失败。错误信息始终相同：AccessDeniedException: User is not authorized to perform iam:PassRole。三天排查后，问题根源才浮出水面——这不是"加权限就能解决"的简单场景，而是多层策略评估机制的系统性约束。

企业IAM架构通常包含四层防护：组织级SCP（服务控制策略）、账户级权限边界、角色/用户级托管策略、以及内联策略。该工程师卡在第三层：企业统一附加的OrgDenyEscalation策略对iam:PassRole、iam:CreateRole等操作实施显式拒绝，且开发者无权修改或解绑。自定义策略只能在未被显式拒绝的范围内生效。

最终解决方案绕开了用户身份本身：通过CloudFormation的服务角色部署。CloudFormation使用独立的服务角色（如cloudformation-service-role）创建资源，该角色通常具备基础设施配置所需的完整权限。由于显式拒绝仅作用于工程师的开发角色，服务角色不受此限制，部署得以完成。

这一案例揭示了企业云治理的深层张力。安全团队需要防止权限滥用，开发团队需要完成基础设施部署，两者的交集往往产生意想不到的摩擦成本。三周时间消耗不在技术实现，而在理解"为什么我的管理员权限无效"——IAM的复杂性在此成为隐性债务。对于构建类似系统的团队，提前确认部署路径与组织策略的兼容性，比事后排查更能节省时间。