Production Hardening & IaC

AgentCore's security is not a single boundary — it is a stack of independent layers, each of which has to be defeated for an attacker to win. Internalize the layers as a checklist; a hardened deployment uses all of them.

The headline layer is session isolation. Agents are non-deterministic, hold stateful reasoning context, and perform privileged tool operations on a user's behalf — so AWS gives every session its own microVM and destroys it on termination (idle timeout and max compute lifetime defaults — commonly 15 min and 8 hours as of writing; these are quotas, so confirm the current values on the live limits page). Critically, AWS does not map sessions to users: "your client backend should maintain the relationship between users and their session IDs." Owning that mapping — and per-user session caps — is your job, not the platform's.

The outbound layer is the one engineers most often get wrong by reflex: they hardcode an API key or stuff it into a prompt. AgentCore Identity exists precisely so you never do that. Tokens live in the vault, encrypted with KMS, and are pulled at call time by a decorator — never embedded in code, config, or the LLM context window.

Here is the senior-engineer truth that marketing slides skip: AgentCore sandboxes are strong on cross-tenant isolation but are NOT airtight data-egress boundaries. The microVM keeps tenant A's data away from tenant B extremely well. It does not, by itself, guarantee that a compromised or prompt-injected agent inside a sandbox cannot smuggle data out.

The concrete leak everyone misses is DNS. The Code Interpreter SANDBOX network mode is often described as "no internet," but the dossier is precise: SANDBOX still permits DNS (A/AAAA) resolution. Teach it as "no general internet egress, S3 reachable via the execution role" — not "airtight network jail." DNS resolution alone is a viable covert channel.

# networkConfiguration on a Code Interpreter session
# SANDBOX  -> isolated; no general public egress; S3 reachable via execution role; DNS still resolves
# PUBLIC   -> full public internet egress
{
  "networkConfiguration": { "networkMode": "SANDBOX" }
}

This is not hypothetical. Published external research demonstrates real exfiltration paths out of the Code Interpreter sandbox:

• BeyondTrust — DNS-based command-and-control out of SANDBOX.
• Sonrai — credential exfiltration via the metadata service (169.254.169.254) plus a "global S3" covert channel.
• Palo Alto Unit 42 — a network-isolation bypass.

The correct takeaway is not "the sandbox is broken" — cross-tenant isolation holds. The takeaway is that isolation is one layer, and you must combine it with the others: least-privilege execution roles (so an escaped agent has nothing worth stealing), no sensitive secrets baked into the role, and active monitoring of egress. The platform raises the floor; it does not remove your obligation to assume the agent can be subverted.

At GA, all AgentCore services gained VPC, AWS PrivateLink, AWS CloudFormation, and resource tagging support [VOLATILE — confirm scope per service]. "All services" is the headline, but the per-service reality is uneven, so verify before you assume parity.

Runtime supports VPC mode. Configure it through the starter toolkit with --vpc / --subnets / --security-groups, so the runtime's egress flows through your VPC's routing, NAT, and security groups:

# Starter-toolkit configure with VPC networking
agentcore configure \
  --vpc \
  --subnets subnet-0a1b2c3d,subnet-4e5f6a7b \
  --security-groups sg-0123456789abcdef0

Network egress to customer VPCs is billed at roughly $0.006/GB in commercial regions [VOLATILE — verify the live pricing page]. Treat that number as a concept (VPC egress is metered), not a timeless fact.

The tools do NOT all match Runtime. The dossier is explicit about the gaps:

So if your compliance story depends on "all agent traffic stays inside the VPC," that holds for the Runtime but is not confirmed for the Browser or Code Interpreter tools — design accordingly and read the live docs.

Resource tagging is the cheap governance win. Tag every AgentCore resource at creation for cost allocation, attribution, and tag-based IAM/Policy conditions. Tagging is supported across the services at GA, and IaC is the right place to enforce it (every resource gets the same baseline tags automatically).

AgentCore uses two roles you must understand: the execution role the agent assumes at runtime, and the trust policy that lets the service assume it. AWS itself warns that auto-generated dev policies are broad and not production-grade — the security research above specifically calls out the Starter Toolkit's default role as granting full S3 read + Secrets Manager, exactly the kind of standing credential an escaped agent would love.

