Enterprise Amazon Bedrock Governance Framework

Governance decision framework for enterprise Bedrock adoption. Covers account structure, IAM design, model selection gates, cost controls, and incident response...

Abstract

This whitepaper presents a five-pillar governance framework for enterprises adopting Amazon Bedrock in a multi-account AWS organization. The framework addresses the governance gaps that appear when Bedrock access is introduced into an existing cloud environment without a coordinated policy: uncontrolled model access, inconsistent cost attribution, unreviewed model additions, slow incident response, and unclear accountability.

The five pillars are: account structure and access boundaries, IAM design and least-privilege model access, model selection gates, cost controls and allocation, and incident response for AI systems. Each pillar has a defined decision owner, a set of control types (preventive, detective, and responsive), and a set of artifacts the organization must produce before the pillar is considered governed.

The worked example throughout is a 50-account AWS organization deploying Bedrock across three business units: a customer-facing product team, an internal analytics team, and a data science research team. Each team has different risk tolerance, budget ownership, and model access requirements. The framework shows how a single governance policy can accommodate these differences without creating three separate, inconsistently enforced regimes.

This framework does not cover Amazon SageMaker custom model training or non-AWS AI services. The Bedrock capabilities described here were verified against AWS documentation as of November 2026 (sourceCheckedDate: 2026-11-05). Amazon Bedrock is a rapidly evolving service; features, API names, and service boundaries may have changed since this content was written. Verify all specific API syntax, service availability, and feature scope against the current AWS documentation before use in a production environment. In particular, Amazon Bedrock Agents Classic is now in maintenance mode; new agent workloads should use Amazon Bedrock AgentCore.

2. Definitions and Scope

Amazon Bedrock access means any API call to the Bedrock service that invokes a foundation model, creates or queries a knowledge base, invokes a Bedrock agent, or manages a Bedrock-related resource (such as a guardrail or a prompt management resource). Access may come from a human user via the AWS console, from an application via the AWS SDK, or from an automated pipeline via a service role.

Foundation model means a third-party or Amazon-developed model available through the Bedrock API, accessed on a pay-per-token or provisioned-throughput basis. This does not include custom fine-tuned models deployed to SageMaker, which require a separate governance framework.

Production allowlist means the set of Bedrock model IDs that are approved for use in production workloads in the organization. A model is not permitted in production until it has passed the model selection gate described in Pillar 3.

AI incident means any event where a Bedrock-powered system produces output that causes or risks causing harm to a user, the organization, or a third party. This includes but is not limited to: generation of harmful or regulated content, disclosure of confidential information through model output, unexpected costs exceeding budget thresholds, or availability failures that affect dependent business processes.

Scope exclusions. This framework does not govern: access to non-Bedrock AI services (OpenAI API, Google Vertex AI, Azure OpenAI); SageMaker custom model training or inference endpoints; use of Bedrock in personal AWS accounts outside the organization's AWS Organizations hierarchy; or academic research use with no connection to production systems.

3. The Governance Problem

The typical sequence of events when an enterprise adopts Bedrock without a governance framework is as follows. A product team or data scientist discovers Bedrock in the AWS console, enables a model in a development account, and begins building a proof of concept. The proof of concept demonstrates value. The team asks for production access. At this point, the organization faces several problems simultaneously.

Access proliferation. Multiple teams have enabled different models in different accounts. Some accounts have broad IAM permissions that allow any principal to invoke any model. There is no central record of which models are in use, in which accounts, for which workloads.

Cost opacity. Bedrock costs are appearing in multiple accounts. No cost allocation tags have been applied. The finance team cannot attribute costs to specific teams or workloads. When a bill arrives with a large Bedrock line item, no one can explain where the spend came from.

Model risk unevaluated. Models were enabled without a formal evaluation process. There is no record of which models were evaluated for content safety, data handling properties, or regulatory compliance. Some models may be processing personal data without a data processing agreement in place.

Incident response undefined. When a Bedrock-powered feature generates problematic output, the organization has no defined procedure for detecting the event, containing the impact, or determining what happened. The first response is usually an ad-hoc Slack message.

