Securing Amazon Bedrock and SageMaker Endpoints: A Practitioner's Guide

In November 2025, a Sysdig research team watched an attacker compromise an AWS environment, enumerate Amazon Bedrock, disable model invocation logging, and achieve full administrator privileges in under ten minutes. The initial access vector was credentials left in a publicly accessible S3 bucket. According to the Tenable Cloud AI Risk Report 2025, 91% of organizations using Amazon SageMaker have root access enabled on at least one notebook instance, and 14% of Bedrock users have at least one AI training bucket with no public access block configured. The controls that protect your Bedrock endpoints and SageMaker inference deployments are not exotic or complex. Most of them are extensions of IAM, KMS, and VPC patterns you are already applying to other workloads. What is missing in most environments is systematic, deliberate application of those controls to AI services from day one.

Why AI Service Security Demands Immediate Attention

Amazon Bedrock and Amazon SageMaker are the two primary AWS services for production AI and machine learning workloads. Bedrock gives you access to foundation models from Anthropic, Meta, Mistral, Amazon, and others through a managed API. SageMaker gives you the full ML lifecycle: data preparation, model training, evaluation, and inference endpoint deployment. Both services are now enterprise standards, and both have become serious attack targets.

The Sysdig Threat Research Team documented an attacker who compromised an AWS environment and reached full administrator privileges in less than ten minutes. The attacker enumerated Amazon Bedrock, confirmed model invocation logging was disabled, and invoked multiple foundation models including Claude, Llama, and DeepSeek R1. They created Lambda backdoors to mint Bedrock credentials and attempted to spin up GPU instances for unauthorized model training.

This is not a theoretical scenario. The Tenable Cloud AI Risk Report 2025 found that approximately 70% of cloud AI workloads contain at least one unremediated vulnerability, and 91% of Amazon SageMaker users have at least one notebook instance with default root access enabled. The report also found that 14.3% of organizations using Amazon Bedrock training buckets have at least one bucket without S3 Block Public Access configured.

The shared responsibility model applies here the same way it does for every other AWS service. AWS secures the underlying infrastructure. You are responsible for IAM configuration, network exposure, encryption, logging, and runtime monitoring. The sections below walk through each security domain with concrete configurations you can apply immediately.

IAM: Least Privilege for Bedrock and SageMaker Roles

Why Default Roles Are Risky

When you get started with Bedrock or SageMaker through the console, AWS often suggests broad managed policies or creates execution roles with wide permissions. AmazonSageMakerFullAccess is a common starting point. It includes permissions that a production inference endpoint does not need, such as the ability to create new training jobs, modify studio domains, or access arbitrary S3 buckets across your account. Keeping that policy on a production role means a compromised endpoint can be used to pivot to training infrastructure, exfiltrate data, or modify models in place.

Scoping Bedrock IAM Policies

A Bedrock execution role that only needs to invoke specific foundation models should look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Notice the use of a condition to lock the policy to a specific region. This prevents credential abuse from regions you do not operate in, which is a common tactic in LLMjacking attacks where adversaries switch regions to evade detection.

Scoping SageMaker Endpoint Roles

A SageMaker model execution role for a specific inference endpoint should only allow access to the exact S3 path where model artifacts are stored, the specific KMS key used to encrypt them, and ECR access limited to the image it needs. Do not share a single SageMaker execution role across multiple endpoints or across training and inference workloads.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-model-artifacts-bucket/prod-model-v3/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability"
      ],
      "Resource": "arn:aws:ecr:us-east-1:123456789012:repository/my-inference-image"
    }
  ]
}

Use IAM Access Analyzer to identify and remove unused permissions. Regular audits using Access Analyzer are essential to finding permission drift in long-running environments where policies accumulate over time.

Service Control Policies for Organizational Guardrails

