Services or capabilities described in AWS documentation might vary by Region. To see the differences applicable to the AWS European Sovereign Cloud Region, see the AWS European Sovereign Cloud User Guide.

Restrict artifact access to model package deployments

When you share a model package across accounts, the consuming account's execution role needs s3:GetObject on the model artifacts in the producing account. By default, that permission applies whenever the role is used. As a result, any principal that uses the role can read the artifacts from a notebook, from a training job, or through a direct API call—not only from an endpoint deployed from a model package.

You can narrow that access so that only endpoints deployed from a model package can read the artifacts. When you deploy an endpoint from a model package, SageMaker AI applies the session tag sagemaker:ModelPackageArn to the execution-role sessions it assumes for that endpoint. The tag value is the ARN of the model package version. The tag applies for the life of the endpoint, both to the sessions SageMaker AI uses to download the model artifacts and to the credentials that the inference container receives at runtime. A bucket policy that requires this tag therefore grants access only to sessions that belong to an endpoint deployed from a matching model package. Notebooks, training jobs, and endpoints deployed from a plain container image do not carry the tag.

If code in your inference container assumes another role, the resulting credentials do not carry the sagemaker:ModelPackageArn tag.

This requires three pieces working together. All three are yours to configure; SageMaker AI supplies only the session tag:

Step 1: Tag and scope the execution role

In the consuming account, tag the execution role ManagedBy=SageMaker and restrict its trust policy to the SageMaker AI service principal. The trust policy must allow both sts:AssumeRole and sts:TagSession. Without sts:TagSession, SageMaker AI cannot apply the sagemaker:ModelPackageArn session tag, and Amazon S3 denies every read that the bucket policy in Step 3 requires.

{
  "RoleName": "GovernedModelExecutionRole",
  "Tags": [ { "Key": "ManagedBy", "Value": "SageMaker" } ],
  "AssumeRolePolicyDocument": {
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "sagemaker.amazonaws.com" },
      "Action": [ "sts:AssumeRole", "sts:TagSession" ]
    }]
  }
}

Step 2: Add a service control policy

Attach the following SCP in your organization. The first statement allows only the SageMaker AI service principal to assume a role tagged ManagedBy=SageMaker. The second allows only SageMaker AI to set the sagemaker:ModelPackageArn tag key, which is the only tag key that the bucket policy evaluates. For more information, see Creating, updating, and deleting service control policies.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSageMakerAssumeOnManagedRoles",
      "Effect": "Deny",
      "Action": "sts:AssumeRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:ResourceTag/ManagedBy": "SageMaker" },
        "StringNotEquals": { "aws:PrincipalServiceName": "sagemaker.amazonaws.com" }
      }
    },
    {
      "Sid": "DenyTaggingProtectedKeysUnlessSageMaker",
      "Effect": "Deny",
      "Action": [ "iam:TagRole", "iam:UntagRole", "sts:TagSession" ],
      "Resource": "*",
      "Condition": {
        "StringLike": { "aws:RequestTag/sagemaker:ModelPackageArn": "*" },
        "StringNotEquals": { "aws:PrincipalServiceName": "sagemaker.amazonaws.com" }
      }
    }
  ]
}

Step 3: Add the Amazon S3 bucket policy

In the producing account, apply the following policy to the bucket holding the model artifacts. The first statement governs reads by endpoints deployed from a model package. All three of its conditions must hold, and Amazon S3 denies any session that is missing one. The second statement allows model package registration, which happens before any deployment tag exists.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlyModelPackageDeployments",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::model-artifacts-bucket/model-package-prefix/*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalTag/sagemaker:ModelPackageArn":
            "arn:aws:sagemaker:*:producer-account-id:model-package/model-package-group/*"
        },
        "StringEquals": {
          "aws:PrincipalOrgID": "o-organization-id",
          "aws:PrincipalTag/ManagedBy": "SageMaker"
        }
      }
    },
    {
      "Sid": "AllowModelPackageRegistrationReads",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::registering-account-id:role/model-registration-role"
      },
      "Action": [ "s3:GetObject", "s3:ListBucket" ],
      "Resource": [
        "arn:aws:s3:::model-artifacts-bucket",
        "arn:aws:s3:::model-artifacts-bucket/model-package-prefix/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-organization-id"
        }
      }
    }
  ]
}

AllowModelPackageRegistrationReads is required. CreateModelPackage reads the artifact to validate it, and at that point the model package does not exist yet, so no sagemaker:ModelPackageArn session tag can be present. Without this statement, the first statement denies registration, and you cannot create the model package at all. Set model-registration-role to the role that calls CreateModelPackage, and keep it scoped to that role rather than to the whole account.

Using Principal with a value of * together with these conditions means any role in your organization can read the artifacts, provided it is tagged ManagedBy=SageMaker and carries the session tag. You do not have to edit the policy for each consuming role. The wildcard on the model package ARN covers every version in the group.

To allow more than one model package group, add one statement per group. Pair that group's ARN pattern with that group's artifact prefix. The condition also accepts a list of ARN patterns in a single statement. Use that form only when the groups are meant to share the same artifacts, because a single statement grants every pattern it lists access to everything its Resource covers.

Artifacts from more than one producer account need the same treatment: one pattern per account, because the tag value carries the account that owns the model package.

If the artifacts are encrypted with a customer managed AWS KMS key, the execution role also needs kms:Decrypt on that key. Because the key and the role are in different accounts, grant it in both places: the key policy in the producing account must allow the execution role, and the execution role's IAM policy must allow kms:Decrypt on the key. Either grant alone is not sufficient.

Monitor artifact access

Your account records both the tagging of the session and the resulting access decision.

Before applying the policies to a production bucket, you can evaluate them with the IAM policy simulator to confirm that a deployment session is allowed and that a session without the tag is denied. The simulator evaluates your policy against context keys that you supply, so it confirms the policy logic but not that a deployment actually produces the tag. Confirm that separately in CloudTrail, as described earlier in this section. For more information, see Testing IAM policies with the IAM policy simulator.