Enterprise Claude Code without leaking your code

The short version: run Claude Code against Amazon Bedrock, put the Bedrock API behind an interface VPC endpoint, and scope access with IAM. Your prompts and your source never touch the public internet or Anthropic's own infrastructure; they stay inside your AWS account, in your chosen region. Under the commercial terms that govern Bedrock, your code is not used to train models. The wiring takes a few hours. The governance — who reviews, who approves, who is accountable when AI writes the diff — takes longer and matters more.

Does Anthropic train on our code?

On Bedrock, no. When you call Claude through Amazon Bedrock, AWS processes the request inside your selected region, governs it through IAM, and does not share your prompts or completions with the model provider. Anthropic does not retain that traffic for training.

There is a sharper point I make to security teams. The only route by which Anthropic trains on prompts under commercial terms is an explicit opt-in — historically the Developer Partner Program — and that programme is first-party API only. It does not exist on Bedrock or Vertex. So on Bedrock there is no toggle a developer could flip, by accident or otherwise, that turns training on. The absence of the opt-out is itself the proof: you cannot opt into something that isn't offered.

This is also the line that separates consumer Claude from commercial. Consumer plans and their terms are a different agreement. Bedrock access falls under Anthropic's commercial terms (and AWS's own service terms), where training on customer content is contractually excluded. When a CISO asks "how do we prove this to audit," the answer is a document trail: the AWS Service Terms for Bedrock, Anthropic's commercial terms, and your own IAM policy showing the only egress path is the in-region Bedrock endpoint.

How does Bedrock plus a VPC endpoint keep code in the account?

By default a Bedrock call from a laptop or CI runner would go out over the public internet to a regional AWS endpoint. The VPC endpoint changes that. You create an interface VPC endpoint (AWS PrivateLink) for bedrock-runtime, and traffic to Bedrock now resolves to a private IP inside your VPC. No internet gateway, no NAT, no public egress.

Then you lock it down from both ends:

• IAM scopes who can call which models. A policy that allows only bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on the specific Claude model ARNs, and nothing else.
• The endpoint policy scopes what the endpoint itself will carry.
• An SCP or aws:SourceVpce condition can reject any Bedrock call that does not arrive through your endpoint — closing the "someone used a personal access key from home" hole.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:eu-west-1::foundation-model/anthropic.claude-*",
      "Condition": {
        "StringEquals": { "aws:SourceVpce": "vpce-0abc123def456" }
      }
    }
  ]
}

Claude Code itself is pointed at Bedrock with a couple of environment variables — CLAUDE_CODE_USE_BEDROCK=1 and the region — and it picks up standard AWS credentials. From the developer's side it behaves identically. From the network's side, every byte of prompt and code went to a private endpoint in your region and stayed there.

What does zero-data-retention actually cover — and what doesn't it?

This is where I slow people down, because "ZDR" gets over-claimed.

What the in-region, no-training posture covers: Anthropic does not keep your prompts or outputs to train models, and AWS does not share them with the provider. Your content stays in the region where the call was processed, encrypted in transit and at rest.

What it does not automatically mean:

• It is not the same as "nothing is logged anywhere." Bedrock has its own invocation-logging feature you can turn on (to S3 or CloudWatch) — useful for your audit, but that's your log in your account, and you should know it exists and decide whether to enable it.
• Abuse/safety processing can exist as a separate, time-boxed mechanism under some configurations; if your threat model requires literally zero retention end to end, that has to be confirmed in writing for your specific setup rather than assumed from a marketing line.
• Claude Code keeps local state — session history, transcripts, cached context on the developer's machine. That's a laptop-hardening and DLP question, not a Bedrock one, and it's the part teams most often forget.

So the honest framing is: the cloud path is in-region, IAM-scoped, and not trained on. Retention specifics and the endpoints (laptops, CI runners) are yours to govern.

Who owns review and release once AI writes the code?

This is the question that actually decides whether the deployment is safe, and it has nothing to do with networking. If an AI agent can open a pull request, the controls that already protect your main branch are the controls that protect you from the AI. You don't need new machinery — you need to refuse to weaken the machinery you have.

Concretely:

• Protected branches. No direct pushes to main. Everything is a PR.
• Required human review. At least one human approval on any AI-authored change. The AI is a contributor, not an approver.
• CI/CD as the gate. Tests, SAST, secret scanning, and dependency checks must pass before merge — same as for humans, no exemptions for "the AI wrote it."
• No self-merge. The identity that opened the PR cannot be the identity that approves it.

And a plain RACI so accountability isn't vague:

The single most important word in that table is Accountable, and it is always a named human. AI shifts who does the typing; it does not shift who is answerable when something ships broken. A team that can't fill in that column shouldn't be merging AI-authored code yet.

How long does it actually take to stand up?

The AWS-side admin is genuinely small — typically in the region of two to three hours for someone who knows their way around IAM and VPCs: request Bedrock model access for the Claude models, create the interface VPC endpoint, write the IAM policy and endpoint policy, add the aws:SourceVpce guard, and point Claude Code at Bedrock. You can validate the whole path with a single test invocation and a flow-log check confirming traffic went private.

The governance work is the longer pole, and it's where the real risk lives — agreeing the RACI, wiring approval gates your developers won't try to route around, and getting security sign-off on the data-flow document. That's days of conversation, not hours of clicking. Budget accordingly: the technical setup is an afternoon; the operating model is the project.

When is this worth doing?

This setup is worth it when your code is the asset — trade secrets, regulated data, contractual confidentiality obligations — and you still want the productivity of Claude Code. The Bedrock-plus-VPC-endpoint pattern lets you say, with evidence, that prompts and source never left your account and were never used for training.

It is over-engineering if you're a small team on open-source-ish code with no compliance surface; first-party API with commercial terms and ZDR is simpler and may be all you need. The trade-off is real: Bedrock adds an IAM/networking layer to maintain and can lag slightly behind first-party on the very newest model availability. You're buying account-boundary isolation and a clean audit story at the cost of a bit more plumbing. For most enterprises with something to protect, that's a trade worth making — provided you do the governance, not just the wiring.