Checks

Bedrock guardrails have the Prompt attack filter set to HIGH strength to detect and block injection and jailbreak patterns. Guardrails missing this setting or using lower strengths are identified.

Amazon Bedrock guardrails provide reusable safety policies for filtering harmful or unwanted content in model inputs and outputs.

This evaluation checks whether at least one guardrail exists in each successfully scanned region. It does not verify that guardrails are attached to agents or passed on individual model invocation API calls.

Bedrock guardrails use sensitive information filters to block or mask detected PII and custom pattern matches in prompts and responses.

The evaluation looks for guardrails with this filtering configured.

Each data source of a Bedrock knowledge base can set serverSideEncryptionConfiguration.kmsKeyArn, which encrypts the transient storage used while documents are chunked and embedded, rather than relying on an AWS-owned key.

Bedrock model invocation logging captures request, response, and metadata for Converse, ConverseStream, InvokeModel, and InvokeModelWithResponseStream calls per Region, delivering records to CloudWatch Logs and/or S3 when configured.

Bedrock model invocation logs are stored in encrypted destinations: S3 buckets with bucket encryption and CloudWatch Logs groups protected by an AWS KMS key.

This evaluates whether configured log targets enforce encryption at rest for request/response content and associated metadata.

Bedrock prompts should be encrypted at rest with a customer-managed KMS key (CMK) rather than the AWS-owned default key. Prompts can contain sensitive instructions, business logic, and references to downstream tooling that warrant tenant-controlled key material and auditable access via AWS KMS.

Bedrock Prompt Management enables centralized creation, versioning, and governance of prompts used with foundation models.

This region-level check verifies whether at least one managed prompt exists in each scanned region, used as an adoption signal for Prompt Management. The presence of a prompt does not by itself guarantee that every application prompt is managed.

Amazon VPCs are evaluated for interface VPC endpoints to all Bedrock services: bedrock, bedrock-runtime, bedrock-agent, bedrock-agent-runtime, and bedrock-mantle (OpenAI-compatible API). Only endpoints in available state are considered. Their presence indicates private Bedrock API connectivity over AWS PrivateLink within the VPC.

BigQuery datasets use Customer-Managed Encryption Keys (CMEK) rather than Google-managed encryption. The evaluation identifies datasets configured to use a customer-managed key for data-at-rest protection.

BigQuery datasets are evaluated for exposure to public identities. The finding highlights datasets that grant any role to allUsers or allAuthenticatedUsers, which makes the dataset publicly accessible beyond intended principals.

BigQuery tables use customer-managed encryption keys (CMEK) for at-rest encryption. The evaluation identifies tables lacking a configured Cloud KMS key, indicating use of default Google-managed encryption instead.

OCI block volumes use Customer-Managed Keys (CMK) from Vault for at-rest encryption instead of Oracle-managed keys.

Identifies whether a block volume has a customer-managed key associated for its encryption.

Boot volumes use customer-managed keys (CMEK) when a Vault key is assigned (kms_key_id present), rather than default Oracle-managed encryption.

OpenStack block storage snapshot metadata is evaluated to detect sensitive data such as passwords, API keys, secrets, and private keys. Snapshot metadata is accessible via the OpenStack API to any user with access to the project. Storing secrets in metadata exposes them to unauthorized access through the API.

OpenStack block storage snapshots are evaluated to verify they reference existing volumes. Orphaned snapshots (whose source volumes have been deleted) may contain stale data, incur unnecessary storage costs, and can be overlooked during security reviews. They may also contain sensitive data from deleted volumes that is no longer being managed.

OpenStack block storage volumes are evaluated to verify that at least one backup exists. Volume backups provide disaster recovery capability by storing volume data in a separate storage backend (e.g., Swift or Ceph). Without backups, data loss from volume corruption, accidental deletion, or infrastructure failure is irrecoverable.

OpenStack block storage volumes (Cinder) are evaluated to verify that encryption is enabled. Volume encryption protects data at rest by encrypting the entire volume using a key managed by the OpenStack Key Manager (Barbican). Without encryption, data stored on volumes is vulnerable to unauthorized access if the underlying storage is compromised.

OpenStack block storage volume metadata is evaluated to detect sensitive data such as passwords, API keys, secrets, and private keys. Volume metadata is accessible via the OpenStack API to any user with access to the project. Storing secrets in metadata exposes them to unauthorized access through the API.

OpenStack block storage volumes are evaluated to verify that multi-attach is not enabled. Multi-attach allows a volume to be attached to multiple instances simultaneously, increasing the attack surface and potentially leading to data corruption or unauthorized access from compromised instances.

OpenStack block storage volumes are evaluated to verify they are attached to at least one instance. Unattached volumes may indicate orphaned resources that are no longer in use but continue to incur storage costs and may contain sensitive data without active monitoring or access controls.

The domain-wide Google Calendar configuration warns users when they invite guests from outside the organization to an event. This prompt gives users a chance to reconsider before sharing meeting details with external parties, reducing the likelihood of accidental information disclosure through calendar invitations.

The domain-wide default for primary calendars shares only free/busy information with external users. When external sharing is set to share full event details, sensitive information such as meeting titles, attendees, locations, and descriptions is exposed to users outside the organization.

The domain-wide default for secondary calendars shares only free/busy information with external users. Secondary calendars are additional calendars users create beyond their primary calendar (e.g., for projects, teams, or personal events), and are commonly used to organize sensitive or focused activities that should not be visible to external parties.