If you run Bedrock or SageMaker workloads across multiple AWS accounts in an organization, add Service Control Policies at the OU level to enforce guardrails that individual account administrators cannot override. A useful SCP prevents any principal from disabling Bedrock model invocation logging or SageMaker VPC endpoint requirements:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockLoggingDisable",
      "Effect": "Deny",
      "Action": [
        "bedrock:DeleteModelInvocationLoggingConfiguration"
      ],
      "Resource": "*"
    }
  ]
}

VPC Isolation and Network Controls

The Default Network Posture Problem

SageMaker notebooks default to direct internet access, and one industry report found this configuration present in 97% of SageMaker deployments. Combined with permissive IAM, direct internet access on a notebook instance is an entry point for attackers. Training jobs that run without VPC isolation can be intercepted or used to inject backdoors into the resulting model artifact.

To avoid making your data and model containers accessible over the internet, create a private VPC with no internet gateway. Network connectivity with AWS services should be provided using VPC endpoints and PrivateLink. This eliminates the need for internet gateways or NAT devices, keeps all traffic within the AWS network backbone, and allows you to monitor all network traffic through VPC flow logs.

Deploying SageMaker Endpoints Inside a Private VPC

When you create a SageMaker model and deploy it to an endpoint, pass the VpcConfig parameter to specify the private subnets and security groups your endpoint containers will use:

import boto3

sm = boto3.client("sagemaker", region_name="us-east-1")

sm.create_model(
    ModelName="prod-llm-endpoint-v3",
    ExecutionRoleArn="arn:aws:iam::123456789012:role/SageMakerEndpointRole",
    PrimaryContainer={
        "Image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-inference:latest",
        "ModelDataUrl": "s3://my-model-artifacts-bucket/prod-model-v3/model.tar.gz",
    },
    VpcConfig={
        "Subnets": [
            "subnet-0123456789abcdef0",
            "subnet-0123456789abcdef1"
        ],
        "SecurityGroupIds": [
            "sg-0123456789abcdef0"
        ]
    },
    EnableNetworkIsolation=True
)

Setting EnableNetworkIsolation=True prevents the inference container from making any outbound network calls whatsoever. Use this for endpoints that do not need to call external APIs at inference time. For endpoints that need to call other AWS services, remove network isolation and route those calls through interface VPC endpoints instead.

Required VPC Endpoints for SageMaker and Bedrock

When running in a VPC with no internet gateway, you need interface VPC endpoints for the AWS services your workloads call. The minimum set for a SageMaker deployment is:

For Bedrock workloads, add:

Amazon SageMaker Unified Studio now supports AWS PrivateLink, providing private connectivity between your VPC and SageMaker Unified Studio without routing customer data over the public internet.

Security Group Configuration

Apply tight security groups to your SageMaker endpoint network interfaces. The inference endpoint does not need to accept inbound connections on arbitrary ports. It communicates with callers through the SageMaker Runtime API via the VPC endpoint, so the security group for the endpoint itself should have minimal or no direct inbound rules. Outbound rules should restrict traffic to only the VPC endpoint interface IPs for the services it calls.

Bedrock Guardrails: Application-Layer Controls

Bedrock Guardrails is the primary mechanism for enforcing content and behavioral policies on your generative AI applications. It sits as a layer between user input and the foundation model, and between the foundation model output and your application, evaluating both directions against your configured policies.

The Six Policy Types

Bedrock Guardrails offers six primary policy types. Content Filters address harmful content categories including hate speech, insults, violence, and misconduct. Prompt Attack Detection identifies jailbreaks and injection attempts. Denied Topics enforce custom subject-matter restrictions you define. Sensitive Information Filters handle PII masking and removal. Word Policies enforce blocklists for specific terms. Contextual Grounding checks whether responses are supported by source material. Since August 2025, Automated Reasoning uses formal mathematical verification to validate responses against defined policy documents with up to 99% accuracy at catching factual errors in constrained domains.

Deploying a Guardrail via the AWS CLI