Accountability gaps. There is no defined owner for each of these problems. The security team thinks it is a product team problem. The product team thinks it is a security team problem. The finance team has no visibility. The legal or compliance team was not consulted.

The five-pillar framework is designed to close each of these gaps before Bedrock moves to production, not after.

The five governance pillars and their primary control types. Each pillar has a defined decision owner and a set of artifacts required before the pillar is considered governed.

4. Pillar 1: Account Structure and Access Boundaries

4.1 Governance principle

Bedrock access should be granted at the account level, not at the individual user or role level. An account that is permitted to use Bedrock is an account where Bedrock governance applies in full. An account that is not permitted to use Bedrock should be prevented from doing so by a Service Control Policy at the AWS Organizations level.

4.2 Organizational unit design

The 50-account organization uses three organizational units (OUs) that are relevant to Bedrock governance:

• AI-Enabled OU. Accounts in this OU are permitted to use Bedrock. All five pillars of this framework apply. The OU contains accounts for the customer-facing product team (3 accounts: dev, beta, production), the internal analytics team (2 accounts: dev, production), and the data science research team (1 account: research sandbox).

• Restricted OU. Accounts in this OU are not permitted to use Bedrock. A deny SCP is applied at the OU level. This covers accounts that handle regulated data (PCI, HIPAA) where Bedrock access has not been evaluated for compliance, and shared service accounts that do not require AI capabilities.

• Sandbox OU. Accounts in this OU are permitted to use Bedrock in a limited way (no production traffic, no customer data) with relaxed IAM controls. Data science research operates here. Sandbox accounts have a hard monthly spend cap applied via AWS Budgets.

4.3 Service Control Policy design

The SCP applied to the Restricted OU denies all Bedrock API actions for all principals, with no exceptions. An illustrative SCP statement is:

{
  "Effect": "Deny",
  "Action": "bedrock:*",
  "Resource": "*",
  "Condition": {}
}

The SCP applied to the AI-Enabled OU does not grant Bedrock access (SCPs cannot grant access; that is done by IAM policies). Instead, it restricts the set of permissible Bedrock API actions to those that are on the production allowlist. Models not on the allowlist are denied via a condition key on the model ARN:

{
  "Effect": "Deny",
  "Action": [
    "bedrock:InvokeModel",
    "bedrock:InvokeModelWithResponseStream"
  ],
  "Resource": "arn:aws:bedrock:*::foundation-model/*",
  "Condition": {
    "StringNotLike": {
      "bedrock:modelId": [
        "anthropic.claude-3-5-sonnet-*",
        "amazon.titan-text-*"
      ]
    }
  }
}

This SCP ensures that even if an application role has an IAM policy that permits bedrock:InvokeModel for all models, the SCP layer will deny calls to any model not on the allowlist. The allowlist in the SCP is the authoritative production allowlist.

4.4 Decision owner and artifacts

Decision owner: Cloud governance director or AWS account owner, with security team review.

Artifacts required:

• OU structure diagram showing which accounts are in each OU and the rationale.
• SCP text for the Restricted OU deny policy.
• SCP text for the AI-Enabled OU allowlist policy, referencing the current production allowlist.
• Change procedure for adding a model to the allowlist (which requires Pillar 3 completion).

5. Pillar 2: IAM Design and Least-Privilege Model Access

5.1 Governance principle

No human user or application role should have unrestricted bedrock:* permission. Access to Bedrock should be granted through purpose-scoped IAM roles, with conditions that restrict the role to specific models and, where possible, to specific resource ARNs. Credentials must not be hardcoded. Roles must be rotated or reviewed on a schedule.

5.2 Role design for application access

Application roles that invoke Bedrock should follow these constraints:

Minimum action set. Grant only the actions required by the application. An application that invokes a model in real time needs bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. It does not need bedrock:CreateAgent, bedrock:DeleteGuardrail, or bedrock:PutModelInvocationLoggingConfiguration. Granting bedrock:* to an application role is not acceptable.

