Checks

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.

Project IAM assignments are analyzed for Cloud KMS separation of duties: principals simultaneously granted roles/cloudkms.admin and any of roles/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, or roles/cloudkms.cryptoKeyDecrypter.

Google Cloud IAM policies are evaluated to find principals granted both roles/iam.serviceAccountAdmin and roles/iam.serviceAccountUser within a project. Service-account related roles are expected to be segregated so that service account lifecycle management is distinct from their use or impersonation.

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.

Azure subscription role assignments granting User Access Administrator are identified to surface principals able to manage access (Azure RBAC) at that scope.

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.

The Huawei Cloud account (root/domain owner) should enforce MFA. Because the domain owner is not a listable IAM user, root MFA is assessed through the account's operation protection policy, which requires MFA verification (virtual MFA, SMS, or email) before critical operations such as deleting resources or managing credentials can be performed.

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.

Google Cloud service accounts with high-privilege IAM roles are identified, including roles/owner, roles/editor, or any role containing admin. The evaluation looks for service accounts bound to these roles in IAM policies across the project hierarchy.

IAM service accounts do not have keys of type USER_MANAGED; only Google-managed keys (or no keys) are present.

GCP IAM service account user-managed keys are evaluated by last rotation. Keys of type USER_MANAGED older than 90 days are identified; those rotated within 90 days align with the expected rotation cadence.

User-managed service account keys with no recorded activity during the last max_unused_account_days are identified using key-usage metrics per service account.

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.