aws bedrock create-guardrail \
  --name "prod-rag-guardrail" \
  --description "Guardrail for production RAG endpoint" \
  --content-policy-config '{
    "filtersConfig": [
      {"type": "VIOLENCE", "inputStrength": "HIGH", "outputStrength": "HIGH"},
      {"type": "HATE", "inputStrength": "HIGH", "outputStrength": "HIGH"},
      {"type": "INSULTS", "inputStrength": "HIGH", "outputStrength": "HIGH"},
      {"type": "MISCONDUCT", "inputStrength": "HIGH", "outputStrength": "HIGH"},
      {"type": "PROMPT_ATTACK", "inputStrength": "HIGH", "outputStrength": "NONE"}
    ]
  }' \
  --sensitive-information-policy-config '{
    "piiEntitiesConfig": [
      {"type": "EMAIL", "action": "ANONYMIZE"},
      {"type": "PHONE", "action": "ANONYMIZE"},
      {"type": "SSN", "action": "BLOCK"},
      {"type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK"}
    ]
  }' \
  --blocked-inputs-messaging "Your input was flagged by our content policy." \
  --blocked-outputs-messaging "This response was blocked by our content policy."

Prompt Injection Defense

When building Bedrock Agents, tag dynamically generated or mutated prompts as user input when they incorporate external data such as RAG-retrieved content, third-party API responses, or prior completions. This ensures guardrails evaluate all untrusted content, including indirect inputs derived from external sources, for hidden adversarial instructions. Apply user input tags to both direct queries and system-generated prompts that integrate external data to activate Bedrock's prompt attack filters on all potential injection vectors while preserving trust in static system instructions.

For production agent deployments, set PROMPT_ATTACK filter strength to HIGH for inputs and use the default preprocessing prompt on your agent, which uses a foundation model to classify whether user input is safe before it reaches your agent's orchestration logic.

Associating a Guardrail with a Bedrock API Call

import boto3

bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1")

response = bedrock_runtime.invoke_model(
    modelId="anthropic.claude-sonnet-4-6",
    guardrailIdentifier="arn:aws:bedrock:us-east-1:123456789012:guardrail/abc123def456",
    guardrailVersion="DRAFT",
    trace="ENABLED",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 1024,
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "type": "text",
                        "text": user_input,
                        "guardContent": {
                            "tag": "PROMPT"
                        }
                    }
                ]
            }
        ]
    })
)

Note the guardContent tag on the user message content. This is how you signal to Bedrock Guardrails which parts of your input are user-controlled versus trusted system instructions. Content tagged as PROMPT is subject to prompt attack detection.

Encryption: KMS Customer-Managed Keys

What to Encrypt

Every storage layer involved in your Bedrock and SageMaker workloads should be encrypted with KMS customer-managed keys rather than the default AWS-managed keys. The difference matters operationally: with AWS-managed keys, you cannot restrict access through key policy, cannot audit usage at the key level, and cannot revoke access by disabling the key.

The surfaces requiring CMK encryption are:

Creating a KMS Key with Appropriate Policy

aws kms create-key \
  --description "CMK for SageMaker endpoint prod-llm-v3" \
  --key-policy '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "Enable IAM User Permissions",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::123456789012:root"
        },
        "Action": "kms:*",
        "Resource": "*"
      },
      {
        "Sid": "Allow SageMaker endpoint role",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::123456789012:role/SageMakerEndpointRole"
        },
        "Action": [
          "kms:Decrypt",
          "kms:GenerateDataKey"
        ],
        "Resource": "*"
      }
    ]
  }'

All data transfer between platform components, API calls, and inter-container communication should be protected using TLS 1.2. All data at rest in S3 buckets, EBS and EFS volumes should be encrypted using customer-managed KMS keys, and automatic key rotation should be enabled.

Enable automatic key rotation on all CMKs used for AI workloads:

aws kms enable-key-rotation \
  --key-id mrk-abc123def456