Scope the execution role to only what the agent actually does. The dossier's abbreviated action list:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Logs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents",
        "logs:DescribeLogGroups", "logs:DescribeLogStreams"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/bedrock-agentcore/runtimes/*"
    },
    {
      "Sid": "Tracing",
      "Effect": "Allow",
      "Action": [
        "xray:PutTraceSegments", "xray:PutTelemetryRecords",
        "xray:GetSamplingRules", "xray:GetSamplingTargets"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Metrics",
      "Effect": "Allow",
      "Action": "cloudwatch:PutMetricData",
      "Resource": "*",
      "Condition": { "StringEquals": { "cloudwatch:namespace": "bedrock-agentcore" } }
    },
    {
      "Sid": "WorkloadTokens",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:GetWorkloadAccessToken*",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:workload-identity-directory/default/workload-identity/myAgent-*"
    },
    {
      "Sid": "Model",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
      "Resource": "*"
    }
  ]
}

Notes that separate a production role from the dev default:

• ECR actions are container-only. ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, ecr:GetAuthorizationToken belong on the role only when you deploy via Container/ECR. A CodeZip deploy that carries ECR perms is over-broad — and a container deploy missing them silently fails to pull the image.
• Workload-token access is scoped by agent name (workload-identity-directory/default/workload-identity/<agentName>-*), not a wildcard.
• cloudwatch:PutMetricData is namespace-conditioned to bedrock-agentcore.
• Drop bedrock:InvokeModel entirely if the agent never calls a Bedrock model.

The trust policy uses confused-deputy guards — principal bedrock-agentcore.amazonaws.com, sts:AssumeRole, conditioned on aws:SourceAccount and aws:SourceArn:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "bedrock-agentcore.amazonaws.com" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "aws:SourceAccount": "123456789012" },
      "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:123456789012:*" }
    }
  }]
}

Secrets stay out of the role and out of the image. The role is for AWS permissions; downstream credentials belong in the token vault (fetched via @requires_access_token / @requires_api_key) or in Secrets Manager — never baked into a container image, a CodeZip bundle, or an environment variable in the deployment. Encrypt at rest with KMS CMKs where the service supports them (the token vault encrypts with service-managed KMS or a CMK; Memory and other stores accept CMKs too) so you control rotation and key access.

For the developer/caller identity, the managed policy BedrockAgentCoreFullAccess is the quickest way to get going, but it is a developer convenience, not a production runtime grant — keep it off the execution role.

Repeatable, reviewable infrastructure is the difference between a demo and a production service. AgentCore is built for this: at GA every service gained CloudFormation support, and the new AgentCore CLI (@aws/agentcore) deploys via CDK → CloudFormation under the hood.

That means agentcore deploy is not magic — it synthesizes a CDK app and applies a CloudFormation stack, which is exactly what you want for production: a diffable template, a change set you can review, and a clean teardown.

npm install -g @aws/agentcore

# Scaffold a production-shaped agent (HTTP protocol, Bedrock model, no managed memory)
agentcore create --name MyAgent --framework Strands --protocol HTTP \
  --model-provider Bedrock --memory none
cd MyAgent

agentcore dev                 # hot-reload server + inspector on :8080 (local)
agentcore deploy              # package -> CDK synth -> CloudFormation deploy
agentcore status
agentcore logs
agentcore traces list

agentcore remove all && agentcore deploy   # full teardown then redeploy

Prerequisites are CDK-shaped. The new CLI needs Node 20+, Python 3.10+, AWS credentials, and — critically — cdk bootstrap to have been run in the target account/region. "CDK not bootstrapped" is a documented deploy gotcha. The caller also needs CloudFormation/CDK permissions in addition to the AgentCore ones.

Why IaC, beyond repeatability:

• Reviewable least privilege. The execution-role JSON above lives in your template, so a reviewer can see — in a PR — that you didn't grant s3:*. Drift is caught by the next deploy.
• Enforced tagging. Apply a baseline tag set at the stack level so every AgentCore resource is tagged for cost allocation and tag-based governance, with no human remembering to do it.
• Reproducible environments. The same template stands up dev, staging, and prod with parameterized account/region/VPC inputs.

CloudFormation, CDK, or Terraform? Pick the one your org already standardizes on:

• CDK — what the new CLI emits; ideal if you want to extend the generated app in TypeScript/Python.
• CloudFormation — the lingua franca underneath; review the synthesized template directly, or hand-author for tight control.
• Terraform — fully viable since the resources are CloudFormation-backed; use it when Terraform is your house standard for multi-account/multi-cloud estates.

Whatever you choose, the win is the same: the security posture (roles, KMS keys, VPC config, tags) is code in version control, not console clicks.

The remaining layers turn a secured deployment into a governed, observable one.

Cedar Policy governs tool calls. The Policy engine intercepts every tool call in one of two modes: ENFORCE (block disallowed calls) or LOG (record what would be blocked without blocking). The progression for a new policy is to roll out in LOG, watch the audit trail for false positives, then flip to ENFORCE. Gateway interceptors and namespace-scoped IAM on Memory add further chokepoints.

Bedrock Guardrails span models and frameworks — content filters, denied topics, word filters, PII detection/redaction, and contextual grounding. Two ways to apply them:

# 1) Native (Bedrock model): attach the guardrail to a Strands BedrockModel
from strands.models import BedrockModel

model = BedrockModel(
    model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0",  # [VOLATILE] verify current default
    guardrail_id="gr-abc123",
    guardrail_version="1",
    guardrail_trace="enabled",
)
# Detect a firing: response.stop_reason == "guardrail_intervened"

# 2) Model-agnostic (imperative): moderate text without invoking a Bedrock FM
# Works with OpenAI / Gemini / self-hosted models
resp = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="gr-abc123",
    guardrailVersion="1",
    source="INPUT",                # or "OUTPUT"
    content=[{"text": {"text": user_input}}],
)

The ApplyGuardrail API is what lets one guardrail policy cover a fleet that mixes Bedrock, OpenAI, and self-hosted models. A useful rollout trick mirrors Cedar's LOG mode: run guardrails in shadow mode (Strands Hooks on MessageAddedEvent / AfterInvocationEvent log would-be blocks) before you enforce.

Auditability is durable and detailed. APPLICATION_LOGS capture full request/response payloads plus trace and session IDs, and route to CloudWatch Logs, S3, or Data Firehose (cross-account monitoring supported); CloudTrail records control-plane API calls. That richness is a double-edged sword:

APPLICATION_LOGS  ->  full request + response payloads + trace/session IDs
                  ->  CloudWatch Logs / S3 / Data Firehose (durable, cross-account)