Phase 2: Foundation and Access Layer - The Infrastructure Nobody Wants to Build

Three months into a Claude deployment, a team gets frozen.

Not by a technical failure. By a governance review. A CISO asks three questions: which employees had accessed which Claude models, which business unit had spent what on API calls, and whether multi-factor authentication was actually being enforced across the deployment. The answers come back: we do not know, we cannot tell, and probably not for everyone.

The deployment is not insecure in a dramatic way. It is ungoverned in a quiet way. Individual developers hold direct API keys. There is no gateway to route through. Cost attribution is a spreadsheet someone updates manually when they remember to. The SSO integration exists, but MFA enforcement was never validated for all role types.

The review puts the deployment on hold pending a governance remediation that should have been the starting point. Weeks of use case work get paused while the foundation is rebuilt underneath it. When the teams go back to their use cases, half of the prompt work needs to be redone because the production routing config and caching behavior changed the effective context.

That is what Foundation deferral costs. Not a clean rework. A messy one, at a moment when momentum has already peaked.

This is the second deep-dive in the series on the enterprise Claude deployment roadmap. Phase 1 covered discovery and assessment. This one covers Phase 2: the eleven tasks that build the infrastructure layer before any use case code is written. Weeks three through five, twelve to fifteen working days.

The pillar piece named the failure mode plainly: teams build use cases first because use cases are visible and infrastructure is not. Phase 2 is the remedy. Every task here produces a component that something in Phase 3, 4, or 5 depends on. Skip or compress any of them and the dependency shows up broken later, at a point when the cost to fix it is higher and the organizational will to absorb a delay is lower.

The eleven tasks organize into six groups. They are not independent. The sequencing matters.

2.1: Enterprise Workspace Provisioning

The starting point for everything else. The Claude Enterprise workspace gets created: org name, admin users, data retention policy, initial API keys for development, staging, and production environments. Three separate key environments, not one shared key rotated across contexts.

The data retention decision is not administrative. It has compliance implications set in Phase 1, Task 1.4. If the regulatory requirements mapping identified a ninety-day retention limit, that gets configured here. If the organization's legal hold requirements mandate longer retention, that gets configured here. A default setting chosen for convenience that conflicts with the compliance requirement will require a workspace reconfiguration later, and workspace reconfiguration in a live enterprise environment is not trivial.

The three-key environment structure is the thing most teams skip in favor of one key that developers share. The reason to separate them is that you cannot rotate a production key without disrupting development work if they are the same key. Separation is a one-time decision that prevents a recurring operational problem.

2.2: SSO Integration

SSO connects the organization's identity provider (Okta, Azure AD, Google Workspace) to the Claude workspace via SAML or OIDC. IdP groups map to Claude workspace roles. MFA enforcement gets enabled and validated. The login flow gets tested before any end users touch it.

2.3: RBAC Policy Design

The RBAC design defines five roles: workspace admin, team admin, developer (API access plus Claude Code), knowledge worker (Claude.ai only), and read-only. Each role maps back to an IdP group so that role changes happen in the IdP and propagate automatically rather than requiring manual seat management.

The failure mode here is compression in the wrong direction. Two things happen when teams rush RBAC: first, everyone gets developer access because it is easier to grant broad permissions than to design the actual role hierarchy. Second, the escalation path for role changes never gets documented, which means role changes later require finding whoever did the original setup and asking them to handle it manually. Neither of these is catastrophic immediately. Both become operational debt that compounds over the length of the deployment.

The validation for these two tasks is Task 2.11: a test matrix that verifies every role type can do what it should be able to do and cannot do what it should not. Not 'does SSO work for a developer account' but 'does a knowledge worker correctly get denied API access, does MFA actually enforce for all role types, and does an IdP group change propagate to the workspace within the expected window.' That test matrix is the evidence the security team needs to sign the Phase 2 gate.

2.4: API Gateway

The gateway is the most important infrastructure component in the entire six-phase deployment. It is also the one most likely to be replaced by a workaround.

The workaround is direct API keys distributed to developers. It works at low scale and early in a deployment. It fails when you need to answer the CISO's questions from the opening of this article.

The gateway needs to handle five things: API key management and rotation for the production key, request logging with configurable detail level (some use cases cannot log request content because of data sensitivity), response logging with the same configurability, cost tagging by team and project, and routing to the correct model and endpoint. Routes required are /v1/messages, /v1/messages/batches, and /v1/messages/count_tokens. The last one is frequently missed and surfaces as a problem when teams add token counting to their applications in Phase 3 and discover the gateway does not handle that route.

2.5: Model Routing Rules

Model routing rules live in the gateway, not in application code. The default is Sonnet 4.6 at medium effort for any request that does not specify otherwise. Override rules route complex reasoning workloads to Opus and classification or high-volume workloads to Haiku. Deprecated model versions get blocked rather than silently falling through to an alias that may change behavior without notice. This logic does not belong in ten different application codebases. It belongs in one place that can be updated once and affects the entire deployment.

2.6: Prompt Caching Configuration