Model ARN condition. The IAM policy should include a resource condition that restricts invocation to specific model ARNs. This is a second layer of control in addition to the SCP. If the SCP is modified incorrectly, the IAM condition remains.

No inline policies on users. Bedrock permissions must not be granted via inline policies on IAM users. Use IAM roles with temporary credentials (STS) or IAM Identity Center (SSO) for human access.

IRSA for EKS workloads. For applications running on Amazon EKS, use IAM Roles for Service Accounts (IRSA) to associate a Kubernetes service account with an IAM role. The role assumes the Bedrock permissions and the application pod inherits them. This avoids the need to distribute long-lived credentials.

An illustrative least-privilege IAM policy for a production application role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockInvokeAllowedModel",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"
      ]
    }
  ]
}

5.3 Role design for console and human access

For engineers who need to access Bedrock via the console (for example, to test a prompt or review model invocation logs), grant access through IAM Identity Center with a permission set that restricts Bedrock actions to read and test operations. Do not grant bedrock:InvokeModel to console users in production accounts. Use a separate evaluation account for interactive model testing.

5.4 Bedrock invocation logging

Enable Bedrock model invocation logging for all accounts in the AI-Enabled OU. Invocation logs capture the model ID, the timestamp, the caller identity, and the input and output token counts. They optionally capture the full prompt and response (with appropriate data handling controls in place). These logs are essential for cost attribution (Pillar 4) and incident response (Pillar 5).

Configure invocation logging to write to a centralized CloudWatch log group or an S3 bucket in the security account. Use a resource-based policy to prevent accounts from disabling their own invocation logging.

5.5 Decision owner and artifacts for Pillar 2

Decision owner: CISO or security engineering lead.

Artifacts required:

• IAM role design document for each application type (Lambda, EKS, EC2, console user).
• Invocation logging configuration record (log destination, retention period, access controls).
• Role review schedule (at minimum annual; recommended quarterly for production roles).

5.6 Worked example: 50-account organization

In the 50-account organization, the customer-facing product team has three accounts. The production account has one application role per service (four roles total). Each role is scoped to the specific Bedrock model the service uses. The IAM policy for each role is generated from a Terraform module that enforces the least-privilege template: the module requires a model ARN input and refuses to generate a policy with a wildcard resource. This prevents engineers from bypassing the least-privilege requirement during infrastructure changes.

6. Pillar 3: Model Selection Gates

6.1 Governance principle

No foundation model may be used in a production workload until it has passed a formal model selection gate. The gate process evaluates the model against a standard set of criteria and produces a signed evaluation record. Approval is recorded in the production allowlist and reflected in the SCP.

The gate process serves two purposes. First, it ensures the organization understands the properties of the model it is deploying: its data handling characteristics, its content safety behavior, and its performance on the organization's use case. Second, it creates an audit trail that demonstrates due diligence if a model produces harmful output or causes a compliance issue.

6.2 Gate process

The model selection gate has six steps.

The model selection gate process. A model must complete all six steps and receive signed approval before it is added to the production allowlist and reflected in the SCP.

Step 1: Evaluation request. A team submits a model evaluation request to the governance team. The request includes: the model ID, the intended use case, the data types the model will process (including whether personal data or regulated data is involved), and the account where the model will be used.

Step 2: Risk classification. The governance team classifies the request into one of three risk tiers based on the data sensitivity and the nature of the use case:

• Tier 1 (Low risk): Internal tooling, no personal data, no regulated content. Example: internal code generation tool.
• Tier 2 (Medium risk): Customer-facing, may involve personal data, no regulated content. Example: customer support bot.
• Tier 3 (High risk): Processes regulated data (PII, PHI, financial data), or generates content with legal or compliance implications. Example: AI-assisted medical documentation.

Tier classification determines the depth of evaluation required and the approval authority.

