Extend Claude Code to remote sessions on Amazon Bedrock AgentCore with security controls

AWS published a sample, sample-remote-coding-agent, that runs Claude Code as a remote agent on Amazon Bedrock AgentCore runtime, giving each coding task its own isolated session inside the customer's AWS account and returning a GitHub pull request for review. The sample preserves Amazon Bedrock data controls, including no use of customer content for model training, temporary IAM credentials, AWS PrivateLink VPC connectivity, and optional zero data retention, with Mantle's zero operator access design barring AWS operators from accessing prompts or completions. AWS cites billing through existing AWS accounts with no per-seat licenses, CloudTrail audit logging, and geographic inference profiles for data residency as reasons customers choose Bedrock as Claude Code's model provider.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ Extend Claude Code to remote sessions on Amazon Bedrock AgentCore with security controls You might already run Claude Code locally on your laptop, backed by Amazon Bedrock. This post shows how to go a step further: run it as a remote agent on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. The sample uses AgentCore runtime, a capability of Amazon Bedrock AgentCore, so every task runs in its own isolated session inside your AWS account. You offload a coding task, close the laptop, and come back to the result. We first discuss why teams choose Amazon Bedrock for Claude Code and highlight a few key security characteristics. Then, we discuss the remote agent architecture and walk through an accompanying sample, sample-remote-coding-agent https://github.com/aws-samples/sample-remote-coding-agent , that implements it. The sample runs each task in its own AgentCore runtime session and returns a GitHub pull request for you to review and merge. Along the way, we show how the Amazon Bedrock data controls stay intact when a task runs remotely. Why customers run Claude Code on Amazon Bedrock Customers choose Amazon Bedrock as Claude Code’s model provider for many reasons. These include billing and credits through their existing AWS account with no per-seat licenses, audit logging in AWS CloudTrail, and geographic inference profiles for data residency. Amazon Bedrock also provides three valuable security characteristics: - Data protection. Amazon Bedrock doesn’t use your content to train models or share it with model providers, and providers can’t access your prompts, completions, or the Amazon Bedrock service logs. Amazon Bedrock is in scope for SOC, ISO, and FedRAMP Moderate, is HIPAA eligible, and can be used in compliance with the GDPR. See Compliance validation for Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/compliance-validation.html for details. - Access through controls you already govern. Claude Code calls Amazon Bedrock with temporary AWS Identity and Access Management IAM credentials, and you can sign in through an identity provider such as Microsoft Entra ID or Okta by following the Guidance for Claude Code with Amazon Bedrock https://docs.aws.amazon.com/solutions/claude-code-with-amazon-bedrock/ . AWS PrivateLink gives your Amazon Virtual Private Cloud Amazon VPC a private connection to Amazon Bedrock. - Control over retention and operator access. Mantle, the next-generation inference engine for Amazon Bedrock, is designed for zero operator access ZOA , so AWS operators have no technical means to access customer data such as your prompts or completions. You also control whether the prompts and outputs from your inference requests are retained. You can configure zero data retention ZDR to make sure that no request or response data is written to durable storage by AWS or shared with the model provider. See Data retention https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html and Exploring the zero operator access design of Mantle https://aws.amazon.com/blogs/machine-learning/exploring-the-zero-operator-access-design-of-mantle/ for details. Why teams add a remote coding agent Remote coding agents have become a common pattern because they turn a coding task into a hand-off. You assign the task, close the laptop or move on to other work, and come back to the result. Several tasks can run at once instead of competing for one machine, and each task runs in its own disposable environment, outside of your laptop and the credentials in your shell. The result comes back as a pull request that a teammate can review like any other change. The pattern has trade-offs: you steer less while a task runs, the environment needs some setup, and cost is harder to predict. The solution in this post runs the work in your own AWS account. Every task runs as an AgentCore runtime session that belongs to your account, and every model call goes to Amazon Bedrock, so those calls inherit the security characteristics described in the previous section. The sample suits some tasks better than others: - Good fit. Scoped features, bug fixes, and tests on a trusted repository that declares its own setup and test commands. - Not a fit. Untrusted code, because the agent runs the repository’s own commands and can’t make them safe, and open-ended work, because each task stops after three attempts. Solution overview The following diagram shows how a task flows from Claude Code or the web console through the control plane to an isolated AgentCore runtime session in your VPC, and back out as a GitHub pull request. The workflow consists of the following steps: 1. Submit. From Claude Code, the sample-rca plugin runs a local Model Context Protocol MCP server, a small helper that gives Claude Code extra tools. The server signs each request with your AWS credentials and calls an IAM-authorized Amazon API Gateway HTTP API. Alternatively, you submit from a web console that Amazon CloudFront serves. You sign in to it with Amazon Cognito, and it calls a Cognito-authorized API. 2. Queue. An AWS Lambda function screens the task prompt with an Amazon Bedrock Guardrails guardrail, then records the task in Amazon DynamoDB and puts it on an Amazon Simple Queue Service Amazon SQS queue. A dispatcher function then starts one AgentCore runtime session for the task, on the runtime that belongs to that repository. 3. Run in an isolated session. Each registered repository has its own AgentCore runtime, which runs one container image stored in Amazon Elastic Container Registry Amazon ECR . The image carries the Claude Code CLI, the Claude Agent SDK that drives it, git, and make. AgentCore runtime runs every session in its own microVM, a lightweight virtual machine with isolated CPU, memory, and filesystem. The microVM runs inside a VPC with private endpoints to Amazon Bedrock and the other AWS services the agent uses. 4. Check out and plan. In the session, the agent gets a GitHub access token from AgentCore Identity, a capability of Amazon Bedrock AgentCore, and clones the repository. It then searches AgentCore memory, another AgentCore capability, for lessons that earlier tasks learned about this repository. Next, Claude Code plans the change with Claude Opus on Amazon Bedrock. 5. Code and verify. Claude Code writes the change with Claude Sonnet. The agent then runs the repository’s own setup and test commands in the same session. 6. Review. Claude Code reviews the result with Claude Opus and can send it back to planning for another attempt, up to three attempts in total. Throughout the run, each step records what happened in AgentCore memory, which extracts lessons, such as a build step with a hidden prerequisite, for later tasks on the same repository. 7. Open a pull request. The agent pushes an agent/<taskId branch and opens a pull request that records the verification command, its exit code, and the attempts used. The pull request opens as a draft unless verification passed. You review it and merge it. The agent never merges. Figure 2 shows the same steps as a flow. It makes two things easier to see: review can send a task back to planning, and every step reports its status to DynamoDB, which is how Claude Code and the console follow a task after you hand it off. The next section describes the security controls that the solution adds to your local setup. Security controls for the solution Running tasks remotely keeps the security characteristics of Claude Code on Amazon Bedrock for model calls and adds controls of its own. The following sections describe each control. The same Amazon Bedrock, now for remote tasks In each session, Claude Code uses Amazon Bedrock as its only model provider. Calls go through a private Amazon Bedrock endpoint and are signed with the runtime’s IAM execution role, and the container holds no other AWS credentials. Model calls from remote tasks therefore keep the same security characteristics as Claude Code on your laptop. A fresh, isolated sandbox for every task Each task runs in its own AgentCore runtime session, a dedicated microVM whose memory is sanitized when the session ends. AgentCore memory carries lessons from one task to later tasks on the same repository. Short-lived GitHub access through AgentCore Identity The agent never holds a long-lived GitHub credential. The sample creates one GitHub App with read and write access to Contents and Pull requests and registers it with AgentCore Identity, which keeps the app’s client secret in its token vault. You install the app only on the repositories the agent can change and authorize each one once through three-legged OAuth 3LO . After that, each container gets a user-to-server token from Identity that expires after 8 hours and is refreshed automatically. The token reaches only repositories where the app is installed and the authorizing user has access, and commits are authored by the app’s bot account. A guardrail on every task prompt Before a task is queued, the API screens its prompt with an Amazon Bedrock Guardrails guardrail through the ApplyGuardrail API. The guardrail uses the Standard tier, whose filters understand code. At low strength, it’s configured to block jailbreak and prompt injection attempts and misconduct, such as a request for malware. It’s also configured to block AWS access keys and other secrets. A blocked prompt returns PromptBlockedByGuardrail , and if the guardrail can’t respond, the task is refused. The guardrail screens what you type, not what the agent reads during a run, so it doesn’t see prompt injection that arrives through repository files or command output. Screening every model call would re-evaluate the full context on each call, billed by text volume, and would flag Claude Code’s own system prompt as a prompt injection attempt. Private networking in your VPC Each AgentCore runtime runs in private subnets of a VPC in your AWS account, with VPC endpoints for the AWS services it calls, so the prompts, task state, and logs that it sends to those services don’t cross the internet. The only route to the internet is a NAT gateway for GitHub and package registries, and the security group allows only outbound HTTPS. An Amazon Route 53 Resolver DNS Firewall blocks the model vendor’s own domains, such as api.anthropic.com , but as a denylist it doesn’t stop other HTTPS traffic. For production, consider an AWS Network Firewall domain allowlist. Least-privilege permissions The AgentCore runtime IAM role can invoke only Anthropic models on Amazon Bedrock, read and write only its own repository’s task records and memory, and pull only the agent image. It’s explicitly denied the AgentCore Identity control plane, so a task can’t change the GitHub credential provider that every repository shares. A human decides what ships The agent opens pull requests but never merges them. Turn on branch protection for the default branch so that every change gets a review. Solution walkthrough The rest of this post walks through deploying the sample in your own AWS account. You deploy the stacks, connect GitHub and register a repository, run a coding task from the web console or Claude Code, and review the pull request that it opens. Deployment takes 15–25 minutes, and registering a repository takes another 8–12 minutes. Prerequisites Before you begin, make sure that you have the following: - An AWS account, ideally a dedicated one, in a Region that offers AgentCore runtime V2: US East N. Virginia us-east-1 , US East Ohio us-east-2 , US West Oregon us-west-2 , Asia Pacific Tokyo ap-northeast-1 , or Europe Ireland eu-west-1 . This post uses us-west-2 . For model availability by Region, see Supported models by AWS Region in Amazon Bedrock https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html . - The AWS Command Line Interface AWS CLI https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html , with credentials for that account. - Docker https://docs.docker.com/get-started/get-docker/ , running. The deploy builds a roughly 1.3 GB