Enterprise teams enable request logging for good reasons: debugging, abuse investigation, quality review. But a prompt sent to Claude often contains the most sensitive text in your business — customer messages, contract clauses, medical notes. The moment a platform's logging feature captures request bodies, that content flows into a cloud-managed log store, and your data-governance obligations follow it there. The three cloud-operated platforms differ sharply in what their logging systems actually record, so this inventory sticks to what each vendor documents.
Amazon Bedrock: full bodies, on one surface only
Bedrock's model invocation logging — disabled by default — collects invocation records including model input and output data. Each log entry embeds the request and response JSON bodies up to 100 KB; larger bodies and binary data (such as images) are written as separate S3 objects with a reference in the entry. Entries also capture the calling IAM principal (identity.arn) automatically, and destinations are CloudWatch Logs, S3, or both, in the same account and Region. Once enabled, logs are stored until you delete the logging configuration — there is no automatic expiry.
The critical scoping detail: AWS documents that invocation logging "is only supported for calls made through the bedrock-runtime endpoint" — the legacy InvokeModel/Converse surface. Calls through the current bedrock-mantle endpoint (the Anthropic Messages API surface for "Claude in Amazon Bedrock") are not captured. So on the current surface, prompt content does not land in invocation logs at all; conversely, don't assume you have an audit record there either. On bedrock-mantle, inference calls appear in CloudTrail only as optionally enabled data events, which record parameters like model and max_tokens — not prompt bodies — though AWS warns that any caller-supplied metadata on those calls "is logged verbatim in CloudTrail," so keep secrets and personal data out of metadata fields.
Where invocation logging is in use, AWS suggests CloudWatch Logs data-protection (masking) policies for sensitive content — a control worth pairing with the logs from day one.
Google Vertex AI: full payloads into your BigQuery dataset
Vertex's request-response logging (a Preview feature) logs samples of requests and responses for supported partner models — Anthropic Claude is listed, for rawPredict / streamRawPredict calls — into a BigQuery table you own. The schema includes request_payload and response_payload string columns plus full_request/full_response JSON: genuine prompt and completion content, not summaries. Pairs larger than BigQuery's 10 MB row limit are simply not recorded.
Two configuration quirks matter for Claude specifically: for Anthropic models only the REST API can configure logging, and it works only on regional endpoints — Google documents that the global and multi-regional endpoints don't support the feature. A samplingRate between 0 and 1 controls what fraction of requests is logged. Governance is entirely yours: retention is whatever you configure on your BigQuery dataset, and access is whatever your BigQuery IAM says. Separately, an opt-in mechanism can share request-response logs in a tamper-proof manner with Anthropic's trust-and-safety team for specific Advanced AI models — a distinct feature requiring consent to a safety addendum, covered in its own article.
Microsoft Foundry: no documented body capture
Foundry's diagnostic settings offer a RequestResponse log category described in Microsoft's documentation as "Logs for every inference request and response, including status codes and latency." Whether actual prompt or completion bodies are included is not documented — the page describes status codes and latency only, so you should not assume payload capture in Foundry diagnostic logs, in either direction: don't count on it for content review, and don't flag it as a content-exposure risk without verifying. The one documented path by which prompt content can enter Azure telemetry is agent tracing: Foundry's agent-framework tracer records gen_ai.input.messages/gen_ai.output.messages span content only when explicitly opted in via environment variables — content is not recorded by default.
| Platform | Prompt/completion bodies in logs? | Where they land |
|---|---|---|
| Bedrock (bedrock-runtime) | Yes, when invocation logging is enabled — full JSON up to 100 KB per entry, overflow to S3 | CloudWatch Logs and/or S3, your account |
| Bedrock (bedrock-mantle) | No — invocation logging does not capture this surface | CloudTrail data events (metadata only, opt-in) |
| Vertex AI | Yes, when request-response logging is enabled — full payloads, sampled, <10 MB per pair | Your BigQuery dataset |
| Foundry | Not documented — status codes and latency only per Microsoft's docs; trace content capture is opt-in | Log Analytics workspace |
Governance takeaways
Treat any log destination that can hold prompt bodies as a sensitive data store: scope access narrowly, set retention deliberately (Anthropic's platform pages recommend activity logging on at least a 30-day rolling basis for misuse investigation), and apply masking where the platform offers it. Note what enabling logging does not do — Anthropic's documentation states that turning on Bedrock logging "does not give AWS or Anthropic any access to your content," and its Foundry page carries an equivalent statement. The logs are yours, in your account, under your cloud provider's compliance posture — confirm specifics with your provider.
Where to go next
For setup mechanics, see Bedrock invocation logging setup and its log schema, the Vertex BigQuery log schema and Vertex logging config constraints, and Foundry diagnostic logs. The broader picture is in the audit logging overview.