Prompt caching is the most consistently underused cost control mechanism in enterprise Claude deployments. The setup is straightforward: identify system prompts that are shared across use cases, place cache_control breakpoints at the appropriate positions, and measure cache hit rates in the development environment. The target is 70 percent or higher on system prompt tokens, which translates to roughly 90 percent cost reduction on those tokens. A deployment that skips this step and runs for six months pays substantially more than necessary and then has to retrofit caching into a live system, which requires prompt restructuring and regression testing against existing evaluation baselines.

2.7: Cost Allocation

Cost allocation connects the Anthropic Analytics API to the organization's cost tracking. The output is a weekly report showing spend by workspace, team, project, and model. Budget thresholds per team with alerts at eighty percent and one hundred percent of budget. The alert at eighty percent matters more than the alert at one hundred. By the time a team has hit their budget ceiling, the work is done and the spend is real. The eighty percent alert creates a conversation before the overage, not after.

2.8: Observability Stack

The observability stack configures OpenTelemetry export from the gateway into the organization's existing APM tool (Datadog, New Relic, Grafana, or equivalent). Four dashboards at minimum: request volume over time, latency at p50, p95, and p99, error rate broken out by error type, and cost per request by model and team. These are not vanity metrics. The latency histogram is how you detect when a use case is silently degrading. The error rate breakdown is how you distinguish an Anthropic API issue from a gateway configuration problem from an application bug. The cost per request trend is how you catch prompt regressions before they appear in the monthly bill.

2.9: Acceptable Use Policy

This task is owned jointly, but the delivery partner owns ensuring it gets done. It is the task most likely to slip because it requires a cross-functional conversation involving legal, HR, and IT, and nobody wants to facilitate that conversation.

The AUP has to specify five things: what data classifications are permitted in Claude requests (this is the direct output of Phase 1, Task 1.3, turned into a policy statement), what use cases are prohibited, how PII must be handled before it is included in a request, what the output review requirements are for any Claude-generated content that will be sent to external parties, and how incidents get reported and escalated.

The failure mode is not having an AUP and then having an incident. The second failure mode is having an AUP that nobody has read because it was published in a SharePoint folder and never referenced during onboarding. The AUP gets built into the Phase 5 onboarding flow, the rollout training materials, and the Claude.ai workspace welcome message. If it exists only as a document, it does not function as governance.

2.10: End-to-End Smoke Test

The smoke test is the gate condition in operational form. A developer authenticates through SSO, receives an API key scoped to their role, sends a request through the gateway, receives a response, and the team verifies that logs appeared in the observability stack and cost attributed correctly to the developer's team. This test is documented with expected results written down before the test runs. It is not a manual click-through. It is a repeatable test case that gets run again after any infrastructure change and again at the start of Phase 3.

2.11: RBAC Test Matrix

The RBAC test matrix covers every role type attempting every operation. The test records both the operations that should succeed and the operations that should fail. A knowledge worker attempting an API call should get a clean denial with an appropriate error message, not a silent failure or an unexpected success. An admin changing an IdP group should see the change propagate to workspace roles within a defined window. MFA should be enforced for all role types without exception.

Both tests need to produce written evidence. Not screenshots of a successful login. Documented test cases with expected results, actual results, and pass or fail determinations. That documentation is what the security team signs against at the Phase 2 gate.

The Gate

Four conditions, all required.

The security team validates SSO and RBAC using the test matrix evidence from Task 2.11. The platform team confirms the API gateway is routing correctly and the observability stack is capturing data. Finance confirms cost tracking is attributing spend to the correct teams. The first real API request traverses the production path end to end: authenticated, through the gateway, logged, cost-attributed, and with the response confirmed in the application.

That last condition is specific. Not 'the gateway is deployed and we believe it works.' A named request, through the production path, with the log entry and cost attribution record as evidence. That specificity is what separates a genuine gate from a checkbox.

Without all four conditions met, Phase 3 does not start. Phase 3 builds use cases against the foundation. If the foundation is not verified, use case work built on top of it inherits every assumption that turned out to be wrong, and those wrong assumptions do not surface until Phase 4, when fixing them requires putting use case code into maintenance mode while the infrastructure underneath it is corrected.

What Gets Deferred and Why

Three tasks see the most pressure in Phase 2.

The API gateway gets replaced by direct keys because the gateway requires infrastructure work that delays the first working API call by several days. The delay is real. The cost is paid in Phase 4 when the governance review happens and the questions the CISO asks cannot be answered.

Response logging gets disabled because someone on the client team is concerned about sensitive data appearing in logs, and disabling logging is faster than configuring per-use-case logging rules. The correct solution is configurable logging that is on by default and disabled selectively for sensitive use cases. The shortcut is no logging, which means the observability stack has request volume and latency but no way to debug a quality regression or investigate a potential data incident.

RBAC gets flattened because the role hierarchy design conversation takes longer than expected and everyone needs access before the conversation concludes. Everyone gets developer access as a temporary measure that becomes permanent. The escalation path for role changes never gets documented. Six months later the deployment has no meaningful access control because the structure was never built.

Phase 3, Pilot Implementation, opens next. It is where the use cases get built against the foundation Phase 2 creates, where the MCP servers that connect Claude to internal systems get constructed, and where the evaluation frameworks that determine whether the pilot has earned the right to move to hardening get established. The Phase 3 gate is the most demanding in the deployment: it requires value confirmation, security approval, and cost alignment, all three, before Phase 4 begins. Next in the series: what that build actually looks like across fourteen tasks.