Claude Audit Logging: How to Track and Monitor AI Usage Across Your Organisation

Claude audit logging is not optional for enterprise deployments. SOC 2 auditors will ask for it. GDPR enforcement requires it. Your incident response team will need it when something goes wrong — and in a production AI deployment, something eventually goes wrong. The question is whether you have the evidence to investigate, remediate, and prove compliance.

This guide covers what to log, how to structure audit records for Claude API interactions, retention and access control requirements, monitoring patterns for detecting misuse or anomalous behaviour, and the specific considerations for regulated industries. This applies whether you're running Claude through the direct API, Claude Enterprise, or via AWS Bedrock or Google Cloud Vertex AI.

What to Log: The Minimum Viable Audit Record

Claude audit logging is not the same as general application logging. Application logs track errors and performance. Audit logs track who did what, when, with what inputs, and what the system produced. The distinction matters because audit logs are immutable evidence — they need different storage, access controls, and retention policies from operational logs.

For Claude API interactions, the minimum viable audit record must capture enough information to reconstruct the interaction for compliance purposes, without creating unnecessary privacy exposure by logging raw user content where it's not required. Strike this balance deliberately — over-logging creates privacy risk, under-logging creates compliance risk.

Field	Type	Description	Required
event_id	UUID	Unique identifier for this interaction	✓
timestamp	ISO 8601	UTC timestamp of request initiation	✓
user_id	String	Authenticated user identifier (from your IdP)	✓
session_id	String	Session or conversation thread identifier	✓
application_id	String	Which Claude application or workflow	✓
model	String	Model used (claude-opus-4-6, claude-sonnet-4-6, etc.)	✓
prompt_hash	SHA-256	Hash of full prompt (enables comparison, not content storage)	✓
prompt_tokens	Integer	Input token count	✓
completion_tokens	Integer	Output token count	✓
response_hash	SHA-256	Hash of Claude's response	✓
latency_ms	Integer	End-to-end latency in milliseconds	✓
data_classification	Enum	Highest data class in the prompt (PUBLIC/INTERNAL/CONFIDENTIAL/RESTRICTED)	✓
prompt_raw	Text	Full prompt text — store in encrypted, access-controlled store	Conditional
response_raw	Text	Full response text — store in encrypted, access-controlled store	Conditional
policy_flags	Array	Any policy violations or alerts triggered	Recommended
ip_address	String	User's IP (masked if GDPR applies)	Conditional

Note the distinction between the hash fields and the raw content fields. The hash lets you verify and deduplicate events without exposing the full content to everyone with access to audit logs. The raw content — when you do need to store it — goes in a separate, more restricted store with separate access controls and encryption keys.

Logging Architecture: Patterns That Scale

Your Claude audit logging architecture needs to satisfy three properties: completeness (no interactions escape logging), immutability (logs can't be altered after the fact), and accessibility (authorised reviewers can retrieve specific records efficiently). These properties pull in different directions — build for all three from the start rather than retrofitting.

The Middleware Pattern

The most reliable architecture for Claude audit logging is a logging middleware layer that wraps every API call. This middleware intercepts requests before they reach Claude, generates the audit record, forwards the request, captures the response, updates the audit record, and emits it to your logging infrastructure. Nothing reaches Claude without being logged. Nothing leaves Claude without being recorded.

import hashlib
import uuid
import time
from datetime import datetime, timezone
from anthropic import Anthropic

class ClaudeAuditLogger:
    def __init__(self, client: Anthropic, audit_store, application_id: str):
        self.client = client
        self.audit_store = audit_store
        self.application_id = application_id

    def create_message(self, user_id: str, session_id: str, messages: list,
                       model: str, system: str = None, **kwargs):
        event_id = str(uuid.uuid4())
        start_time = time.time()

        # Build prompt for hashing
        full_prompt = system or "" + str(messages)
        prompt_hash = hashlib.sha256(full_prompt.encode()).hexdigest()

        # Classify data (simplified — use your DLP classifier here)
        data_class = self._classify_data(full_prompt)

        audit_record = {
            "event_id": event_id,
            "timestamp": datetime.now(timezone.utc).isoformat(),
            "user_id": user_id,
            "session_id": session_id,
            "application_id": self.application_id,
            "model": model,
            "prompt_hash": prompt_hash,
            "data_classification": data_class,
            "status": "initiated"
        }

        try:
            # Make the actual API call
            api_kwargs = {"model": model, "messages": messages, **kwargs}
            if system:
                api_kwargs["system"] = system

            response = self.client.messages.create(**api_kwargs)

            # Update audit record with response data
            response_text = response.content[0].text
            audit_record.update({
                "prompt_tokens": response.usage.input_tokens,
                "completion_tokens": response.usage.output_tokens,
                "response_hash": hashlib.sha256(response_text.encode()).hexdigest(),
                "latency_ms": int((time.time() - start_time) * 1000),
                "status": "success",
                "stop_reason": response.stop_reason
            })

            # Emit to audit store
            self.audit_store.write(audit_record)
            return response

        except Exception as e:
            audit_record.update({
                "status": "error",
                "error_type": type(e).__name__,
                "latency_ms": int((time.time() - start_time) * 1000)
            })
            self.audit_store.write(audit_record)
            raise

    def _classify_data(self, text: str) -> str:
        # Hook your DLP classifier here
        # This is a placeholder that always returns INTERNAL
        return "INTERNAL"

Immutable Log Storage

Audit logs must be tamper-evident. Cloud storage with write-once policies (AWS S3 Object Lock, Azure Immutable Blob Storage, GCS Bucket Lock) prevents modification after write. For highest-assurance environments, use append-only databases with cryptographic chaining — each record includes a hash of the previous record, making undetected modification of the chain computationally infeasible.

Structured Logging for Query Efficiency

Regulatory audits and incident investigations start with specific questions: "Show me all Claude interactions by user X between dates Y and Z." Structure your audit records to answer these queries efficiently. Partition your log store by date. Index on user_id, session_id, and application_id. Keep the metadata (all fields except raw prompt and response) in a fast query layer — and keep the raw content separately, retrievable by event_id for authorised reviewers only.

Retention Policies by Industry and Regulation

How long you must retain Claude audit records depends on the regulatory frameworks that apply to your organisation and the nature of the interactions logged. Getting this wrong creates compliance exposure in both directions — too short a retention period and you can't satisfy audit requests, too long and you're holding data beyond its legitimate purpose under GDPR.

Financial services firms subject to FCA or SEC oversight generally need to retain records of communications and decision-making processes for 5-7 years. If Claude is assisting with advice, research, or trading decisions, those records fall within this requirement. UK MiFID II rules require 5 years for investment communications. US SEC Rule 17a-4 requires 6 years for broker-dealers. Get legal sign-off on which of your Claude use cases generate records subject to these rules.

Under GDPR and UK GDPR, the principle of storage limitation requires you to keep personal data only for as long as necessary for the specified purpose. This creates tension with audit retention requirements — you may be obligated both to retain audit records and to delete personal data on request. The resolution is data minimisation in your logs: don't log personal data you don't need, pseudonymise what you do log, and build a process for handling subject access requests against your audit store.

Healthcare organisations handling patient data under HIPAA have a 6-year retention requirement for records of policies and procedures and documentation of their implementation. If Claude interactions relate to patient care, treatment decisions, or protected health information, those records likely require HIPAA-compliant storage and retention. See our full guide on Claude HIPAA compliance for the specific controls required.

Real-Time Monitoring and Anomaly Detection

Audit logging is retrospective — it captures what happened. Real-time monitoring is proactive — it alerts when something is happening that warrants attention. For enterprise Claude deployments, you need both. The monitoring layer sits between your audit log stream and your incident response team.

Usage Volume Alerts

Set baseline usage patterns by user, department, and application. Alert when usage deviates significantly — a user who normally sends 50 Claude interactions per day suddenly sending 5,000 is worth investigating, whether it's a credential compromise, an automated script, or someone who found an unintended API access point. Usage-based alerting also catches cost anomalies before they become significant billing events.

Data Classification Alerts

If your DLP classifier identifies RESTRICTED data classification in a Claude prompt, that should generate an immediate alert. Employees sending customer PII, trade secrets, or patient health information to Claude outside approved data handling procedures needs real-time detection, not a quarterly audit review. Route these alerts to your data governance team, not just IT ops.

Prompt Pattern Detection

Prompt injection attempts — where someone tries to override your system prompt or Claude's behaviour through crafted user input — leave detectable patterns. Common patterns include "ignore previous instructions", system prompt disclosure requests, role-playing instructions designed to bypass safety controls, and abnormally long inputs designed to overflow context windows. These should trigger alerts and, in high-risk applications, automatic conversation termination.

Monitoring Dashboards

Build operational dashboards that surface the metrics your AI governance team needs to monitor on an ongoing basis: total interactions by application and user cohort, token consumption trends, error rates and types, data classification distribution, and alert frequency by type. Dashboards make governance visible — which is what boards and audit committees need to see that oversight is actually happening.

Access Controls for Audit Data

The audit log of your Claude deployment contains sensitive information — user behaviour patterns, potentially confidential business content, and data that could be used to reconstruct intellectual property. Access to audit logs must be controlled as carefully as the underlying business data.

Implement role-based access control for audit data. Security operations teams need access to metadata and alert data for incident investigation. Compliance and legal teams need access to full records when preparing for audits or responding to regulatory inquiries. Individual managers should not have access to their direct reports' Claude interaction logs — this creates privacy and labour relations issues. General employees should not be able to view other employees' interactions. Design these controls before you go to production and document them for your SOC 2 auditor.

For access to raw prompt and response content — the most sensitive part of your audit store — require break-glass procedures: a formal request, approval from a second person, and automatic notification to the subject where required by law. Every access to raw content should itself be logged. This is the audit log of your audit log — and for high-assurance environments, it's not optional.

Claude Enterprise and Admin Console Logging

Claude Enterprise includes an admin console that provides usage analytics, user management, and some visibility into how Claude is being used across your organisation. This is a starting point, not a complete audit solution. The admin console shows aggregate usage data, top users by volume, and some conversation metadata — but it's not designed to satisfy SOC 2 audit requirements or regulatory investigation requests.

Claude Enterprise's admin controls let you set usage limits, manage user access, and view usage reports. For compliance purposes, you still need your own logging infrastructure in parallel — capturing the full interaction record with the granularity and immutability that regulatory frameworks require. Think of the admin console as an operational tool and your logging infrastructure as the compliance record.

If you're running Claude through Claude Enterprise and building custom applications on the API, the logging middleware approach described above applies to your API calls. For direct Cowork or Claude.ai usage by employees, you'll rely more heavily on the admin console data and need to assess whether that satisfies your specific compliance requirements. Our Claude Enterprise implementation service includes a logging and monitoring architecture designed for your regulatory context.