Step 3: Technical evaluation. For Tier 1 and Tier 2, the AI/ML engineer performs a technical evaluation including: prompt injection testing, content safety evaluation using the organization's standard test suite, performance benchmarking on a representative sample of the use case inputs, and review of the model's data handling documentation (specifically whether prompt content is used for model training by the provider). For Tier 3, the technical evaluation also includes a data protection impact assessment (DPIA) and legal review.

Bedrock Guardrails should be evaluated at this stage as a mandatory control for Tier 2 and Tier 3 models. Guardrails provide content filtering, topic blocking, and sensitive information redaction that can be applied at the API layer regardless of the model's own safety features. See https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html for the current guardrail configuration options.

Step 4: Approval. The evaluation record is submitted to the approval authority:

• Tier 1: AI governance lead.
• Tier 2: AI governance lead and security engineering lead.
• Tier 3: AI governance lead, CISO, and legal counsel.

Approval is recorded in a signed evaluation record that includes the evaluation findings, any required controls (such as mandatory guardrail configuration), and an expiry date for re-evaluation (12 months for Tier 1 and Tier 2; 6 months for Tier 3).

Step 5: Allowlist update. After approval, the model ID is added to the production allowlist. The SCP is updated to include the new model ARN in the allowed list. The SCP change requires a separate approval from the cloud governance director to prevent any single approver from completing the entire gate unilaterally.

Step 6: Production deployment. The team can now deploy the model to production, subject to the IAM controls in Pillar 2 and the cost controls in Pillar 4.

6.3 Allowlist governance

The production allowlist is maintained as a version-controlled document in the organization's governance repository. Each entry includes: model ID, model ARN, date of approval, approval authority, risk tier, required controls (guardrail IDs, IAM conditions), and re-evaluation date. The allowlist is reviewed in full at least annually.

A model can be removed from the allowlist if the re-evaluation fails, if the provider changes the model's data handling terms, or if an AI incident (Pillar 5) is attributed to the model. Removal from the allowlist triggers an SCP update and a notification to all teams using the model.

6.4 Decision owner and artifacts for Pillar 3

Decision owner: AI governance lead (owns the gate process); cloud governance director (owns the SCP update).

Artifacts required:

• Model evaluation request form template.
• Risk classification criteria document.
• Technical evaluation checklist (Tier 1, Tier 2, and Tier 3 versions).
• Production allowlist (version-controlled).
• SCP change procedure.

6.5 Worked example: 50-account organization

The data science research team requests access to a new foundation model for a research project. The model will process anonymized customer behavior data to generate marketing copy suggestions. The governance team classifies this as Tier 2: customer-facing application, involves customer data (even though anonymized), generates content with brand implications.

