Claude Enterprise Deployment Guide: Architecture, SSO, and Data Residency

Three Deployment Paths

Every Claude enterprise deployment starts with one decision: where does the model run, and who controls the infrastructure around it. Three paths cover almost every organization.

Direct Anthropic API

The Anthropic API is the fastest path to production. You get an API key, set a rate limit, and start sending requests within an hour. There is no infrastructure to provision and no separate cloud account to reconcile against your existing billing. The tradeoff is infrastructure control: requests leave your network boundary and travel to Anthropic's endpoints directly, so you inherit Anthropic's security posture rather than extending your own VPC controls around it. For startups, product teams prototyping a feature, or any organization without a hard requirement to keep traffic inside an existing cloud perimeter, this is the right default.

AWS Bedrock

Bedrock exposes Claude models through the same API surface AWS customers already use for other foundation models. Requests stay inside your VPC, route through your existing IAM policies, and show up in your existing AWS billing and CloudTrail logs. This matters for organizations running HIPAA-regulated workloads, SOC 2 Type II programs, or GDPR-sensitive data pipelines that already depend on AWS's compliance documentation and Business Associate Agreement coverage. If your data platform, your audit tooling, and your security team's mental model are all AWS-native, Bedrock removes an entire category of "where does this data go" questions during your next audit.

Azure AI Services

Azure AI Services serves Claude to organizations standardized on the Microsoft stack: Entra ID for identity, Azure Monitor for logging, Azure Policy for governance. The deployment model mirrors Bedrock's value proposition for AWS shops. Claude becomes one more managed service inside infrastructure your team already operates. Choose Azure when your identity provider, compliance tooling, and network architecture are already built around Microsoft's cloud, and you want Claude to inherit those controls rather than stand apart from them.

Choosing Between Them

The decision rarely comes down to model capability. The underlying Claude models are the same across all three paths. It comes down to where your compliance obligations live, which cloud already holds your sensitive data, and how much infrastructure overhead your team is willing to operate. A pilot team building an internal tool can start on the direct API and migrate to Bedrock or Azure once the use case proves out and a security review requires VPC isolation.

Identity and Access: SSO and SCIM

Once a Claude deployment moves past a pilot, identity becomes the first real engineering problem. Manually provisioning accounts for fifty or five hundred employees does not scale, and it leaves orphaned accounts behind every time someone leaves the company.

Single Sign-On

SSO connects your identity provider (Okta, Entra ID, Google Workspace) to Claude's admin console through SAML or OIDC. Users authenticate with the credentials they already have, and your IT team retains a single point of control for revoking access. Domain capture extends this further: claiming your organization's email domain means any new account created with a company email address gets automatically routed into your managed organization instead of spinning up as an unmanaged individual account outside IT's visibility.

SCIM Provisioning

SCIM (System for Cross-domain Identity Management) automates the user lifecycle itself. When HR adds someone to the identity provider, SCIM creates their Claude account and assigns the right group membership. When someone is offboarded, SCIM deactivates that account on the same cycle as every other application tied to your identity provider, with no separate ticket and no manual cleanup. For any organization rolling Claude out past a few dozen seats, SCIM is the difference between identity management as a recurring task and identity management as a solved problem.

Managed Settings

Managed settings let an admin enforce policy at the organization level rather than relying on individual users to configure things correctly. Default model access, data retention behavior, and which features are available to which groups all get set centrally and apply automatically to every account provisioned through SSO and SCIM. This is what turns a collection of individual Claude accounts into an actual managed deployment.

Data Handling and Residency

Security architects evaluating Claude need a precise answer to one question: what happens to the data sent in a prompt after the response comes back.

Zero Data Retention

Zero Data Retention (ZDR) means prompts and completions are not stored after the request completes and are not used to train future models. Under a ZDR agreement, the only artifact left behind is whatever logging your own infrastructure captures on the way out. Anthropic's systems process the request and discard the content. This is the configuration most enterprise deployments handling customer data, financial records, or anything covered by a confidentiality obligation should run under by default.

Regional Hosting

Bedrock and Azure deployments inherit the regional controls of their host cloud: you choose the AWS region or Azure region your endpoint runs in, and that choice determines where the compute (and any transient processing) physically happens. For organizations with data residency requirements tied to a specific jurisdiction (keeping EU citizen data inside the EU, for example), this is usually the deciding factor between a direct API deployment and a cloud-routed one, since the direct API does not currently offer the same region-pinning controls as the hyperscaler integrations.

What Stays Inside the Boundary

