Infrastructure Requirements for Claude: Deployment, Data Retention and Isolation

1.Where Claude is procured, billed and authenticated

Infrastructure requirements usually come from outside the engineering team: procurement, finance, identity and compliance. The Claude Code deployment docs compare the routes to Claude on exactly these points. The comparison is written for rolling out Claude Code, but it shows how an organisation's existing cloud contracts, audit tooling and identity provider narrow the choice.

Network rules add two more options. A corporate proxy routes traffic through HTTPS_PROXY or HTTP_PROXY when every outbound request has to be monitored. An LLM gateway sits between the client and the provider when the organisation wants central usage tracking, per-team budgets or central authentication. It is configured with variables such as ANTHROPIC_BASE_URL or ANTHROPIC_BEDROCK_BASE_URL.

Sources1

2.Messages API or Managed Agents: state and data retention

The second infrastructure decision is who runs the agent loop. The Messages API gives you direct access to the model and suits custom agent loops that need fine-grained control. You build the loop, the tool execution and the runtime yourself. Claude Managed Agents is a pre-built harness that runs on managed infrastructure. It handles long-running execution, sandboxes, scheduled runs, and sessions that keep a persistent filesystem and conversation history.

Data residency is a separate requirement. Managed Agents can run sessions in self-hosted sandboxes on infrastructure you control, which the docs position for compliance and data-residency needs. That governs where the sandbox runs. These sources don't say where model inference itself runs, so don't read self-hosting as a guarantee about inference location.

Sources2

3.Isolation, network and credential requirements

When the solution runs an agent that executes code, security requirements become concrete controls. The Agent SDK deployment guide lists them by resource: mount only the directories the agent needs, restrict the network to specific endpoints through a proxy, inject credentials through the proxy, and drop Linux capabilities. Isolation technologies differ in strength and cost. A sandbox runtime has very low overhead. gVisor and VMs give excellent isolation when set up correctly, but cost more in performance and complexity.

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

With --network none, the agent can reach the outside world only through the mounted proxy socket. That shapes the credential design: a proxy outside the container adds the credentials, so the agent never sees them and they are stored in one place. The same proxy can enforce an endpoint allowlist and log every request for audit.

Sources3

4.Hosting: where state lives and what to ask a sandbox provider

A self-hosted Agent SDK deployment also has to decide where state lives. By default, session transcripts go under ~/.claude/projects/, CLAUDE.md memory files sit at the user and project tiers, and artifacts land in the session's working directory. If the requirement is for users to resume conversations across requests, the SDK can resume a session ID from a SessionStore. That can be an object store, a key-value store or a database.

Sources4

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Because Managed Agents lets you delete sessions, it satisfies a Zero Data Retention requirement.Why is that wrong?

   Managed Agents stores session history, sandbox state and outputs on the server by design. It is not currently eligible for ZDR or HIPAA BAA coverage. Deleting data after the fact is not zero retention.

   Covered in Messages API or Managed Agents: state and data retention

2. 2.A sandbox proxy with a domain allowlist inspects encrypted traffic, so nothing can reach hosts outside the list.Why is that wrong?

   The sandbox runtime proxy checks the client-supplied hostname and does not decrypt traffic. Techniques like domain fronting can get around it. If your threat model needs stronger guarantees, you need a TLS-terminating proxy.

   Covered in Isolation, network and credential requirements