The technical evaluation takes 3 days. The evaluator runs the standard content safety test suite (100 adversarial prompts across the organization's content categories) and reviews the provider's data handling documentation. The evaluator configures a Bedrock Guardrail with a topic block for competitor mentions and a sensitive information filter for email addresses and phone numbers, and confirms the guardrail functions correctly against the test inputs.

The approval is granted by the AI governance lead and the security engineering lead. The model is added to the allowlist with a required control: the guardrail must be applied to all production invocations of this model in this account. The SCP is updated. The research team deploys to their research sandbox account first, then promotes to the internal analytics production account after a 2-week trial.

7. Pillar 4: Cost Controls and Allocation

7.1 Governance principle

Every Bedrock cost must be attributable to a specific team, workload, and account. Cost anomalies must be detected automatically and trigger a review before the next billing cycle. Sandbox and research use must be capped to prevent unexpected spend from propagating to the organization's main Bedrock budget.

7.2 Tagging strategy

All Bedrock-related resources (knowledge bases, agents, guardrails, prompt management resources) must be tagged with at minimum:

• Team: the owning team name.
• Workload: the workload or product name.
• Environment: dev, beta, or production.
• CostCenter: the finance cost center code.

Bedrock model invocation costs are not directly taggable at the invocation level, but they appear in the account-level cost data attributed to the account. The account-to-team mapping in the organization's tagging convention provides the team-level attribution. For more granular attribution within an account, use Bedrock invocation logging (Pillar 2) to associate invocations with specific application roles, which can then be mapped to workloads.

7.3 Budget alerts

Configure AWS Budgets for each account in the AI-Enabled OU with:

• A monthly spend alert at 50% of the monthly budget (notification to the team lead).
• A monthly spend alert at 80% of the monthly budget (notification to the team lead and the cloud governance director).
• A monthly spend alert at 100% of the monthly budget (notification to the cloud governance director and finance).

For sandbox accounts, additionally configure a hard budget action that removes the bedrock:InvokeModel permission from all roles in the account when the monthly budget is exhausted. This prevents sandbox overruns from accumulating. Hard budget actions use AWS Budgets Actions, which apply an IAM policy that overrides existing permissions.

7.4 Cost Explorer and showback

Use AWS Cost Explorer to generate monthly cost reports broken down by service (Bedrock), account, and resource tag. Share these reports with each team lead as part of the monthly governance review. The governance team uses these reports to identify cost anomalies, track cost per workload over time, and forecast spend for the next quarter.

Showback (reporting costs to teams without charging them directly) is the minimum requirement. Chargeback (actual inter-team billing) is a finance decision that this framework does not mandate, but the tagging and Cost Explorer configuration in this pillar provides the data foundation for it.

7.5 Provisioned throughput governance

Provisioned throughput commitments (which reserve model capacity for a fixed monthly fee) require a separate approval process. No team may commit to provisioned throughput without approval from the cloud governance director and the finance lead, because the commitment persists for the contractual term regardless of actual usage. The governance team maintains a register of all active provisioned throughput commitments with their expiry dates.

7.6 Decision owner and artifacts for Pillar 4

Decision owner: Cloud governance director (owns budget configuration); finance lead (owns chargeback decisions).

Artifacts required:

• Tagging standard document with required tags and allowed values.
• Budget alert configuration record for each account.
• Monthly cost report template.
• Provisioned throughput approval register.

7.7 Worked example: 50-account organization

The customer-facing product team's production account has a monthly Bedrock budget of $4,000. At the end of month 3, the Cost Explorer report shows Bedrock spend of $6,200, which exceeds the budget. The 80% and 100% alerts fired but were not actioned. The governance review reveals that a code change added an additional model invocation per request without updating the cost forecast. The team updates the forecast, the product owner approves a budget increase to $7,000, and the governance team updates the Budget alert thresholds. The incident is documented and used to establish a practice of cost impact assessment for any change that adds or modifies a Bedrock invocation.

8. Pillar 5: Incident Response for AI Systems

8.1 Governance principle

An AI incident is a materially different event from a conventional infrastructure incident. The impact may be subtle (a model producing subtly biased output), widespread (a prompt injection attack causing data exposure), or delayed (a model that gradually degrades in quality over weeks). The incident response process must account for these characteristics.

8.2 What constitutes an AI incident

The organization's AI incident definition should include at minimum:

• Content safety violation: a Bedrock-powered system generates content that violates the organization's content policy or applicable regulations (for example, generates regulated financial advice, produces harmful content, or generates content that the organization's guardrails were configured to block but did not).
• Data exposure: model output contains information that should not have been accessible (for example, retrieval from a knowledge base returns a document that the requesting user should not have access to, or a model reproduces training data containing personal information).
• Cost anomaly: Bedrock spend in any account exceeds 150% of the monthly budget within a billing period, suggesting runaway automation, a prompt injection attack that generates high token volumes, or a configuration error.
• Availability impact: a Bedrock service disruption (from AWS or from the organization's integration layer) causes a production feature to be unavailable for more than the agreed SLA.
• Model quality degradation: an application monitoring metric (for example, escalation rate, user satisfaction score, or automated evaluation score) drops below a threshold that indicates the model is no longer performing at an acceptable level, potentially due to a model update by the provider.

8.3 Detection

AI incidents may be detected through several mechanisms:

Guardrail intervention logs. Bedrock Guardrails log each intervention (blocked content, filtered response, sensitive data redaction). A sudden spike in guardrail interventions may indicate a prompt injection attempt or an unusual usage pattern.

CloudWatch metrics. Model invocation errors, latency spikes, and token volume anomalies are visible in CloudWatch. Configure alarms for each of these metrics in each production account. The monitoring configuration is documented at https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html.

Application-level monitoring. Escalation rate, user feedback, and automated evaluation scores in the application layer are often the first signal of a model quality problem. These metrics must be fed into the organization's observability stack and alerted on.

User reports. Users who observe unexpected or harmful model output should have a clear channel to report it. This channel must be monitored and reports must be triaged within 24 hours.

8.4 Containment

The first priority in an AI incident is to stop the impact. Containment options in order of severity:

1. Guardrail configuration update. For a content safety violation, update the Bedrock Guardrail to block the specific topic or content pattern. This takes effect immediately without a code deployment and without disabling the service.

1. Model invocation disable. For a severe content safety violation or data exposure, disable the application's ability to invoke the model by modifying the IAM role (remove bedrock:InvokeModel from the role policy). This disables the AI feature but leaves the rest of the application functional.

1. Account-level deny. For an organization-wide threat (for example, a prompt injection attack that is propagating across accounts), apply an SCP deny to the affected accounts. This is the most disruptive option and requires the cloud governance director's authorization.

1. Traffic diversion. For an availability incident caused by a Bedrock regional outage, redirect traffic to a fallback region or to a degraded-mode version of the application that does not use Bedrock.

Containment actions must be authorized and executed by named individuals in the incident response runbook. No containment action should be taken unilaterally without logging the action and notifying the incident commander.

8.5 Post-incident review

Every AI incident that reaches containment level 2 or above must have a post-incident review (PIR) within 5 business days. The PIR produces:

• A timeline of the incident from first detection to containment.
• A root cause analysis.
• A list of corrective actions with owners and due dates.
• An assessment of whether the incident should trigger a re-evaluation of the affected model (Pillar 3).

The PIR document is stored in the governance repository and is reviewed at the next monthly governance meeting.

8.6 Decision owner and artifacts for Pillar 5

Decision owner: CISO (owns incident response policy); AI governance lead (owns AI-specific detection and triage procedures).

Artifacts required:

• AI incident definition (what events qualify, with examples).
• Incident response runbook with named roles (incident commander, communications lead, technical lead).
• Containment playbook with authorization levels for each containment action.
• PIR template.
• Communication template for user notifications.

8.7 Worked example: 50-account organization

The customer-facing product team's support bot returns a response that includes a customer's email address in the context of an answer about account settings. This is detected by a user who reports it via the designated reporting channel. The security team classifies it as a data exposure incident (containment level 2). The technical lead disables model invocation for the support bot role within 20 minutes of the report. Investigation reveals that a knowledge base document containing customer data was inadvertently included in the RAG corpus. The PIR recommends a document classification review before any document is added to a production knowledge base, and this recommendation is added as a mandatory check to the model selection gate process for RAG workloads.

9. Operational Consequences and Review Cadence

The five-pillar framework is not a one-time setup. It requires ongoing operational commitment from named owners. The following review cadence is recommended:

Monthly:

• Cloud governance director reviews the Cost Explorer report for all AI-Enabled OU accounts.
• AI governance lead reviews any new model evaluation requests and gates from the prior month.
• CISO reviews any AI incidents from the prior month and the status of corrective actions from prior PIRs.

Quarterly:

• Full review of the production allowlist. Any model whose approval is within 60 days of expiry is flagged for re-evaluation.
• Review of IAM role permissions for all production Bedrock roles. Confirm no role has permissions broader than documented.
• Budget alert threshold review. Adjust thresholds based on the actual spend trend from the prior quarter.
• Escalation matrix review for all Bedrock-powered production features (see Pillar 5 runbook).

Annually:

• Full SCP review. Confirm the allowlist in the SCP matches the production allowlist document.
• Full role design review. Confirm all application roles follow the least-privilege template.
• Governance framework review. Update this framework for changes in Bedrock capabilities, organizational structure, or regulatory requirements.

The operational cadence must be written into the job responsibilities of the named owners, not treated as an optional activity. If the governance framework is not maintained, it degrades: SCPs become stale, allowlists accumulate unevaluated models, and budgets drift from actuals.

10. Limitations

This framework has specific limitations that organizations should understand before adopting it.

SageMaker custom models. Models trained and deployed on Amazon SageMaker are not governed by this framework. SageMaker custom models require a separate governance framework covering model training data governance, model versioning, and inference endpoint security. The two frameworks should be designed to be complementary.

Non-AWS AI services. Use of OpenAI, Anthropic API (direct), Google Vertex AI, Azure OpenAI, or any other non-AWS AI service is outside the scope of this framework. Organizations that use multiple AI providers need a broader AI governance policy that this framework can feed into as the AWS Bedrock-specific implementation.

Bedrock service evolution. Amazon Bedrock is actively evolving. The framework was verified against AWS documentation as of November 2026 (sourceCheckedDate: 2026-11-05). Services and features have changed: Amazon Bedrock Agents Classic is in maintenance mode and new signups are no longer accepted; new agentic workloads should use Amazon Bedrock AgentCore. As additional changes occur, the governance team should assess whether they require updates to existing pillars or new coverage areas.

Organizational complexity. This framework is designed for a 50-account organization with three distinct business units. Very large organizations (500+ accounts, 10+ business units) may need to distribute governance ownership more granularly. The pillar structure remains valid but the approval chains and OU design will need to be adapted.

Regulatory compliance. This framework provides a governance structure but does not constitute legal, compliance, or regulatory advice. Organizations in regulated industries (healthcare, financial services, public sector) must layer their applicable regulatory requirements on top of this framework. The framework is designed to be compatible with NIST AI Risk Management Framework (NIST AI RMF) principles (see https://www.nist.gov/artificial-intelligence/ai-risk-management-framework) but is not a full implementation of that framework.

11. Review Checklist

Use this checklist to assess the current state of Bedrock governance in your organization. Each item maps to a specific pillar.

Pillar 1: Account Structure

• [ ] AWS Organizations OU structure separates AI-Enabled, Restricted, and Sandbox accounts.
• [ ] A deny SCP is applied to the Restricted OU blocking all bedrock:* actions.
• [ ] An allowlist SCP is applied to the AI-Enabled OU restricting model invocation to approved model ARNs.
• [ ] The OU structure and SCP texts are documented and version-controlled.

Pillar 2: IAM Design

• [ ] No application role has bedrock:* permission.
• [ ] All production application roles are scoped to specific model ARNs.
• [ ] Bedrock invocation logging is enabled for all accounts in the AI-Enabled OU.
• [ ] Invocation logs are stored in a centralized, access-controlled location.
• [ ] IAM roles are reviewed at least annually.

Pillar 3: Model Selection Gates

• [ ] No model is in production use without a completed evaluation record.
• [ ] The production allowlist is documented and version-controlled.
• [ ] The allowlist in the SCP matches the production allowlist document.
• [ ] All Tier 2 and Tier 3 models have a Bedrock Guardrail configured as a required control.
• [ ] A re-evaluation schedule exists for each allowlisted model.

Pillar 4: Cost Controls

• [ ] All Bedrock-related resources are tagged with the required tags.
• [ ] AWS Budgets alerts are configured for each AI-Enabled OU account.
• [ ] Sandbox accounts have a hard budget action to prevent overruns.
• [ ] Monthly Cost Explorer reports are shared with team leads.
• [ ] A provisioned throughput approval register exists.

Pillar 5: Incident Response

• [ ] An AI incident definition is documented and acknowledged by the CISO.
• [ ] An incident response runbook exists with named roles.
• [ ] Containment playbook exists with authorization levels.
• [ ] CloudWatch alarms are configured for model invocation errors, latency, and token volume in all production accounts.
• [ ] A user reporting channel for model output issues is published and monitored.
• [ ] A PIR template exists and has been used for at least one test exercise.

12. Primary References

The following primary sources were used in developing this framework. Each should be verified against the current documentation before implementing specific configuration, as AWS documentation is updated continuously.

1. Amazon Bedrock IAM security documentation -- covers IAM condition keys, resource ARN formats, and least-privilege policy design for Bedrock, source checked 2026-11-05.

1. Amazon Bedrock Guardrails documentation -- covers guardrail configuration, content filtering categories, sensitive information types, and API integration, source checked 2026-11-05.

1. AWS Organizations SCP documentation -- covers SCP policy syntax, effect precedence, and condition key usage for service-level restrictions, source checked 2026-11-05.

1. NIST AI Risk Management Framework -- provides the risk classification vocabulary and governance principle structure that informed the five-pillar design, source checked 2026-11-05.

1. Amazon Bedrock monitoring and CloudWatch documentation -- covers invocation logging configuration, CloudWatch metric names, and alarm configuration for Bedrock, source checked 2026-11-05.

1. AWS Cost Management and Cost Explorer documentation -- covers Cost Explorer configuration, tagging strategy for cost attribution, and AWS Budgets Actions for hard spend caps, source checked 2026-11-05.

13. Cross-Pillar Governance Interaction

The five pillars are not independent. Changes in one pillar create obligations in others, and governance gaps tend to compound across pillar boundaries.

Account structure changes (Pillar 1) trigger IAM review (Pillar 2). When a new account joins the AI-Enabled OU, the existing SCP applies immediately. However, IAM roles in the new account may not follow the least-privilege template. Any account added to the AI-Enabled OU requires an IAM audit within 30 days of joining.

Model selection approvals (Pillar 3) determine cost budget inputs (Pillar 4). A Tier 2 model approval must include a cost estimate based on projected invocation volume before the model is added to the allowlist. Without a cost estimate, budget alerts in Pillar 4 have no meaningful threshold to compare against.

Incidents (Pillar 5) trigger model re-evaluation (Pillar 3). A content safety incident attributed to a specific model must trigger a re-evaluation of that model's allowlist entry, regardless of the scheduled re-evaluation date. The post-incident review (PIR) documents this triggering condition.

Invocation logging (Pillar 2) enables incident detection (Pillar 5). If invocation logging is disabled or misconfigured, data exposure incidents may not be detectable until a user reports them. Pillar 2 logging configuration is a prerequisite for Pillar 5 detection capability.

Maintaining cross-pillar coherence requires a governance lead who reviews all five pillars together at the monthly governance meeting, not separately by functional owner.

14. Practical Next Steps

For a governance director or CISO beginning this work, the following sequence is recommended:

Week 1: Inventory. Identify all accounts in the AWS organization where Bedrock is currently enabled or where model invocation logs show activity. Identify all models in current use. This inventory becomes the starting point for the production allowlist and the OU remediation plan.

Week 2: Account structure. Assign each account to the correct OU. Apply the Restricted OU deny SCP to accounts that should not have Bedrock access. Do not apply the AI-Enabled OU allowlist SCP until the allowlist is defined.

Week 3: IAM audit. Review IAM policies in all accounts where Bedrock is currently in use. Identify any role with bedrock:* or wildcard resource permissions. Remediate in order of environment (production first, then beta, then development).

Week 4: Retrospective allowlist.** For each model currently in use, conduct an expedited evaluation (using the Tier classification criteria) and create a retrospective evaluation record. This establishes the initial production allowlist. Models that cannot be evaluated within the week are removed from the SCP allowlist until their evaluation is complete.

Month 2: Cost controls and monitoring. Implement tagging, budget alerts, and Cost Explorer reports. Configure CloudWatch alarms for all production accounts. This pillar is operational from month 2 onward.

Month 3: Incident response readiness. Document the AI incident definition, the runbook, and the containment playbook. Conduct a tabletop exercise using a simulated content safety incident. Document the results and use them to refine the runbook.

From month 3, the organization operates under the full five-pillar framework with a monthly governance review as the ongoing operating mechanism.