Regulated-Data Deployment Constraints: Privilege, HIPAA, GDPR, and FedRAMP
AdvancedConstruct Claude agents with the Agent SDK, custom loops, and hooks · Difficulty 3/5
Explanation
Why This Belongs in Agent Construction, Not Just Security
When the data an agent will touch carries a regulatory or contractual string attached -- attorney-client privilege, HIPAA, GDPR, FedRAMP, or a company's own residency policy -- that string settles the endpoint, the credential type, and the destination for logs *ahead of* any prompt, tool, or memory decision you'd otherwise make first. You rarely get to pick the delivery surface itself as the developer, but you are the one writing the code that points at a given endpoint, attaches the credential, sets the region, and ships the logs somewhere -- and unpicking a wrong choice there after the agent is already wired costs far more than getting it right on the first pass.
The Four Constraints and What Survives Review
| Constraint | What it tends to rule out | What usually survives review |
|---|---|---|
| Attorney-client privilege | A consumer Claude.ai session the firm has no end-to-end audit trail for, no matter how carefully the prompt itself is written | Calls made from a first-party application the firm controls, with SSO for user identity and traffic routed through a gateway the firm has vetted, logging both requests and responses. By default, Anthropic does not retain a copy of prompts/responses/tool-call content for direct API traffic, so if the firm needs that record for compliance purposes, the application itself has to write it to an approved log store |
| HIPAA (PHI) | Routing PHI to any endpoint, or writing it to any log/retention path, that a signed Business Associate Agreement doesn't specifically cover | A configuration named in an active BAA: either a HIPAA-enabled org on Anthropic's own API, or PHI routed through the partner's existing HIPAA-eligible AWS Bedrock or GCP Vertex account. Console, Workbench, beta features, and consumer plans fall outside BAA coverage -- check the current eligibility list before building on any of them |
| GDPR / EU data residency | A code path where the processing region isn't fixed, or that could get served from a jurisdiction outside the one the customer approved | Bedrock or Vertex with the region locked in the client config. Anthropic's own direct API has no EU residency option today, so a customer with an EU-only requirement needs to go through one of those two cloud routes instead |
| FedRAMP / government | Anything running outside a cloud environment authorized for the impact level required -- including a dev/test setup that quietly points at the commercial endpoint while production points at the authorized one | Exactly three routes clear this bar today: Claude for Government (C4G, FedRAMP High through Palantir's federal cloud service), Claude on Amazon Bedrock GovCloud (FedRAMP High plus DoD IL4/5), and Claude on Vertex AI Assured Workloads. Claude Enterprise on AWS Marketplace does not carry FedRAMP authorization -- a favorite exam distractor |
The Governing Principle
In every one of these four rows, the constraint is a hard gate, not a soft preference weighed against convenience: it rules out entire delivery routes regardless of how well-designed the prompt, tools, or memory architecture are on top of them. Get the constraint named at the start of the build, before any design choice about the agent's loop, tools, or wiring path.
Common exam traps
- Assuming a signed BAA blankets an entire Anthropic account. It doesn't -- Console, Workbench, beta features, and consumer plans all sit outside it; coverage is scoped to the specific configuration named in the agreement.
- Assuming the direct Anthropic API offers EU data residency out of the box. It doesn't -- a GDPR-driven residency requirement needs a Bedrock or Vertex route instead, with the region locked in explicitly.
- Picking "Claude Enterprise on AWS Marketplace" as a FedRAMP-authorized route. It is explicitly NOT FedRAMP authorized; the three authorized routes are C4G, Bedrock GovCloud, and Vertex AI Assured Workloads.
- Assuming Anthropic captures full conversation logs for compliance by default on direct API traffic. It does not -- the calling organization must implement its own application-layer logging if that's a requirement.
Key Takeaways
- A regulated-data constraint (privilege, HIPAA, GDPR, FedRAMP, internal residency policy) decides the endpoint, credentials, and log destination before any prompt/tool/memory design choice is made
- Attorney-client privilege rules out consumer Claude.ai surfaces; it requires direct API/SDK access via SSO through a firm-approved gateway, with the firm implementing its own app-layer logging since Anthropic doesn't capture compliance conversation content by default
- HIPAA requires a BAA-covered configuration -- a dedicated HIPAA-enabled org on the direct API, or a cloud-mediated route via Bedrock/Vertex on an existing HIPAA-eligible account -- and a BAA never covers Console, Workbench, beta features, or consumer plans
- The direct Anthropic API doesn't offer EU data residency today -- a GDPR-driven requirement needs Bedrock or Vertex instead, with the region explicitly locked in the client config
- FedRAMP has exactly three authorized routes (C4G, Bedrock GovCloud, Vertex AI Assured Workloads); Claude Enterprise on AWS Marketplace is explicitly NOT FedRAMP authorized -- a classic exam-trap distractor
Glossary Terms
The US Health Insurance Portability and Accountability Act, governing the protection of protected health information (PHI). Design implications include using HIPAA-eligible services and business associate agreements, and restricting or redacting PHI across the pipeline rather than assuming the model alone is compliant. Compliance is a property of the whole system -- data handling, access, retention, and contracts -- not of the model in isolation.
The EU General Data Protection Regulation, governing the protection of personal data for EU data subjects. Design implications include data minimization, establishing a lawful basis for processing, honoring data-subject rights, and respecting data-residency requirements.
The Federal Risk and Authorization Management Program, a US government standard for security assessment and authorization of cloud services used by federal agencies. Design implication: use authorized cloud environments and controls appropriate to the workload's authorization level for any Claude deployment serving government workloads.
The availability of Claude models through Amazon Bedrock and Google Vertex AI in addition to Anthropic's direct API, with a largely consistent message format across all three. Differences are limited to authentication, endpoint/region, and model-ID naming -- not model behavior. Vendor choice is driven by existing cloud footprint, data-residency requirements, and procurement constraints.
The choice of where an agent's loop and tools run: Anthropic-hosted/managed (Anthropic runs the infrastructure, lowering operational burden but reducing environment control) versus self-hosted/in-process (the developer runs the loop and tools in their own environment, maximizing control over data flow, networking, and least privilege at the cost of operating it themselves). Neither option is universally correct -- the decision trades operational burden against control over data residency and least privilege.
Related Concepts
Three Ways to Build the Loop: Agent SDK, Custom Loop, and Managed Agents
There are three wiring paths for an agent loop: a custom loop over the Messages API (full control, full responsibility), the Claude Agent SDK (managed loop running in your own process), and Claude Managed Agents (Anthropic runs the loop and the sandbox server-side, public beta)
Hooks as Deterministic Guardrails
Hooks (PreToolUse, PostToolUse) are code callbacks at fixed points in the agent loop and behave deterministically