The log is in the other system

Claude Team does not have one Enterprise-style audit and compliance feed across every product surface. That is different from saying there is no evidence.

The Team plan gives Owners and Primary Owners usage analytics, and the Primary Owner can run an organization data export that includes conversation data. Team also supports rich OpenTelemetry monitoring for Cowork, while Claude Code has its own OpenTelemetry event stream when it is configured.

What Team does not have is the Enterprise audit log, Compliance API or inference hooks.

The investigation problem is therefore not "there are no records." It is "the records live in several places."

There is no one log

Cowork OpenTelemetry is the important change in this picture. On Team and Enterprise, an organization can configure an OpenTelemetry collector for Cowork, and the current event stream can include the full user prompt and every tool or MCP invocation, including server and tool names, parameters, success or failure, execution timing and human approval decisions. That is much closer to an invocation record than a usage dashboard.

It is also sensitive evidence. If you enable it, treat the collector as part of the security architecture. Decide where those prompts and tool parameters are stored, who can read them and how long you retain them.

Claude Code has a separate OpenTelemetry implementation. Its event stream includes prompt events, tool decisions, tool results and MCP activity. Prompt content is redacted by default, and detailed tool arguments and tool content require explicit opt-in settings. That distinction should remain visible in the operating documentation because "we enabled telemetry" does not tell you which content the collector actually receives.

The organization data export serves another purpose. It is available to the Primary Owner on Team and Enterprise and includes conversation data. It is a bulk export created after the fact, not a live audit stream.

Those three records answer different questions.

The system of record still matters

Telemetry can tell you that a tool call was attempted and whether Claude reported success. The connected system tells you what actually landed there.

Google Workspace Drive logs supported third-party API access as application activity and can expose the actor plus the third-party OAuth client ID and application name. Google also documents filtering report activity by OAuth client ID.

GitHub audit events expose application-attribution fields such as oauth_application_id on many supported actions.

Microsoft 365 has its own audit trail across workloads through Purview and related Microsoft audit APIs. The exact application attribution available depends on the workload and event, so do not write a blanket promise that every Microsoft action can always be filtered on one Claude application ID.

Slack is weaker as a universal source. Workspace access logs can show actions performed through an app or bot on a member’s behalf, but Slack explicitly warns that not all third-party app actions appear there. Enterprise Grid provides richer audit capabilities, but that still does not turn Slack into a complete transcript of every connector invocation.

The operating rule is therefore simple. Know which connected systems provide complete evidence for the action you care about, which provide partial evidence, and which require Claude-side telemetry to complete the picture.

Filter on the client where the source supports it

Searching only for the employee is often the slow way to investigate connector activity. Where the source platform exposes the calling application, search or filter on that application as well.

Google Workspace is the clearest example. Drive log events can include the OAuth client ID and application name for third-party API access, and the Reports API supports filtering on OAuth client ID. GitHub exposes OAuth application attribution on many audited events. Other systems vary by workload.

Do not promise one universal query across every SaaS platform. The technique is actor, application, time window and affected resource together, which is usually more useful than starting with the person’s name alone.

Build the evidence map before the incident

Attempt, effect, identity and conversation are separate evidence questions. Map each one before an incident, and record where each answer lives:

• Cowork OpenTelemetry. What did Cowork ask, and which tool or MCP call did it make? Your OTel collector.
• Source-system logs. What action actually landed, as whom, and on which resource? Google Admin, Microsoft Purview, GitHub, Slack and the application itself.
• Identity provider. Who authenticated to Claude, and under what identity and access conditions? Okta, Entra, Google or the configured IdP.
• Organization data export. What conversation content exists in the Team organization? The Primary Owner.

Claude Code OpenTelemetry is a fifth specialist record, for developer activity.

Usage analytics is another useful signal, but not an event ledger. Team Owners and Primary Owners can see adoption and spend information, connector read and write action counts and product usage, and the spend report can be exported per user and per model. That is valuable for finding anomalies and choosing where to investigate. It is not a substitute for event telemetry.

Enterprise changes the evidence layer

Enterprise adds the audit and compliance controls Team lacks.

The Enterprise audit log records administrative and organization events, and the export currently covers up to 180 days. Chat and project content is not carried in those audit records themselves.

The Compliance API goes further. It can provide activity events and content across supported Claude deployments, including session transcript content for Cowork and Claude Code with prompts, responses and tool-call content where documented.

Inference hooks add a different control again. They can inspect and enforce policy on prompts, tool-call responses and uploaded file text before that material reaches Claude.

Those are materially different capabilities from reconstructing an incident afterward.

Even with Enterprise, the connected system remains important. The system of record tells you whether the intended external effect actually occurred.

One page, written in advance

The useful incident document is short. For each evidence source, record:

• What question it answers
• Where it lives
• Who can retrieve it
• Whether it is enabled
• What content is included or redacted
• Retention
• Export procedure
• The Primary Owner
• The Cowork OpenTelemetry destination
• The Claude Code OpenTelemetry destination, if used
• How connector access is revoked
• How a Claude member is removed
• The internal person who owns the incident procedure
• How an Owner escalates to Anthropic support if needed

Write the evidence map before there is an incident. A questionnaire answer that says "Team has no Enterprise audit log, so we use these documented compensating records" is very different from discovering the limitation while the reviewer is waiting.

The honest version

This is not the same as having one Enterprise compliance plane across Claude.

For a company whose customers require centralized AI audit evidence, regulated retention or programmatic compliance ingestion, that difference can justify Enterprise.

For other organizations, Team can still produce a strong incident picture if the telemetry is configured before it is needed and the source-system evidence map is documented.

The record is not in one place. That is precisely why you need to know where each part lives.

Product note. Product features change frequently, so always check current features and documentation before acting on this note. It reflects behavior as reviewed in September 2026 and is a starting point rather than a configuration reference.

Explore this expertise: AI Platform Governance

All technical notes