Logging, Monitoring, and Threat Detection

Enabling Bedrock Model Invocation Logging

Bedrock model invocation logging is off by default. Without it, you have no record of prompts sent, models invoked, token counts consumed, or latencies observed. This is the gap that the November 2025 attacker confirmed before proceeding. Enable logging to both S3 and CloudWatch Logs:

aws bedrock put-model-invocation-logging-configuration \
  --logging-config '{
    "cloudWatchConfig": {
      "logGroupName": "/aws/bedrock/model-invocations",
      "roleArn": "arn:aws:iam::123456789012:role/BedrockCloudWatchRole",
      "largeDataDeliveryS3Config": {
        "bucketName": "my-bedrock-logs-bucket",
        "keyPrefix": "invocation-logs/"
      }
    },
    "s3Config": {
      "bucketName": "my-bedrock-logs-bucket",
      "keyPrefix": "invocation-logs/"
    },
    "textDataDeliveryEnabled": true,
    "imageDataDeliveryEnabled": true,
    "embeddingDataDeliveryEnabled": true
  }'

Set up a CloudWatch metric filter and alarm on the invocation log group to alert on anomalous patterns such as unusually high token consumption, requests from unexpected IAM principals, or requests outside business hours.

CloudTrail for API Plane Audit

Enable CloudTrail for all Bedrock and SageMaker API calls. Enabling CloudTrail for Amazon Bedrock API calls and deploying Bedrock Guardrails as a content filter in front of your model endpoint are among the first controls DevSecOps teams should apply when extending existing security controls to AI workloads.

Create a CloudTrail trail that logs management and data events for both services:

aws cloudtrail create-trail \
  --name bedrock-sagemaker-audit-trail \
  --s3-bucket-name my-cloudtrail-bucket \
  --include-global-service-events \
  --is-multi-region-trail \
  --enable-log-file-validation

aws cloudtrail put-event-selectors \
  --trail-name bedrock-sagemaker-audit-trail \
  --event-selectors '[
    {
      "ReadWriteType": "All",
      "IncludeManagementEvents": true,
      "DataResources": [
        {
          "Type": "AWS::Bedrock::*",
          "Values": ["arn:aws:bedrock:*"]
        }
      ]
    }
  ]'

GuardDuty for Runtime Threat Detection

Amazon GuardDuty now includes threat detection for Bedrock and SageMaker API activity. It monitors CloudTrail for anomalous patterns including unusual model invocations from new geographic locations, credential use from unexpected IP ranges, and high-volume API calls consistent with unauthorized access. Enable GuardDuty in every region where you operate AI workloads and integrate findings into your Security Hub for centralized triage.

aws guardduty create-detector \
  --enable \
  --features '[
    {"Name": "RUNTIME_MONITORING", "Status": "ENABLED"},
    {"Name": "S3_DATA_EVENTS", "Status": "ENABLED"},
    {"Name": "CLOUD_TRAIL", "Status": "ENABLED"}
  ]'

SageMaker-Specific Hardening

Disable Root Access on Notebook Instances

91% of Amazon SageMaker users have at least one notebook with root access enabled by default. A compromised session token on such an instance grants an attacker the ability to modify all files on it, pivot to training infrastructure, and access any IAM role the notebook's execution role can assume.

When creating a new notebook instance, explicitly set root access to disabled:

aws sagemaker create-notebook-instance \
  --notebook-instance-name prod-analysis-notebook \
  --instance-type ml.t3.medium \
  --role-arn arn:aws:iam::123456789012:role/SageMakerNotebookRole \
  --root-access Disabled \
  --direct-internet-access Disabled \
  --subnet-id subnet-0123456789abcdef0 \
  --security-group-ids sg-0123456789abcdef0 \
  --kms-key-id mrk-abc123def456

Note that both root-access Disabled and direct-internet-access Disabled are set explicitly. These are not the defaults. You must set both intentionally.