Under a Bedrock or Azure deployment, the prompt content itself still has to reach the model. That part is unavoidable for any hosted LLM. What changes is everything around it: network routing stays inside your VPC, authentication uses your existing IAM or Entra credentials, and audit logging lands in your existing CloudTrail or Azure Monitor pipeline instead of a separate system you have to reconcile against. Document this boundary explicitly during your security review. The most common audit finding in early Claude deployments is not a data leak. It is the absence of a written description of exactly what crosses the boundary and what does not.

Connecting Claude to Internal Data

A Claude deployment that only answers from general knowledge solves a narrow set of problems. Most enterprise value comes from connecting the model to internal knowledge bases, ticketing systems, and line-of-business tools.

RAG for Internal Knowledge

Retrieval-augmented generation (RAG) is the standard architecture for grounding Claude in internal documents. Your knowledge base (wikis, policy documents, support tickets, contracts) gets chunked, embedded, and stored in a vector database. When a user asks a question, the system retrieves the most relevant chunks and includes them in the prompt alongside the question, so Claude answers from your actual documentation instead of guessing. The hard part of a RAG deployment is rarely the model call. It is chunking strategy, embedding refresh cadence, and access control on the retrieval layer itself, since a RAG system that ignores document-level permissions will happily surface content a user should not be able to see.

Model Context Protocol

Model Context Protocol (MCP) is an open standard for connecting Claude to external tools and data sources in a structured way. Instead of writing one-off integration code for every system Claude needs to reach, an MCP server exposes a defined set of capabilities (read this database, call this internal API, search this ticketing system) and Claude calls into them through a consistent protocol. Think of it as the connector layer between the model and your internal systems: it standardizes how Claude requests information or takes action, rather than every team inventing its own integration pattern.

MCP is still an emerging standard. Treat early MCP connectors as you would any new integration surface: review what each server exposes, test it against a narrow use case before widening access, and assume the ecosystem of available connectors will keep changing for the next several release cycles. The protocol's value is architectural: a single governable point where Claude meets your internal systems, not a guarantee that every connector you find is production-hardened.

Governance

Governance is what keeps a Claude deployment auditable as it scales past the team that built it.

Managed Settings and Policy Enforcement

Managed settings, covered above for identity, do double duty as a governance control. An admin sets data retention behavior, default model selection, and feature availability once at the organization level, and every user provisioned through SSO inherits that policy without being able to override it locally. This is what makes governance enforceable rather than aspirational: policy that depends on individual users configuring their own settings correctly is not policy. It is a suggestion.

Audit Logging

Every deployment path should feed usage logs into whatever SIEM or log aggregation system your security team already monitors. Bedrock and Azure deployments do this natively through CloudTrail and Azure Monitor. A direct API deployment needs an explicit logging layer built into the integration, since there is no surrounding cloud platform capturing it automatically.

Connector and MCP Governance

As MCP connectors proliferate, someone needs to own the list of which connectors are approved, what each one can read or write, and who has permission to install a new one. Treat this the same way you would treat OAuth app approval for any other SaaS platform: a connector that can read your CRM or write to your ticketing system needs the same scrutiny as a third-party app requesting the equivalent API scopes. Without an explicit approval process, connector sprawl becomes the next shadow IT problem.

A Practical Rollout Sequence

Deployments that stall usually try to solve identity, governance, and org-wide rollout simultaneously, in week one. A sequence that works in practice:

1. Pilot a Narrow, Measurable Use Case

Pick one workflow with a measurable outcome (contract review time, support ticket resolution time, code review turnaround) and run it with a small group on the direct API. The goal is evidence, not infrastructure. You want a number to point to before you ask for budget to build out SSO and governance.

2. Stand Up Identity

Once the pilot justifies wider access, connect SSO and SCIM before adding more users manually. Retrofitting identity onto fifty existing individual accounts is more work than building it before account number fifty exists.

3. Define Governance Policy

Write down data retention settings, which deployment path the organization standardizes on, and who approves new MCP connectors. Set these as managed settings before the user base grows past the point where everyone can be trusted to configure things consistently on their own.

4. Roll Out in Phases

Expand by department or function rather than flipping access on for the entire organization at once. Each phase surfaces integration gaps (a connector that needs broader access, a workflow that needs a different deployment path) while the blast radius of any misconfiguration is still small.

Deploying Claude with Mindcat

Mindcat deploys Claude for enterprises across the API, AWS Bedrock, and Azure AI Services paths described above, with the governance, security configuration, and adoption support built into the engagement rather than left for your team to assemble afterward. That includes architecture review to select the right deployment model for your compliance posture, SSO and SCIM setup against your existing identity provider, RAG implementation against your internal knowledge base, and MCP integrations with the tools your teams already use.

If your organization is past the pilot stage and evaluating what a governed, audited Claude deployment looks like in practice, the next step is an architecture review against your specific compliance requirements and existing cloud footprint.