How I Governance-Proofed Our Bedrock Agents Across Multiple AWS Accounts

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3844772) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Nez Iribas Posted on Apr 28 How I Governance-Proofed Our Bedrock Agents Across Multiple AWS Accounts #ai #aws #terraform #community Part 2 of 4 — Securing Agentic AI on AWS: A Cloud Engineer's Playbook In Part 1, I fixed 11 security gaps in a single Bedrock Agent. That was the easy part. The hard part: making sure no developer in any of our AWS accounts could ever reproduce those gaps. The moment someone opens a new sandbox account and deploys an agent without reading the playbook, everything you fixed is undone. A playbook isn't governance. Governance is what makes the playbook irrelevant. This article covers how to enforce Bedrock security controls at the organizational level — so insecure configurations become impossible to deploy, not just discouraged. By the end, you'll have: 3 production-ready SCPs that block insecure Bedrock configurations before they're deployed 2 AWS Config Rules (1 managed + 1 custom Lambda) that catch drift in real time An EventBridge → SNS alerting pipeline wired up with Terraform A hands-on test sequence to verify every control actually works All Terraform. All verified against AWS documentation. No handwaving. Note: Some supporting resources (KMS keys, S3 buckets, IAM roles) are referenced but not fully defined — this article focuses on the governance layer itself. Adapt the examples to fit your existing infrastructure. The Architecture: Three Layers Layer 1 — SCPs (Preventive) └── Block insecure configurations before they're deployed Layer 2 — AWS Config Rules (Detective) └── Catch drift in resources that already exist Layer 3 — EventBridge + SNS (Responsive) └── Alert immediately when something slips through Enter fullscreen mode Exit fullscreen mode If Layer 1 works, Layer 2 never fires. If Layer 2 fires, Layer 3 wakes someone up. Defense in depth — not for paranoia, but because people make mistakes and environments drift. Prerequisites You'll need: AWS Organizations with at least one OU Terraform v1.5+ with AWS provider v5.x Permissions to manage org-level policies Verify your org structure before you start: # Confirm your org exists and get the root ID aws organizations describe-organization # List your OUs ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text) aws organizations list-organizational-units-for-parent --parent-id $ROOT_ID Enter fullscreen mode Exit fullscreen mode Layer 1: Service Control Policies SCPs are evaluated before IAM policies — before the request even reaches the service. Even an account root user cannot override them. This is what makes them the right tool for hard enforcement. ⚠️ Always test SCPs in a sandbox OU first. Attach to a single test account before applying org-wide. A misconfigured SCP can immediately lock out legitimate access across every account in the OU. SCP 1: Block Bedrock API Keys Entirely In July 2025, AWS released Bedrock API Keys — a new authentication method that lets developers call Bedrock outside of standard IAM roles. Long-lived keys, created with one click from the console, not tied to IAM roles. If your team has no need for them, block both the creation and the usage. This SCP requires two statements to be complete. Most…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.