Claude Code Remote Sessions on Amazon Bedrock AgentCore: AWS Sample With Security Controls

AWS published a sample on November 6, 2026 that moves Claude Code off the laptop and into a remote, sandboxed session on Amazon Bedrock AgentCore. You hand off a task, close the lid, and come back to a pull request. The AWS Machine Learning Blog post by Andrew Ren, Kevin Low and Traci Lim is a level 400 how-to, and its value is less the "remote Claude Code" idea than the list of security controls wrapped around it, and the honest list of what those controls do not cover.

This post walks through the design, the controls, the limits AWS states itself, and what to check before you copy it.

TL;DR: the sample in one table

Agents that act on your behalf need rules. See how explainx helps secure your agents →

Why run Claude Code remotely at all?

Claude Code normally runs in your terminal, and it can use Bedrock as its model provider. AWS argues for a different shape: a remote agent in your own account. Tasks run in parallel, each in a disposable environment, and the developer stops babysitting a terminal. The post names the trade-offs plainly: less steering during a run, more setup work, and cost that is harder to predict.

The post gives these reasons to use Bedrock as the model provider: billing through an existing AWS account with no per-seat licences, audit logging in CloudTrail, geographic inference profiles for data residency, access through IAM temporary credentials with PrivateLink, and retention controls including zero data retention. It also says Bedrock does not use customer content for training or share it with model providers. Those are AWS claims. Check them against your own agreement before you rely on them.

AWS has pushed this pattern for a while. Its docs for hosted coding agents describe running Claude Code on AgentCore so each agent gets its own isolated microVM, and say an agent that talks to Bedrock natively needs only an IAM role with model invoke rights, plus a container image that sets CLAUDE_CODE_USE_BEDROCK=1 (AWS AgentCore hosted IDE agents docs). The November 6 post builds a full task pipeline on top of that idea.

How does the architecture work?

Claude Code remote sessions on Amazon Bedrock AgentCore architecture with API Gateway, Lambda, SQS and private VPC runtime Image: AWS

The sample has three layers: submission, queueing, and execution.

Submission. A local MCP server in the sample-rca plugin signs requests with your AWS credentials and calls an IAM-authorised Amazon API Gateway HTTP API. If you prefer a browser, a web console served by Amazon CloudFront with AWS WAF signs you in through Amazon Cognito. Our guide to the Model Context Protocol explains why an MCP server is a natural front door for this.

Queueing. A Lambda function screens each prompt with Amazon Bedrock Guardrails, writes the task to DynamoDB, and puts it on an SQS queue. A dispatcher Lambda then starts one AgentCore runtime session per task, on the runtime that belongs to that repository.

Execution. Every registered repository gets its own AgentCore runtime running one container image from Amazon ECR. The image holds the Claude Code CLI, the Claude Agent SDK, git and make. Each session is a separate microVM inside a VPC.

Inside the session the agent follows a fixed loop:

1. Fetch a GitHub token from AgentCore Identity.
2. Clone the repository.
3. Search AgentCore memory for lessons from earlier tasks on the same repo.
4. Plan with Claude Opus on Bedrock.
5. Code with Claude Sonnet.
6. Run the repository own setup and test commands.
7. Review with Claude Opus. The review can send the work back to planning.

Task flow of a remote Claude Code agent from API Gateway to an AgentCore session that plans, codes, verifies and opens a pull request Image: AWS

When the loop ends, the agent pushes an agent/taskId branch and opens a pull request that records the verification command, its exit code and the number of attempts used. If verification did not pass, the pull request is a draft. The agent never merges.

The split between a stronger planning and review model and a cheaper coding model mirrors a pattern we covered in Claude Code subagents and multi-agent workflows and in the effort levels for subagents.

Which security controls does the sample add?

This is the part worth reading closely. AWS lists controls in five areas.

Network

Runtimes sit in private subnets. VPC endpoints carry traffic to AWS services, so prompts, task state and logs do not cross the public internet. The only internet route is a NAT gateway for GitHub and package registries, and the security group allows only outbound HTTPS.

A Route 53 Resolver DNS Firewall blocks model-vendor domains such as api.anthropic.com, so the agent cannot quietly route model calls around Bedrock. AWS is open that this is a denylist and does not stop other HTTPS traffic. For production it recommends an AWS Network Firewall domain allowlist. That caveat matters: a denylist stops one known exit, not data leaving to an unknown host.

Identity and permissions

Model calls use the runtime IAM execution role, and the container holds no other AWS credentials. The role can invoke only Anthropic models on Bedrock, read and write only its own repository task records and memory, and pull only the agent image. It is explicitly denied the AgentCore Identity control plane, so a task cannot change the shared GitHub credential provider.

Secrets

The sample creates one GitHub App with read and write access to Contents and Pull requests. The client secret sits in the AgentCore Identity token vault. Users install the app only on the repositories the agent may change and authorise each one through three-legged OAuth. Containers get user-to-server tokens that expire after 8 hours and refresh on their own. Commits come from the app bot account.

