When your application calls Claude, a request containing your prompt travels from your code to a model endpoint and a response travels back. By default, that traffic goes over the public internet, encrypted with TLS. For most workloads that is acceptable: encrypted-in-transit API traffic is how nearly all SaaS works. But some organizations have policies, regulators, or contracts that require sensitive traffic to stay on private network paths. If that describes you, the good news is that this is exactly where the 3P deployment model earns its keep.
Why the network path matters (and why it sometimes doesn't)
TLS encryption already protects the content of your requests in transit. What private networking adds is a different kind of assurance: the traffic never traverses the public internet at all, so it cannot be misrouted there, your egress firewall rules stay simple, and you can prove to an auditor that the path from application to model endpoint stayed inside a controlled boundary.
Be honest with yourself about which assurance you actually need. If your driver is "encrypt data in transit," TLS gives you that on any path. If your driver is "no sensitive workload may have a route to the public internet," you need private endpoints. Security reviews go faster when you can name which requirement you are satisfying.
What private connectivity looks like on each platform
One of the practical advantages of accessing Claude through a cloud provider is that the model endpoint becomes just another managed service on that cloud, and the cloud's standard private-connectivity mechanisms generally apply.
Amazon Bedrock sits inside AWS, where the standard pattern for reaching managed services privately is a VPC endpoint (AWS PrivateLink). Traffic from your VPC reaches the service over the AWS network rather than the internet, and you can lock down which VPCs and roles may use the endpoint.
Google Vertex AI lives in Google Cloud, where Private Service Connect and VPC Service Controls are the usual tools for reaching Google APIs privately and for drawing a perimeter around which identities and networks can call them.
Microsoft Foundry runs on Azure, where Private Link endpoints attached to a resource are the standard way to keep service traffic on the Microsoft backbone and off the internet.
Claude Platform on AWS is Anthropic-operated but runs on AWS and authenticates with AWS SigV4, so it participates in an AWS-centric network architecture rather than requiring a path out to a separate vendor's infrastructure.
A necessary caveat: private-connectivity support for specific AI services changes over time, and the details (which regions, which endpoint types, which features are covered) vary. Treat the mechanisms above as the right questions to ask, and confirm current support for the specific Claude endpoint you plan to use with your cloud provider before you commit to an architecture.
Network controls beyond the endpoint
Private endpoints are one layer. A complete network story for an LLM workload usually includes a few more pieces, all of them standard cloud hygiene rather than anything AI-specific.
Egress control. If your application servers can only reach an approved list of destinations, add the Claude endpoint to that list explicitly rather than opening broad internet egress "just for the AI feature."
Identity, not just network. A private path does not decide who may call the model. Pair network controls with least-privilege IAM roles, service accounts, or resource keys so that only the intended workloads can invoke Claude, whichever path the packets take.
A single choke point. Many enterprises route all LLM traffic through one internal gateway service. That gives you one place to enforce the private path, log every request, and attribute cost, instead of auditing dozens of applications individually.
Questions to settle before the security review
Bring answers to these and the network portion of your review will be short: Which platform and region will we call? Does our provider support a private endpoint for it today, and in that region? What is our fallback if the private path is unavailable? Which subnets and identities are allowed to reach the endpoint? Where are the flow logs and API logs that prove the path taken? None of these require ML expertise; they are the same questions your network team answers for every managed service.
Where to go next
Network controls pair naturally with an audit trail, covered in Audit Logging Claude Usage, and with the broader data-flow picture in Where Does Your Data Go?. For platform basics, see the platforms overview.