Security controls are not features. They are the guardrails that determine whether a deployment is permissible at all under your regulatory framework. This chapter consolidates the controls matrix across Bedrock, Vertex, Foundry, and Snowflake Cortex, explaining how each provider handles telemetry, egress, encryption, audit logging, and identity. The controls available on each route differ materially. Where they differ, the chapter names the difference plainly so your procurement team can build a controls inventory against your requirements.
Anthropic publishes three pre-built security profiles: Standard, Restricted, and Locked Down. These compose individual configuration settings into recognisable postures. Understanding these profiles and how they map to your regulatory posture is the key decision point after you have chosen your inference provider.
How to read this chapter and the controls matrix
Security controls fall into eight categories. Each row of the matrix below represents one category. The columns represent the four deployment routes. Cells marked with a check (✓) indicate the control is available; cells with a note indicate the control is available but requires configuration or verification; empty cells indicate the control is either not documented or not available.
| Control Category | Bedrock | Vertex | Foundry | Snowflake Cortex |
|---|---|---|---|---|
| Data egress to Anthropic | No ✓ | No ✓ | Not yet | Depends on gateway |
| Telemetry (four-category opt-out) | ✓ | ✓ | ✓ | ✓ |
| OpenTelemetry export | ✓ | ✓ | ✓ | ✓ |
| Encryption in transit (TLS) | TLS 1.2+ ✓ | TLS 1.2+ ✓ | TLS 1.2+ | TLS 1.2+ ✓ |
| Encryption at rest (default) | AWS KMS ✓ | Google KMS ✓ | Azure KMS ✓ | Snowflake managed |
| Customer-managed keys (CMK) | ✓ | Verify | Verify | Verify |
| Audit logging | CloudTrail ✓ | Cloud Audit Logs ✓ | Diagnostic logs | Snowflake audit tables |
| Identity and access control | IAM ✓ | IAM ✓ | Azure AD (Entra ID) ✓ | Snowflake RBAC |
Not all rows are equivalent. Some controls are offered by the provider; others require enterprise contracts or are customer-configured. Verify configuration requirements with your account manager before procurement.
Stay with the series
This is chapter eight of a hub that breaks down every Claude deployment route with primary-source references for pricing, residency, and contractual terms. New chapters as they publish, sent to your inbox. Subscribe to the newsletter.
Data in transit and data at rest: the boundary cases
When Claude inference runs, your prompts and responses travel from the user device to your configured provider endpoint, then back to the user device for local storage. This journey divides into two phases: in-transit encryption and at-rest encryption. The two are distinct controls and apply at different points.
In-transit encryption uses TLS 1.2 as a minimum across all four routes, with TLS 1.3 recommended by providers. Cipher suites must support Perfect Forward Secrecy so that even if a long-term encryption key is compromised later, recorded traffic remains unreadable. Bedrock, Vertex, and Foundry all document TLS requirements; Snowflake Cortex operates across Snowflake's encrypted data platform. All external communication uses HTTPS on port 443.
At-rest encryption protects data stored on disk. Bedrock uses AWS Key Management Service by default; Vertex uses Google Cloud KMS; Foundry uses Azure Key Vault; Snowflake encrypts all data at rest with keys it manages. Customer-managed encryption keys (CMK) appear to be available on some routes but are inconsistently documented. Bedrock explicitly mentions CMK support in its FAQs; Vertex and Foundry CMK availability should be verified with your account manager before procurement.
The practical implication is that data encryption in both directions is table-stakes across all four routes. The variation lies in whether you control the encryption keys. For most regulated enterprises, the question is not whether encryption exists but whether you can bring your own keys and audit key usage. That requires direct conversation with your provider.
Telemetry and the four-category model
Cowork 3P documents telemetry as four independent categories, each disableable:
Essential Telemetry. Crash reports, performance data, and diagnostic metadata (app version, OS, error type, redacted stack frames). User prompts and responses are excluded. Non-Essential Telemetry. Product usage analytics and feature adoption metrics. Non-Essential Services. UI cosmetics such as connector favicons and preview iframes. Auto-Updates. Update checks and update availability notifications.
Telemetry is enabled by default. Disabling telemetry is an active choice through configuration. The operational consequence is visibility. When telemetry is enabled, Anthropic and the provider receive diagnostic data that helps them support the deployment. When you disable telemetry categories, you improve privacy but reduce visibility for support teams if incidents occur. Document this trade-off in your governance policy.
Telemetry is opt-out
Four categories enabled by default. Disabling all four achieves zero Anthropic telemetry at runtime except VM bundle download.
The Anthropic egress boundary
This is the load-bearing row of the matrix. Anthropic documents that the "no conversation data sent to Anthropic" guarantee applies only to Bedrock and Vertex deployments. For Foundry and custom gateway routes, this guarantee does not yet apply. This distinction is not a marketing claim. It is a material difference that determines whether a deployment meets specific compliance requirements.
On Bedrock, Anthropic explicitly states that after AWS takes delivery of a Claude model, AWS performs a deep copy of the inference and training software into AWS accounts for deployment. Because Anthropic does not have access to those accounts, they do not have access to Bedrock logs or customer prompts and completions. AWS's own FAQs state that your content is not used to improve base models and is not shared with any model providers.
On Vertex, Google documents that data remains in your configured region and does not reach Anthropic's systems.
On Foundry, the data privacy documentation states that Anthropic is the data processor for prompts and outputs. Critically, the documentation also states that prompts and outputs may be processed outside your region for operational purposes. Anthropic has stated that equivalent data residency guarantees for Foundry are planned but not yet live.
On Snowflake Cortex and other data-platform routes using Anthropic's gateway access, the same guarantee does not yet apply.
For any enterprise whose compliance posture depends on no conversation data reaching Anthropic's infrastructure, Bedrock and Vertex are the only two routes that currently meet this requirement as of 2026-04-22. Verify current status at the Anthropic Cowork 3P documentation before procurement.
The guarantee boundary — controls matrix row 1
Bedrock and Vertex guarantee zero Anthropic data egress. Foundry and custom gateways do not yet. This row determines regulatory feasibility.
Customer-managed keys (CMK) and encryption at rest
Customer-managed encryption keys place encryption key material under your control, not the provider's. This is a requirement for some regulated enterprises because it means the provider—and by extension, law enforcement or government agencies—cannot decrypt your data without your key material.
Bedrock documents CMK support in its FAQ. Vertex, Foundry, and Snowflake CMK status is inconsistent across their public documentation. Vertex and Foundry should be asked directly about CMK support during procurement. If CMK is a hard requirement for your compliance posture, confirm support and configuration before signing a contract. The operational implications of CMK include key rotation cadence, audit logging for key access, and recovery procedures if keys are lost or compromised.
Audit logging by provider
Audit logging captures who accessed what, when, and whether the access succeeded. Each provider routes audit logs through different systems:
AWS Bedrock uses CloudTrail to capture API calls and authentication events. The Bedrock data protection documentation recommends CloudTrail but does not explicitly confirm that CloudTrail captures all Bedrock model invocations. Clarify CloudTrail coverage with your AWS account manager, particularly whether invocation events (not just authentication) are logged.
Google Vertex uses Cloud Audit Logs (formerly Cloud Logging) to capture API calls, authentication, and configuration changes. Vertex's logging is integrated into Google Cloud's broader audit infrastructure.
Azure Foundry uses diagnostic logs and integrates with Azure Monitor. The exact events captured for Claude model invocations should be verified with Microsoft.
Snowflake Cortex uses Snowflake's native audit tables. Query history, login events, and data access are available through standard Snowflake ACCOUNT_USAGE views.
For all four routes, you are responsible for configuring log retention, querying logs, and using log data for compliance investigations. Logs are not automatically retained indefinitely. Establish log retention policies as part of your deployment plan.
Identity and credential management
Identity determines who can invoke the model and under what authority. Each provider uses its own identity system:
Bedrock uses AWS Identity and Access Management (IAM). Users authenticate as IAM users, federated identities through AWS Identity Center, IAM roles, or temporary credentials from AWS Security Token Service. Administrators define permissions using IAM policies. This is identical to every other AWS service, so if your platform team manages AWS infrastructure, they already understand the access control model.
Vertex uses Google Cloud Identity and Access Management (IAM). Users authenticate through Google Cloud service accounts, federated identity through Workload Identity, or OAuth. The permission model is similar to Bedrock—principal, action, resource, condition.
Foundry uses Microsoft Entra ID (formerly Azure Active Directory). Users authenticate through Entra ID or API keys. Anthropic Claude preview models (including Mythos) require Entra ID; other models support API key authentication.
Snowflake Cortex uses Snowflake's role-based access control (RBAC). Users authenticate to Snowflake and inherit permissions from their assigned roles.
Credential rotation is an operational requirement in all four. For Bedrock and Vertex, rotation happens through your cloud provider's credential management. For Foundry, it depends on whether you use Entra ID (federated) or API keys (manual rotation). For Snowflake, it happens through Snowflake's credential policies. Document credential rotation cadence in your runbook.
The three Anthropic security profiles
Anthropic publishes three pre-built security profiles that compose individual configuration settings into recognisable postures. You select one profile per device or deployment.
Standard is the default. Telemetry and updates are enabled. Signed extensions are required. Users can extend Cowork freely with custom tools and connectors. This profile is suitable for development and evaluation environments where visibility into application behaviour is valuable.
Restricted disables non-essential telemetry, blocks user-added connectors, and enforces workspace isolation. Enough telemetry remains active for Anthropic support to diagnose issues if problems arise. This profile is suitable for regulated enterprises that want reduced telemetry egress but retain some diagnostic visibility.
Locked Down blocks all external communication except inference requests and OpenTelemetry export. Auto-updates are disabled. Air-gapped deployment is explicitly supported. This profile is suitable for organisations with zero-egress requirements or air-gapped infrastructure. The trade-off is that support diagnostics are limited and updates must be managed manually.
MCP (Model Context Protocol) tool policies
Tools extend Claude's capabilities with external integrations—file access, web search, calculation, database queries. By default, users can install and invoke tools freely. Administrators can lock down tool use through two mechanisms:
First, administrators can disable specific built-in tools entirely using the disabledBuiltinTools configuration key.
Second, administrators can deploy managed MCP servers through managedMcpServers and define per-tool policies: allow (tool always available), ask (user must confirm per invocation), or blocked (tool unavailable). Managed MCP servers cannot be removed by end users.
This granularity is important because a tool like "file access" or "web fetch" could leak data if misconfigured. Define a tool policy inventory as part of your security configuration.
What the matrix does not cover
The controls outlined above describe the infrastructure. They do not describe:
Contractual terms (Data Processing Agreements, sub-processors, liability caps). Verify these with your legal team and account manager. Governance and change control (who can modify configuration, approval workflows, incident response). See Chapter 9 for governance frameworks. Vendor-specific compliance certifications. Bedrock, Vertex, and Foundry are certified under various frameworks (FedRAMP, SOC 2, ISO, HIPAA). Verify which certifications apply to your regulatory context.
Primary sources
- Anthropic. Cowork on 3P — Overview. Retrieved 22 April 2026.
- Anthropic. Cowork on 3P — Configuration reference. Retrieved 22 April 2026.
- Anthropic. Cowork on 3P — Telemetry and egress. Retrieved 22 April 2026.
- Amazon Web Services. Bedrock Data Protection. Retrieved 22 April 2026.
- Amazon Web Services. Bedrock FAQs. Retrieved 22 April 2026.
- Google Cloud. Vertex AI — Claude Documentation. Retrieved 22 April 2026.
- Google Cloud. Vertex AI Regional Availability. Retrieved 22 April 2026.
- Microsoft. Azure AI Foundry — Claude Data Privacy. Retrieved 22 April 2026.
- Snowflake. Cortex AI Functions. Retrieved 22 April 2026.
- Snowflake. Cross-Region Inference. Retrieved 22 April 2026.
Nothing in this article is legal advice. It names regulatory frameworks and describes how each deployment route affects compliance posture. Compliance interpretation for your specific regulatory context, jurisdiction, and client contracts must be reviewed with qualified legal counsel. Verify current provider documentation before making a procurement decision.