Bedrock Custom Model Import: Guardrails and IAM Still Must Wrap

Bedrock Custom Model Import: Guardrails and IAM Still Must Wrap

Importing custom weights into Bedrock feels like an escape hatch from managed model limits—until someone invokes the imported model without Guardrails, without CloudTrail-friendly logging, and with an IAM policy that says bedrock:InvokeModel on *. Custom Model Import changes where weights live, not your duty to wrap them with the same controls as foundation models.

⚡ TL;DR: Import only from approved S3 artifacts with hash pins; require Guardrails on every InvokeModel/Converse path; scope IAM to the imported model ARN; enable invocation logging; run the same eval + safety suites as managed models before traffic. See Bedrock Guardrails and Guardrail Metrics.

Import with supply-chain discipline

# Pin artifact hash before CreateModelImportJob
aws s3api head-object --bucket ml-artifacts --key models/acme-coder-v3/model.tar.gz \
  --query '{ETag:ETag,ChecksumSHA256:ChecksumSHA256}'

# Refuse import if SHA256 != lockfile entry in infra repo
{
  "jobName": "acme-coder-v3-import",
  "importedModelName": "acme-coder-v3",
  "roleArn": "arn:aws:iam::123456789012:role/BedrockModelImport",
  "modelDataSource": {
    "s3DataSource": {
      "s3Uri": "s3://ml-artifacts/models/acme-coder-v3/"
    }
  }
}

Import role: read-only on that prefix; no s3:*. Model cards + eval reports land in the same change ticket as the import job.

Guardrails are not optional on imported IDs

import boto3
brt = boto3.client("bedrock-runtime")

RESP = brt.converse(
    modelId="arn:aws:bedrock:us-east-1:123456789012:imported-model/acme-coder-v3",
    guardrailConfig={
        "guardrailIdentifier": GUARDRAIL_ID,
        "guardrailVersion": "5",
        "trace": "enabled",
    },
    messages=[{"role": "user", "content": [{"text": user_prompt}]}],
)

Do not ship application paths that call imported models with a “dev bypass” flag — that flag will reach prod. Enforce Guardrails in a single shared Bedrock client SDK used by all services.

IAM that names the model

{
  "Effect": "Allow",
  "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:Converse"],
  "Resource": [
    "arn:aws:bedrock:us-east-1:123456789012:imported-model/acme-coder-v3"
  ],
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "us-east-1"
    }
  }
}

Separate roles for prompt-engineering sandboxes vs prod agents. Deny bedrock:InvokeModel on * in SCPs for prod accounts except through approved role patterns.

Logging, eval, and rollback

Control Managed FM Imported model
Invocation logging Required Required (same)
Guardrails Required Required (same)
Golden coding evals Required Required + custom fine-tune slices
Rollback Change model ID alias Alias → previous imported ARN
prod alias: acme-coder-prod → imported-model/acme-coder-v3
rollback:   acme-coder-prod → imported-model/acme-coder-v2

Wire canaries from synthetic agent evals before shifting aliases.

Closing checklist

Dos
– Hash-pin S3 artifacts; review model cards in the same PR as import
– Attach Guardrails on every invoke path via shared SDK
– Scope IAM to imported model ARNs; alias for rollback
– Enable invocation logging + metrics dashboards
– Run safety + coding canaries before prod traffic

Donts
– Do not treat import as “Guardrails don’t apply”
– Do not grant bedrock:* on * to app roles
– Do not import from writable shared buckets
– Do not skip FP monitoring (guardrail metrics)
– Do not hot-swap weights without eval gates

Related reading

Last updated on September 11, 2026


Discover more from CheatCoders

Subscribe to get the latest posts sent to your email.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply