You Can't Stop Developers Using Claude, So Route It Through Bedrock

The Real Question Is Not Whether, But Where

Your developers are using Claude right now. They have been for six months. The question isn't whether to allow it, that ship sailed when the first engineer pasted a schema into claude.ai to debug a join. The question is whether you route that traffic through AWS Bedrock with PrivateLink so prompts never hit Anthropic's logs, or whether you let it stay in the browser where your DLP tools can't see it and your compliance team can't audit it.

Mid-market SaaS companies shipping Agentforce stacks hit this in Q2 2025 when they realized their agent orchestration was calling Claude API directly from Heroku dynos. The prompts contained customer PII, the responses went into Slack threads, and the security posture was "we asked engineers not to." That works until the SOC2 audit.

Bedrock solves this by running Claude Opus and Sonnet inside your AWS account. You call bedrock:InvokeModel, the inference happens in a VPC you control, and Anthropic never sees the prompt or the response. You still get Claude, same models, same quality, same speed, but the data path is VPC → Bedrock endpoint → your application. No external egress. This is the setup that lets a FinTech company tell their auditor "we use Claude, and here's the AWS PrivateLink config that proves it never leaves us-east-1."

Two Rollout Patterns: Platform Team Ships the Plumbing, Devs Get CLI Access

The source piece walks through admin setup and developer onboarding as two separate checklists. That split mirrors how this actually rolls out.

Platform team work (one time, takes a Thursday):

1. Enable Bedrock in your AWS account. Request model access for Claude Opus and Sonnet in the Bedrock console, approval is instant for most accounts, 24 hours if you're new.
2. Create a PrivateLink endpoint in your VPC. This is the VPC interface endpoint that routes bedrock.us-east-1.amazonaws.com traffic internally. Lock it down with a security group that only allows traffic from your app subnets.
3. Write an IAM policy that grants bedrock:InvokeModel on the Claude model ARNs. Attach it to a role your application pods assume, or to a user group for CLI access.
4. Deploy a proxy or bastion if you want developers to call Bedrock from their laptops during development. Alternatively, require them to run inside a dev VPC that has the PrivateLink endpoint.

Developer work (per engineer, takes 20 minutes):

1. Install the AWS CLI and configure credentials that assume the Bedrock IAM role.
2. Install Claude Code CLI (Anthropic's official tool, not a third party thing). Configure it to use --api-mode bedrock and point it at your region.
3. Test with a prompt that includes a fake schema or internal service name. Verify the response comes back and check CloudTrail to confirm the bedrock:InvokeModel call logged.
4. Add the Bedrock endpoint to MCP (Model Context Protocol) server configs if you're running agents that need to call Claude as a tool. MCP is Anthropic's protocol for letting agents invoke models and tools in a structured way, it's what Agent Builder uses under the hood when you build an Agentforce agent that calls Claude for reasoning steps.

The two-tier rollout prevents the common failure mode where security ships a locked-down config and developers route around it because it's too hard to use. If the platform team ships PrivateLink and the devs get a working Claude Code CLI that Just Works, adoption is fast.

The Compliance Win: No Prompts in Anthropic's Logs, Full Audit Trail in CloudTrail

The reason this setup passes SOC2 and HIPAA audits is that AWS Bedrock has a contract addendum stating that prompts and responses are not used for model training and are not logged by Anthropic. The Bedrock service logs the API call metadata (timestamp, model ID, token count) to CloudTrail, but the actual prompt text stays in memory during inference and gets discarded. Your auditor can verify this by reading the AWS Bedrock Data Processing Addendum and checking your CloudTrail logs.

This is different from calling Claude API directly, where Anthropic's terms allow them to log prompts for abuse monitoring (they don't use them for training, but they do keep them for 30 days). Bedrock removes that logging entirely. For a FinTech company that processes credit applications, this is the difference between "we can use Claude" and "we cannot use Claude because the prompt contains SSNs."

The second compliance lever is IAM. You can grant bedrock:InvokeModel to specific users or roles and revoke it centrally. When an engineer leaves, you don't have to chase down API keys they saved in their .bashrc, you just remove them from the IAM group and their Claude access stops working. Compare that to claude.ai where there's no central control plane and engineers are logging in with personal Google accounts.

The Cost Tradeoff: Bedrock Is 20% More Expensive, But You're Paying For The Audit Trail

Bedrock pricing for Claude Sonnet is roughly 20% higher than calling Claude API directly: $3 per million input tokens on Bedrock vs. $2.50 on Claude API as of May 2025. For a mid-market company running 50 million tokens a month (about 50 agent sessions per day, each with 10-turn conversations), that's an extra $250/month. The tradeoff is that you get PrivateLink, CloudTrail logging, IAM-based access control, and a contract that says Anthropic never sees your prompts. Most companies shipping production Agentforce stacks pay that premium without hesitation because the alternative is "we don't have Claude in the security questionnaire."

The hidden cost is platform team time to maintain the PrivateLink endpoint and IAM roles. Budget 2 hours per quarter for access reviews and endpoint updates. If your platform team is already running a dozen VPC endpoints (for S3, RDS, etc.), this is marginal. If you're not using PrivateLink anywhere, this is your first one and you'll spend a day learning the routing rules.

The Downstream Integration: Agentforce Agents Call Bedrock, Not Claude API

Once Bedrock is live, your Agentforce agents running in Agent Builder need to call it instead of Claude API. Agent Builder has a "Custom Invocable Action" primitive that lets you call any HTTP endpoint from a Flow. You write an Apex class that signs the Bedrock request with AWS SigV4, calls bedrock:InvokeModel, and returns the response to the agent. This is 50 lines of Apex, most of it boilerplate.

The pattern: Agent Builder agent needs to summarize a case history. The agent's Flow invokes your Apex action. The Apex action pulls the case from Data Cloud, formats it into a prompt, calls Bedrock Claude Sonnet, and returns the summary. The agent inserts the summary into the email draft. At no point does the case history leave your AWS account or Salesforce org. This is the setup that HealthTech companies need when the case history contains HIPAA data.

If you're running agents on Databricks Mosaic AI instead of Agent Builder, the equivalent is to use the Mosaic AI Agent Framework and configure the LLM provider as Bedrock. The agent DAG calls your Bedrock endpoint instead of OpenAI or Anthropic. Same pattern, different orchestration runtime.

Bedrock turns "we can't use Claude because of data residency" into "we use Claude and here's the architecture diagram that proves it never leaves us."