Pre-Signed URL Expiration

SageMaker notebook access uses pre-signed URLs. If you generate these URLs for users, set short expiration times. The default expiration can be up to 12 hours. For most workflows, a five-minute expiration is more than sufficient and dramatically reduces the window for URL interception or reuse.

aws sagemaker create-presigned-notebook-instance-url \
  --notebook-instance-name prod-analysis-notebook \
  --session-expiration-duration-in-seconds 300

Container Image Scanning

Every custom Docker image you use for SageMaker training or inference should go through Amazon ECR image scanning before deployment. Enable enhanced scanning on your ECR repositories to get continuous vulnerability assessment rather than on-push scanning alone:

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[
    {
      "repositoryFilters": [
        {"filter": "my-inference-*", "filterType": "WILDCARD"}
      ],
      "scanFrequency": "CONTINUOUS_SCAN"
    }
  ]'

Block deployments from your CI/CD pipeline when ECR scanning finds CRITICAL severity findings. Your pipeline should query scan results before pushing the updated model configuration to SageMaker.

Comparison: Bedrock vs SageMaker Security Responsibilities

Understanding which security controls apply to which service prevents coverage gaps. The two services have meaningfully different shared responsibility boundaries.

Putting It Together: A Production Security Checklist

Before you promote any Bedrock or SageMaker workload to production, validate the following:

Identity and Access
All Bedrock and SageMaker execution roles are scoped to specific resources and actions. Wildcard resource ARNs are absent from production roles. IAM Access Analyzer has reviewed all policies for unused permissions. SCPs at the OU level enforce minimum security standards that account-level policies cannot override.

Network
SageMaker endpoints and training jobs run inside private subnets with no direct internet access. Interface VPC endpoints are configured for all required AWS services. Security groups on endpoint ENIs restrict outbound traffic to the VPC endpoint interfaces. No notebook instance has direct internet access enabled.

Encryption
S3 buckets storing training data and model artifacts are encrypted with CMKs. Notebook EBS volumes are encrypted. Automatic key rotation is enabled. Bucket policies enforce aws:SecureTransport to require TLS on all API calls.

Logging and Detection
Bedrock model invocation logging is enabled and writing to both S3 and CloudWatch Logs. CloudTrail is active in all regions with data events enabled for Bedrock APIs. GuardDuty is enabled in all active regions. CloudWatch alarms fire on anomalous invocation patterns.

Application Layer
A Bedrock Guardrail with PROMPT_ATTACK detection at HIGH strength is associated with every production endpoint. PII filters are configured with appropriate actions (anonymize vs block) based on your data classification. Denied topics are defined for your specific use case. Contextual grounding checks are enabled for RAG-based applications.

Conclusion

The security controls for Amazon Bedrock and SageMaker are not fundamentally different from the controls you already apply to the rest of your AWS estate. IAM least privilege, VPC isolation, KMS encryption, CloudTrail audit logging, and GuardDuty threat detection are the same services you use for EC2, RDS, and Lambda. What changes is the attack surface: model invocation logging, prompt injection via user inputs, guardrail removal, training data exposure, and GPU compute abuse are specific to AI workloads and require AI-specific configuration steps on top of your baseline.

Start with the highest-impact actions first. Enable Bedrock model invocation logging today, as it costs almost nothing and provides immediate audit visibility. Disable direct internet access and root access on all SageMaker notebooks by updating their configurations. Scope all execution role policies to specific resource ARNs rather than wildcards. Deploy a Bedrock Guardrail with prompt attack detection for any customer-facing application.

The November 2025 Sysdig-documented breach started with a public S3 bucket and took ten minutes from initial access to full account compromise. Every control in this guide would have either prevented the initial access or dramatically reduced the blast radius. Apply them systematically, validate them through AWS Config rules and Security Hub standards, and you significantly reduce the probability that your AI investment becomes someone else's compute budget.

FAQS