Checks

AWS Lambda function URLs are assessed to determine whether AuthType enforces AWS IAM authentication or permits public invocation.

Applies to functions with a function URL and highlights when requests must be authenticated and authorized via IAM principals.

AWS Lambda functions use only layers published within the same AWS account, rather than layers owned by external accounts.

A Lambda layer bundles shared code or dependencies that are injected into the function execution environment at runtime.

Lambda functions using obsolete runtimes-such as python3.8, nodejs14.x, go1.x, ruby2.7-are identified against a curated list of deprecated runtime identifiers.

AWS Lambda functions attached to a VPC use subnets that span at least the required number of Availability Zones (2 by default).

The evaluation counts the unique AZs of the function's configured subnets.

Lambda layer content is analyzed for embedded secrets across files in the layer's package, detecting patterns like API keys, passwords, tokens, and connection strings. Findings reference file names and line numbers where potential secrets appear.

AWS Backup is assessed for the existence of at least one backup plan that schedules and retains recovery points for selected resources.

The evaluation determines whether any plan is configured; when none is found-even if backup vaults exist-the absence of a plan is noted.

AWS Backup recovery points are evaluated for encryption at rest using the backup vault's KMS configuration. Items lacking vault-level encryption are highlighted, regardless of the source resource's encryption.

AWS Backup environments with existing backup plans are assessed for the presence of at least one report plan that generates jobs or compliance reports.

AWS Backup vaults are evaluated for encryption at rest with AWS KMS. The finding highlights vaults without a configured KMS key protecting stored recovery points.

AWS Backup in the account/region includes at least one backup vault that stores and organizes recovery points for use by backup plans and copies.

AWS Batch job definitions are analyzed for plaintext secrets placed in container environment variables and command parameters. It identifies values that resemble credentials (keys, tokens, passwords) within job definitions.

Bedrock agents should have an associated guardrail for their sessions. The evaluation identifies agents without a guardrail linked for input/output screening during interactions.

Bedrock Agent execution roles (agentResourceRoleArn) should grant only the minimum permissions the agent needs. The evaluation FAILs when the role has an AWS-managed *FullAccess policy attached, has an inline statement allowing broad actions on Resource: "*", or has no permissions boundary configured.

Every Bedrock Agent assumes the role in its agentResourceRoleArn. That role must belong to exactly one agent, so no agent inherits another's permissions.

Bedrock API keys linked to IAM users are evaluated for excessive permissions, including policies that grant full access (* or bedrock:*) or enable privilege escalation. The finding highlights keys whose attached or inline policies provide broad or escalating capabilities.

AWS recommends Amazon Bedrock long-term API keys only for exploration; production workloads should use short-term API keys (session-scoped, valid up to 12 hours). This check fails for any active long-term Bedrock API key, escalating to critical severity when configured to never expire. Already-expired keys pass — they can no longer authenticate.

Bedrock custom models produced by model customization can be encrypted at rest with a customer-managed KMS key rather than resting under an AWS-owned key the organization cannot audit, rotate, or revoke.

IAM roles (excluding service roles) are evaluated for attachment of the AWS-managed AmazonBedrockFullAccess policy.

This policy grants unrestricted access to all Amazon Bedrock actions and resources.

Bedrock guardrails can attach a contextualGroundingPolicy whose filters score each response for GROUNDING (supported by the retrieved source) and RELEVANCE (answers the question asked). Both filter types must be enabled, set to action: BLOCK, and carry a threshold above 0.

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.