This is a better pattern than pasting a personal access token into an environment variable. Our write-up of AWS trust in depth for agent autonomy covers the same scope-and-bound thinking at the policy level.

Session isolation

Each task gets a dedicated microVM, and AWS says the session memory is sanitised when it ends. AgentCore memory does carry lessons between tasks on the same repository. That is useful, and it is also shared state per repo. Treat it as a place where a poisoned lesson could persist.

Prompt screening and human review

A Standard-tier Bedrock Guardrail screens the prompt before it is queued. At low strength it blocks jailbreaks, prompt injection and misconduct requests such as malware, and it blocks AWS keys and other secrets. A blocked prompt returns PromptBlockedByGuardrail, and if the guardrail cannot respond, the task is refused. The pull request step keeps a person in the loop, and AWS recommends branch protection on the default branch.

What does the sample not cover?

AWS states several limits itself. We list them without adding any of our own.

The first row is the one to read twice. A coding agent reads README files, issues, dependency manifests and test output. Any of those can carry instructions aimed at the agent. A screen on the user prompt does not see them. We saw this class of problem in AgentCorruption, where one prompt hijacked every Bedrock AgentCore agent, and in the Vercel KVM zero-day that escaped an agent sandbox. A microVM limits the blast radius. It does not stop the agent from being talked into a bad action inside its allowed scope.

Setup: what the post says you need

The visible part of the post lists these steps:

1. Use an AWS account, ideally a dedicated one, with the AWS CLI and credentials.
2. Run Docker. The deploy builds an ARM64 image of roughly 1.3 GB locally.
3. Pick a supported Region. The post lists us-east-1, us-east-2, us-west-2, ap-northeast-1 and eu-west-1 for AgentCore runtime V2 and uses us-west-2.
4. Deploy the stacks. Expect 15 to 25 minutes.
5. Connect GitHub and register a repository. Expect 8 to 12 minutes per repository.
6. Run a task from the web console or from Claude Code, then review the pull request.

The AWS post links the code as the aws-samples/sample-remote-coding-agent repository. We could not read the exact commands and config snippets in the post, because that part was cut off in the copy we fetched. Follow the repository README and the AWS post for the exact deploy steps.

How does this compare with other sandbox options?

Remote microVM sessions are one of several ways to contain a coding agent. A local VM sandbox such as the one in our Capsem guide keeps everything on your machine and can run air-gapped with an inspecting proxy. A tool-call proxy such as the one in our Hugging Face SafeAgents guide blocks risky actions before they run. The AWS sample sits at the other end: a managed, account-level setup with IAM, VPC and audit trails, aimed at teams that already live in AWS.

These layers do not compete. The microVM limits what a bad action can touch. A tool-call check decides whether the action should happen at all. For the AgentCore side of the ecosystem, our guide to the AWS agent registry and runtime tool discovery shows how agents find tools, and the Web Answer launch on AgentCore shows how a managed tool plugs into the same gateway.

What should you check before copying it?

• Repository trust. Only register repositories whose setup and test commands you would run on your own laptop.
• Egress. Replace the DNS denylist with a domain allowlist before real use.
• Memory. Decide who can write lessons into AgentCore memory, and review what it stores.
• Branch protection. Require review on the default branch. The agent opens pull requests, but a misconfigured repo could let a merge slip through.
• Cost. Set budgets and alarms. AWS itself calls cost less predictable.
• Injection. Assume the repository can contain hostile text. A runtime check on agent actions, not only on the first prompt, is the missing layer. AgentBeam, the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions, and it is one way to add that layer.

What this means for teams

The sample shows where managed coding agents are heading: tasks queued from a chat or an MCP tool, run in disposable cloud sessions, and returned as pull requests. For teams on AWS it removes real friction, since billing, audit and access control all live in accounts they already run. It also moves the risk. A laptop agent can hurt one machine. A fleet of remote agents with write access to many repositories can hurt many, and the control that matters most is no longer the sandbox but what the agent is allowed to read and do inside it.

The three-attempt cap and the draft-PR rule are sensible defaults. They force a human to see every change. The honest caveats in AWS own text are the most useful part of the post, so read them before the setup steps.

Related reading

• AgentCorruption: one prompt hijacked every Bedrock AgentCore agent
• AWS trust in depth for agent autonomy
• AWS agent registry and runtime tool discovery
• Web Answer on Amazon Bedrock AgentCore
• Capsem VM sandbox for Claude Code, Gemini CLI and Codex
• Hugging Face SafeAgents local proxy
• Claude Code subagents and multi-agent workflows
• Vercel KVM zero-day and agent sandboxes

Details reflect the AWS post dated November 6, 2026 and may change. Check the AWS blog and the AgentCore docs for current Regions, limits and pricing.