Checks

IAM users have identity-based policies attached directly (managed or inline) instead of inheriting permissions via groups or roles.

IAM identities with the AWS managed policy AWSCloudShellFullAccess attached are identified across users, groups, and roles.

This indicates principals are granted cloudshell:* on *, enabling full CloudShell features, including environment startup and file transfer.

Customer-managed IAM policies are examined for Allow statements granting bedrock-agentcore:GetWorkloadAccessToken, GetWorkloadAccessTokenForJWT or GetWorkloadAccessTokenForUserId over resources that reach a workload identity other than the caller's own -- *, or an AgentCore ARN whose resource field wildcards past workload-identity-directory.

Custom IAM policies are reviewed for statements that grant full CloudTrail access via the cloudtrail:* wildcard, indicating unrestricted permission to all CloudTrail actions.

Customer-managed IAM policies are examined for statements that grant AWS KMS full access using kms:*. The focus is on policies allowing service-wide actions rather than narrowly scoped, key-specific permissions.

Customer-managed IAM policies are examined for statements that grant aws-marketplace:Subscribe on all resources (*). This action controls the ability to subscribe to AWS Marketplace products, including Amazon Bedrock foundation models, and should be scoped to specific product ARNs to enforce least privilege.

Customer-managed IAM policies are examined for Allow statements granting iam:PassRole over every role -- Resource *, or an IAM ARN whose resource field is nothing but wildcards -- where the passed role can reach Bedrock AgentCore: the statement pins iam:PassedToService to an AgentCore principal, or sets no such condition while the policy allows an AgentCore action.

IAM roles granted Bedrock permissions are evaluated for recent service usage.

Roles whose last Bedrock access exceeds the configured threshold (default 60 days) or that have never accessed Bedrock are flagged, indicating stale permissions that should be reviewed.

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

Attachment indicates the role holds unrestricted permissions across services and resources.

IAM roles are assessed for the AWS-managed ReadOnlyAccess policy combined with a trust policy that allows external AWS principals or *. This identifies roles that expose broad read permissions to other accounts.

IAM service role trust policies restrict AWS service principals to expected sources using global condition keys like aws:SourceArn or aws:SourceAccount, avoiding overly broad sts:AssumeRole trust relationships.

Trust-policy statements letting an AWS service principal call sts:AssumeRole confine the request source to one account -- via aws:SourceAccount, an account-bearing aws:SourceArn, or an organization-scoped source. Scope: statements whose condition binds no account, and trust policies that are not a plain service role. Unconditional service roles go to the related check.

AWS Organizations uses centralized root credentials management to control root user credentials across member accounts.

This finding evaluates whether the organization has enabled the RootCredentialsManagement feature to centrally govern presence and recovery of root passwords, access keys, signing certificates, and MFA.

AWS root user credentials are assessed for MFA status and device type. The check detects whether MFA is absent or implemented with a virtual device instead of hardware MFA on the root user, and notes when centralized root credential management is in effect.

AWS root user with active credentials is assessed for MFA activation. The evaluation considers whether the root identity has a password or access keys and whether MFA is enabled.

If centralized root access is enabled in Organizations, the presence of individual root credentials is also noted.

IAM user access keys are assessed via the credential report. For each active key, the last_rotated timestamp is compared to 90 days; keys exceeding this age are identified. Users without keys or with only recent rotations are noted.

IAM roles with the AWS managed SecurityAudit policy (arn:aws:iam::aws:policy/SecurityAudit) are identified. The focus is on whether a role exists that grants read-only visibility into security-relevant configuration across AWS services.

Presence of an IAM role that has the AWS managed AWSSupportAccess policy attached, designating a support role for interacting with AWS Support Center and related tooling.

IAM users are evaluated for active access keys whose last-used timestamp exceeds max_unused_access_keys_days (default 45). Users without access keys, or whose keys were used within this window, are reported separately.

IAM users granted Bedrock permissions are evaluated for recent service usage.

Users whose last Bedrock access exceeds the configured threshold (default 60 days) or that have never accessed Bedrock are flagged, indicating stale permissions that should be reviewed.

IAM users granted SageMaker permissions are evaluated for recent service usage.

Users whose last SageMaker access exceeds the configured threshold (default 90 days) or that have never accessed SageMaker are flagged, indicating stale permissions that should be reviewed.

IAM users are evaluated for a direct attachment of the AWS managed policy AdministratorAccess. The finding identifies identities where this policy appears among the user's attached policies.

IAM users with console access are evaluated by password_last_used. Inactivity beyond max_console_access_days (default 45) marks stale console access.

Users without console access are excluded.

IAM users are evaluated for hardware MFA enrollment, identifying physical tokens or security keys and distinguishing them from virtual or SMS MFA, as well as users without any MFA.