3 mins to read
Most teams govern AI workloads at the application layer. They configure guardrails for their Bedrock agents, scope IAM roles per workload, and build policies around approved models. That discipline matters, but it breaks down the moment a developer spins up a new account or invokes a model directly without touching the application stack.
Org-level enforcement closes that gap. AWS now provides the tooling to apply AI governance uniformly across every account in your organization, and the controls are more precise than most teams realize.
What’s Actually Controllable at the Org Level
There are four categories of control worth implementing today:
1. MCP Server Access AWS-managed remote MCP servers, including the generic AWS MCP Server and service-specific variants for SageMaker, EKS, and ECS, support both read and write access to the AWS control plane. The aws:ViaAWSMCPService condition key lets you block all API calls made through these servers org-wide with a single SCP statement. One caveat: agents with direct CLI access can route around this. The control is meaningful for constraining managed MCP paths, but it doesn’t solve the broader problem of over-permissioned agent identities.
2. Baseline Guardrails via Bedrock Policies Amazon Bedrock Policies enforce specific guardrail configurations at the org level. Once attached to a node in your org hierarchy, every model invocation from covered accounts applies those guardrails, even direct InvokeModel calls that don’t reference guardrails explicitly. This is a meaningful shift from the previous model, where guardrails only applied if the workload opted in.
A practical baseline: configure prompt injection detection in us-east-1 and us-west-2, share the guardrails with your organization, then attach a Bedrock Policy at the root. Any invocation from a covered account in those regions gets the guardrail applied automatically. Pair this with an SCP that blocks Bedrock in all other regions, otherwise model invocations from other regions your baseline entirely.
Want the full implementation details? The complete technical guide covers working code for each SCP, step-by-step Bedrock Policy setup, and verification outputs.
[Read the full article →]
3. Model Availability via SCP Foundation models are first-class resources in IAM, they appear in the Resource field of policy statements. This means you can deny access to specific model families using standard SCP deny statements, referencing model ARN patterns like arn:aws:bedrock:*::foundation-model/deepseek*. The same logic applies to invocations made via the OpenAI SDK compatibility layer, which uses a separate bedrock-mantle IAM namespace requiring a bedrock-mantle:Model condition key rather than an ARN resource reference.
4. AI Service Availability via SCP SCPs can disable entire AI services at the org level by denying all permissions in a service’s IAM namespace with a wildcard action. To block Bedrock AgentCore across every covered account, a single deny statement on bedrock-agentcore:* is sufficient. SCPs also support per-identity exemptions using the aws:PrincipalArn condition key, which is useful when security roles need read access to confirm the absence of AI resources, or when you need to preserve access for break-glass accounts, without opening the service to everyone else.
5. Long-Term Bedrock API Key Restrictions AWS released Bedrock API Keys in mid-2025. Short-term keys are scoped appropriately and inherit the creating identity’s permissions. Long-term keys are a different story. When keys are created from the console, AWS creates a new IAM user with an attached managed policy, issues static credentials not tied to the calling identity, and exposes permissions that include the ability to invoke arbitrary models and modify guardrails. Sonrai identified an SCP bypass in early 2026 that relied on long-term key use.
AWS themselves recommend against long-term keys in production. Two SCPs address this directly: one blocks their use via bedrock:BearerTokenType condition matching, and one prevents their creation by denying iam:CreateServiceSpecificCredential.
The Controls Are Real — So Are the Gaps
None of this replaces the harder work of right-sizing the permissions attached to cloud identities. An SCP blocking MCP server access doesn’t constrain an agent that can invoke the AWS CLI directly.
These org-level controls are a floor, not a ceiling. They’re most effective when combined with identity-level permission scoping, specifically, ensuring that the identities your AI agents and developers operate under hold only the privileges they actually need.
For the full implementation guide – including working code for each SCP, step-by-step Bedrock Policy setup, and verification outputs, read the complete technical article: Enforcing AI Governance Across AWS Organizations: SCPs, Guardrails, and API Key Controls.
