An audit log is the tamper-resistant record of who did what, when, in your systems. For Claude usage, it is the backbone of every downstream conversation — security investigations, cost attribution, compliance evidence, and the occasional "did anyone actually use this feature?" A useful property of the third-party platforms is that model invocation is a cloud API call like any other, which means it can flow into the same audit machinery your organization already runs.
The questions your record must answer
Design backwards from the questions. Who (which identity) invoked the model? From which application and environment? When, how often, and against which model IDs? How many tokens went in and out — the quantity you are billed for? And were there denied attempts, which are often more interesting than successful ones? If your logging can answer these for any week in the past year, you are in good shape. Notice what is not on the list: the content of prompts and responses. That separation is deliberate, and it is the most important design decision in this article.
Where the logs come from on each platform
On Amazon Bedrock, API activity can be captured through CloudTrail, AWS's account-wide audit trail, and folded into whatever analysis and retention pipeline your security team already runs on it. On Google Vertex AI, the equivalent surface is Cloud Audit Logs, with the same benefit: model calls appear alongside the rest of your GCP activity under existing retention and access rules. On Microsoft Foundry, Azure's resource logging and activity records play the same role for the Foundry resource. On Claude Platform on AWS, requests are SigV4-signed AWS-style calls associated with your workspace; because the service is Anthropic-operated, confirm with current documentation exactly which logging surfaces are available and how they connect to your AWS-side tooling rather than assuming parity with Bedrock's.
In every case the practical checklist is the same: confirm audit logging is enabled for the account or project where Claude runs (do not assume defaults), route the logs to your central location, set retention to match your compliance requirements, and restrict who can read or delete them.
Control plane vs. content: two different logs
Cloud audit trails are built to record that a call happened and by whom — metadata — not the full text of what was said. Content logging (prompts and responses) is a separate decision with real privacy weight: those texts may contain customer data, and a log of them is a second copy of sensitive information with its own access-control and retention obligations. Some teams need content logs for quality review or dispute resolution; others deliberately avoid keeping them. Either answer can be right. What is wrong is not deciding — content ending up in debug logs by accident is the common failure. If you do need content logging, the cleanest home for it is an internal gateway that all Claude traffic passes through, where you can log consistently, redact deliberately, and attach the request to a team and use case.
Making the record answerable
A pile of log lines is not an answerable record. Two practices convert one into the other. First, per-workload identities: if every application calls Claude with its own role or service account, the "who" column in the log is meaningful by construction; with shared credentials, no amount of log analysis recovers it. Second, a handful of standing queries or dashboards built before anyone asks: usage by identity per week, token volume by model, denied-call attempts, and calls from unexpected identities. Reviewing them monthly takes minutes and turns your audit log from an insurance policy into an early-warning system.
Where to go next
Meaningful logs depend on scoped identities — read Least-Privilege Access for Claude if you haven't. For the operational metrics side (latency, errors, quality signals) as opposed to the audit side, continue with Observability for Claude Apps, or review the launch checklist.