Claude reaches an enterprise through several distinct paths, and the vendors document them precisely.
Our observation is that the assurance posture differs across those paths more than the product does, and that the difference is set by decisions an assurance function rarely makes.
Three paths, three postures
Anthropic distinguishes the offerings directly. On Claude Platform on AWS, Anthropic operates the stack while AWS provides the authentication layer, IAM-based access control, and billing through AWS Marketplace; Anthropic is the data processor for inference inputs and outputs. On Claude in Amazon Bedrock, AWS operates the inference stack, the offering runs on AWS-managed infrastructure with zero operator access — Anthropic personnel have no access to the inference infrastructure — and data handling is governed by Amazon Bedrock. The first-party path is Anthropic end to end.
AWS’s own documentation for Claude Platform on AWS states that both Anthropic and AWS act as independent data processors, that the AWS Service Terms govern the offering, and that Anthropic’s Commercial Terms of Service, Data Processing Addendum, and Usage Policy also apply.
The instruments follow the operator. The Compliance API is available on Claude Platform on AWS, authorized through an AWS IAM action rather than a Compliance Access Key alone. On Claude in Amazon Bedrock it is not: the Compliance API sits on that offering’s list of unsupported endpoints. HIPAA readiness — permanent once enabled, and the subject of the companion’s sharpest finding — is not available on Claude Platform on AWS at all. Zero data retention is opt-in there and does not apply on Bedrock, where AWS is the processor.
Agent session transcripts deserve a precise statement. Local session capture applies while users are signed in with their Claude Enterprise account. On Claude Platform on AWS, Claude Code authenticates with AWS credentials or a workspace API key, and the documentation states that /login and /logout do not sign the user into a Claude.ai subscription on this path. Signing up provisions a new Anthropic organization tied to the AWS account, separate from any existing organization including a Claude Enterprise organization procured through AWS Marketplace, with no in-place conversion available. Reading those together, our conclusion is that agent session transcripts are not retrievable on that path — the Activity Feed and content endpoints ride on an organization with no Claude Enterprise sign-in to capture from. That is our reading of three pages joined, not a statement any one of them makes, and we mark it as such.
Same model, same vendor. Three postures, and the choice among them is ordinarily made on procurement, residency, and billing grounds.
Each vendor publishes its half, and publishes it well
The duty division is not something a reader has to infer. Both vendors set it out under their own headings, in named lists.
Anthropic’s Claude Code security documentation carries a section headed User responsibility: Claude Code only has the permissions you grant it, and you are responsible for reviewing proposed code and commands for safety before approval. For sessions routed to a self-hosted environment, isolation, network egress, and git credentials are the deployment’s responsibility. On the connector layer, Anthropic reviews connectors against its listing criteria before adding them to its directory, but does not security-audit or manage any MCP server. And the qualifier that closes the section: while these protections significantly reduce risk, no system is completely immune to all attacks.
AWS states its half as a two-column model. AWS owns secure infrastructure and microVM isolation at the hardware level, OS kernel patching, language runtime patching, managed runtime code including validation of the request structure the invocation API accepts, network infrastructure security, and service availability. The customer owns agent code security and dependency management, IAM access controls and resource policies, security of commands executed in runtime sessions, session-to-user mapping enforcement, input validation and prompt injection prevention, model configuration validation, skill and instruction sources, container image updates, and network configuration.
Two statements in that documentation are worth drawing out, because they say plainly what our earlier dispatches arrived at by reading where instruments bind.
The first concerns what a runtime will and will not judge: the harness validates the structure of the request it accepts, but it does not inspect the meaning of prompts, screen content, or enforce behavioral constraints on the agent. The second concerns the trace: correlation identifiers are propagated to downstream primitives to enable unified trace views, and they are used for observability only — never for authorization or data access decisions.
That is the anchor’s finding, stated as a design principle by a different vendor about a different product. Evidence and control are separate instruments. Neither vendor claims otherwise. Both write it down.
What the reviewed pages leave undescribed
Each account above is accurate about its own scope. Anthropic documents the duty that attaches to the model and the coding harness. AWS documents the duty that attaches to the runtime, the network, and the identity gate. Neither sets out the composite in the pages reviewed here, and neither is positioned to: on the paths where both parties are involved, each sees one side of a boundary the other operates.
The audit record makes the division concrete. On Claude Platform on AWS, every response carries two request identifiers — an AWS one indexed in CloudTrail, and an Anthropic one for use with Anthropic support. Workspace, compliance, vault, and webhook operations are logged as CloudTrail Management events by default, while inference, batch, file, skill, and managed-agent operations are Data events requiring explicit configuration and incurring additional charges. So the trail exists in two systems, with different default-on behavior, correlated by two identifiers that only the enterprise holds together.
Stated precisely: the composite duty for a given deployment path exists, and it is assembled from documents that are each correct about their own scope. No document among those reviewed here sets out the composite for a chosen path, and the structural reason is that neither party stands on both sides of it. The enterprise does.
What follows for a program
Three consequences, and none of them is a gap in a vendor’s product.
A coverage claim is path-scoped. “Our Claude usage is auditable” is not a statement about Claude. It is a statement about one path, one operator, one processor arrangement, and one set of instruments — and it changes when a workload moves to a different path for reasons of residency or billing. The companion made this point about credentials; it holds one level up, about platforms.
A platform choice is an assurance choice. Residency requirements point toward Bedrock, where AWS is the sole processor. That same choice removes the Compliance API from the picture. Feature velocity and the Compliance API point toward Claude Platform on AWS, and that choice removes HIPAA readiness. These are documented trade-offs rather than surprises, and they are decided at procurement, where the assurance consequence is not usually on the sheet.
The uncovered links are assigned, not purchased. The chain an assurance program answers for runs from intent through context, authorization, and execution to committed state. The instruments this series examined reach the asked-and-answered end of it: a session transcript evidences what was requested and what the model returned, and even there the system prompt and tool definitions are absent. Authorization scope is evidenced from configuration the enterprise holds — managed policy settings, hook definitions, connector configuration — which the transcript does not carry. Execution and committed state are evidenced from the systems the agent wrote to, which no vendor instrument reaches. Those links close by being owned.
The hard claim
The same model from the same vendor carries three different assurance postures, and none of the differences is a property of the agent. Each is a consequence of a procurement decision: who operates the stack, who processes the data, whose audit system holds the record.
Every vendor documents its own half of the resulting duty, accurately and in the open. Across the pages reviewed here, none describes the composite for a chosen path — which follows from position rather than from omission, since neither party sees both halves. Assurance is therefore not something an enterprise buys with a platform. It is what remains once both vendors have documented their halves — and the enterprise is the only party that can assemble it.
Which is the reason this series read documentation rather than tested products. The instruments are good, the disclosures are candid, and the duty they leave behind is legible to anyone who reads both sides. What an enterprise owes its customers, its board, and its auditors is not the instruments. It is the assembly.
Every vendor documents its own half of the duty, accurately and in the open. Across the pages reviewed here, none describes the composite for a chosen path — which follows from position rather than omission, since neither party sees both halves.
Assurance is not something an enterprise buys with a platform. It is what remains once both vendors have documented their halves, and the enterprise is the only party that can assemble it.
