[New Check]: AWS Organizations enables and attaches Bedrock policies

Existing check search

• I have searched existing issues, Prowler Hub, and the public roadmap, and this check does not already exist.

Provider

AWS

New provider name

No response

Service or product area

organizations

Suggested check name

organizations_bedrock_policy_enabled_and_attached

Context and goal

• Source control: BR-15 — Cross-Account Guardrails Enforcement.
• Semantic requirement: Verifies organization-level guardrails are configured using AWS Organizations Amazon Bedrock policies (the BEDROCK_POLICY policy type) for centralized safety control enforcement across all accounts. Checks if running in the AWS Organizations management account, validates the Bedrock policy type is enabled at the organization root, and verifies that Bedrock policies are attached.
• Valid cloud-posture assertion: The Organizations collector does not inventory BEDROCK_POLICY type enablement or attachments. The proposed check evaluates a durable AWS control-plane property with deterministic resource-level or regional posture semantics; it does not treat optional product adoption or manual governance evidence as failure.
• Resource scope: The AWS Organizations management account, organization root, and BEDROCK_POLICY policies.
• Initiative tracker: https://github.com/prowler-cloud/prowler/issues/12597

Expected behavior

• Resource or scope to evaluate: The AWS Organizations management account, organization root, and BEDROCK_POLICY policies.
• PASS when: BEDROCK_POLICY is enabled at the root and at least one Bedrock policy is attached to an in-scope target.
• FAIL when: the type is disabled or no Bedrock policy is attached.
• MANUAL when: Required detail or policy data is unavailable or indeterminate after collection; never emit a false PASS for unreadable in-scope data.
• No resources: Return no findings. For regional/account-level posture checks, return no finding when the audited service has no relevant resources in that region.
• Error behavior: Preserve Prowler's normal service-error reporting and do not convert AccessDenied, unsupported-region responses, or partial inventory into PASS.

References

• Immutable AWS source snapshot: https://github.com/aws-samples/sample-aiml-security-assessment/tree/0e2c5b48a6016a77e9d376bc17f41ef95cb2635d
• Source implementation for BR-15: https://github.com/aws-samples/sample-aiml-security-assessment/tree/0e2c5b48a6016a77e9d376bc17f41ef95cb2635d
• Audited Prowler snapshot: https://github.com/prowler-cloud/prowler/tree/2b81fdcc04c298bc476086b4082bd8fa4a9f1dd5
• Required AWS APIs/collector inputs: organizations:DescribeOrganization; organizations:ListRoots; organizations:ListPolicies; organizations:ListTargetsForPolicy.
• Full initiative and classification rationale: https://github.com/prowler-cloud/prowler/issues/12597

Suggested severity

High

Additional implementation notes

• Collector change: Extend the Organizations collector with policy-type state and BEDROCK_POLICY inventory/attachments.
• Dependencies: Organizations policy-type collector
• Emit one finding per resource unless the scope above explicitly defines a regional/account-level posture result.
• Add metadata and implementation files following the AWS check conventions, plus collector/model updates where required.
• Acceptance tests must cover PASS, FAIL, unreadable/indeterminate MANUAL behavior, empty inventory, API error handling, and all stated edge conditions.
• Tests must prove the exact AWS response fields above and ensure unrelated resources/configurations are not reported.
• Keep this CheckID atomic; do not combine it with adjacent assertions that have different resources, APIs, or remediation.

Validation evidence required

Before this implementation can be considered ready for merge:

• The pull request must complete a CodeRabbit review, and all actionable findings must be addressed or explicitly resolved with technical justification.
• The contributor must provide execution evidence for one PASS case and one FAIL case using representative AWS resources. The evidence must include the executed Prowler command and the resulting finding output, demonstrating the expected status and status_extended message.
• All execution evidence must be censored before publication. Account IDs, resource names, ARNs, credentials, tokens, endpoints, and any other sensitive or identifying information must be visibly masked or removed from screenshots, logs, and command output.
• Unit tests are required, but they do not replace this runtime evidence.