In previous posts I've said how Claude Compliance API telemetry has limits. You can see user's prompts and Claude's reply, but not which tools Claude called, what an MCP server handed back, or which files it read off their laptop. In this post I show how to close that gap and get more Claude coverage using OpenTelemetry. This is the third post in this Claude Enterprise monitoring series. I'd recommend reading the posts before if you haven't already: Auditing Claude Enterprise: Shipping the Compliance API into Your SIEM In this post I show how to use Anthropic’s Compliance API to stream Claude Enterprise audit events into your SIEM, and introduce claude-compliance-sdk, a Python SDK I built to make interacting with the API easier. Why bother? You don’t need me to tell you that AI PaperMtn PaperMtn Part 1: How to ingest Claude Compliance logs into your SIEM Detecting Misuse with the Claude Compliance API: The Threat Is in the Content Detections for Claude Enterprise built on Compliance API content: a prefilter and LLM judge that catch prompt injection, jailbreaks and data exfiltration. PaperMtn PaperMtn Part 2: Writing detections using the Compliance logs and introducing a prefilter -> LLM judge pipeline for scanning chat content Why bother? If you've been playing along at home, you'll now have Claude Compliance API logs flowing into your SIEM, mapped to your data models and picked up by your existing detections, with a prefilter -> LLM judge pipeline assessing message content and flagging potential violations. These are detections are valuable and catch real threats, but there is still a blind spot. They only reason over what was said. The true "agentic" attacks are about what was done , and the doing happens in the gaps the Compliance API cannot see. The execution layer is where the worst things happen. A poisoned MCP response tricks Claude into a sensitive action. The conversation feed records jon.snow 's innocuous prompt and Claude's reply; the instruction that actually drove the action arrived in the MCP server's return, which the Compliance API never captures. Claude reads a file outside the project scope on jon.snow 's machine, a directory it had no business touching. There is no conversation artefact for this at all. A file was read, and the only place that fact exists is the execution layer. A tool action jon.snow rejected, followed moments later by a near-identical one that was auto-approved. Approval decisions live nowhere in the conversation; from the content feed, both the rejection and the approval are invisible. The conversation tells you what was said and the execution layer tells you what was done. A detection for an agentic platform needs both. Reviewing the coverage matrix AI moves quickly, and since I mapped Claude Enterprise coverage in the first post, the landscape has already shifted. Here is the most up-to-date version: Layer Claude.ai Chat Claude API Claude Code Cowork Files Cowork Chrome Cowork MCP Cowork Tasks Audit log export ✅ 🟡 🟡 ❌ ❌ ❌ ❌ Compliance API · events ✅ 🟡 🟡 ❌ ❌ ❌ ❌ Compliance API · content ✅ 🟡 ❌ ❌ ❌ ❌ ❌ OpenTelemetry · Code ❌ ❌ ✅ ❌ ❌ ❌ ❌ OpenTelemetry · Cowork ❌ ❌ ❌ ✅ 🟡 ✅ 🟡 On-device proxy / LLM gateway 🟡 🟡 ✅ ❌ ✅ 🟡 🟡 About OTel : OpenTelemetry (OTel) is an open-source, vendor-neutral standard for emitting telemetry from software, logs, metrics and traces, in a common format (OTLP) that you ship to a collector or to a SIEM that speaks it. It's not Claude-specific. What is new is that Claude's surfaces now emit their execution-layer activity over it, so tool calls, calls out to MCP servers (Model Context Protocol, the open standard Claude uses to reach external tools and data) and file access all arrive as ordinary log events. Two shapes show up in this post: event-style logs from Cowork and Claude Code, and traces (span trees) from the Office agents. OpenTelemetry for Cowork wasn't available when I wrote Part 1. It's now native and admin-configurable (Claude Desktop 1.1.4173 and later), set in Org settings under Cowork with an OTLP endpoint, protocol and headers. OpenTelemetry for Claude Code was available, but you had to rely on users setting their own environment variables. These variables are now enforceable: pushed through managed-settings.json by your MDM, where the values cannot be overridden locally. Additionally, there are the Office agents (Excel, Word, PowerPoint and Outlook), which now emit trace-based telemetry to a per-organisation collector. Cowork activity is still not in the Compliance API; OTel is the only centralised record of it. The two sources complement each other, and they share a user account identifier that lets you join them. Full coverage relies on you ingesting both sources . Cowork: telemetry by flipping a switch An admin can now turn on OTel logging for Cowork organisation-wide, under Organization settings > Cowork. You'll need to enter the OTLP endpoint, protocol and headers. Once those are populated, logs start flowing straight away in any ...