Guides/Playbook

Claude adds API traces: Check missing security evidence

7 min read
On this page
A request timeline with recorded spans and an empty outline where evidence is missing

Check missing trace evidence

General Analysis

On October 14, 2026, Anthropic launched OpenTelemetry export in public beta for the Claude Platform. Messages API calls and Managed Agents sessions can now send traces to an observability backend, alongside spans from the Claude SDK. Security teams gain a way to follow execution across the client and service. They also need to establish which activity the trace leaves out.

A successful request can have no exported span. Anthropic documents best-effort delivery and caller-controlled sampling. Before relying on this feed, give investigators a way to distinguish missing evidence from no activity.

This guide proposes a coverage check for the new API export. It is a sourced implementation plan, not a report of a tested Claude deployment. For terminal and Agent SDK monitoring, use the separate Claude Code OpenTelemetry guide. The Compliance API guide covers retained enterprise records.

Establish a baseline outside the trace feed#

Consider a hypothetical application that reviews support tickets with the Messages API and can propose a follow-up through a client tool. Keep a request ledger in the application service, outside the agent's writable environment. Record an application attempt ID before sending; attach the response's request ID when available. Keep retries as separate attempts. Do not store the API secret or ticket text in this ledger.

Use that ledger to answer whether a known request has a corresponding server span. Preserve attempts that never received a request ID as a separate unresolved group. A timeout can prevent the client from learning the ID, so those attempts cannot be reconciled with the join below.

The span reference maps anthropic.request.id to the request-id response header. SDK request spans have kind CLIENT; API request spans have kind SERVER. The API service name is claude-platform. Match these fields together so an SDK span does not disguise a missing API span.

The following SQL uses application-defined staging tables. Normalize your backend export into received_spans, and load authenticated POST /v1/messages attempts with request IDs into request_ledger. Exclude other endpoints: the API does not emit this span for /v1/chat/completions. Both tables must cover the same organization, workspace, and closed time window. Wait for your documented ingestion allowance before running it.

Code source: illustrative reconciliation query; field mapping follows the OpenTelemetry span reference.

SQL
WITH server_requests AS ( SELECT DISTINCT request_id FROM received_spans WHERE service_name = 'claude-platform' AND span_name = 'anthropic.messages.create' AND span_kind = 'SERVER' AND request_id IS NOT NULL ) SELECT r.attempt_id, r.request_id FROM request_ledger AS r LEFT JOIN server_requests AS s ON s.request_id = r.request_id WHERE r.request_id IS NOT NULL AND s.request_id IS NULL;

Rows mean the selected export has no matching server span. They do not identify the cause. Investigate sampling, destination scope, delayed ingestion, and delivery failure before attributing the gap to tampering. An empty result only closes this request-level check; it says nothing about missing tool evidence or unrecorded requests outside the application.

Keep a second, independent usage check. The Usage API provides time-bucketed token data with API-key and workspace filters. Collect all pages for the same interval and compare like-for-like token categories. These aggregates can expose activity absent from your application ledger, but cannot identify its individual requests. Use a dedicated reporting identity; the application does not need the reporting credential.

For Claude Platform on AWS, the programmatic Usage and Cost API is currently unavailable. Use the Console's Usage and Cost pages for this comparison instead.

See how your AI systems hold up under real attacks

General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.

Connect both export paths#

An administrator configures API destinations in the Claude Console. For a custom destination, use an HTTPS OTLP/HTTP endpoint accepting protobuf on port 443, with credentials in headers. The base URL normally gets /v1/traces appended. Select the intended workspaces, send the destination test, and verify anthropic.test in the backend. Then send a harmless application request and reconcile its ID. API setup.

Treat the Console's Healthy state as the result of the last delivery. It is not the outcome of the reconciliation above. A redirect or a hostname resolving to a non-public address disables the destination; continuous delivery failure for 24 hours also disables it. Repair and re-enable it, then verify a new request. Preserve the earlier interval as a gap rather than assuming it was replayed. Delivery behavior.

Client tools require another path. Register the application's tracer provider before its first SDK call and route its exporter to the approved collector. For a Managed Agents self-hosted sandbox, configure tracing in the worker process and permit its collector traffic. Console export alone cannot supply those worker spans. Pin the SDK version while the tracing interface remains in beta. SDK setup.

Keep permission decisions separately#

The tool-span reference excludes several cases from API tool spans: application-run custom tools, tools executed in self-hosted sandboxes, Managed Agents multiagent and advisor tools, and uses denied by the auto permission policy or an application's user.tool_confirmation response.

This changes how to read a security dashboard. Zero denied tool spans cannot establish zero denied attempts. Preserve the application's approval decision with the session, tool-call identifier, policy revision, and decision time. Retain the relevant session events too. The Managed Agents tool-approval guide explains the permission workflow.

Use downstream service records to verify effects such as a sent message. A trace may help locate the operation; the destination system is where you check whether it happened. Apply the same separation when a tool is blocked: record the decision without requiring an execution span that the product does not emit.

Run a small acceptance matrix#

Use synthetic content and an isolated workspace. These are proposed checks, not results from General Analysis testing. Document the expected export scope before each case, and keep the observed result beside the application record.

Harmless fixtureAcceptance evidence
Send one Messages request with tracing enabledIts request ID matches a SERVER span; the SDK path has its own CLIENT span.
Send a request with the W3C sampled flag offThe ledger retains the request even though API spans are suppressed; the reconciliation exposes the expected gap.
Run one client tool that returns a fixed stringThe application export contains its tool span; the runbook identifies the client as the source.
Deny a dummy Managed Agents tool confirmationThe approval record and session evidence retain the denial without depending on an API tool span.
Deliver the same captured span twice to a test ingestion pipelineCounting deduplicates by trace ID and span ID; a repeated delivery does not become another operation.

The sampling and duplicate-delivery expectations follow API export behavior; tool expectations follow the span reference. Review who controls inbound trace headers in your application. Untrusted caller context should not silently choose the sampling policy for security-sensitive work.

Check the evidence content before expanding access#

Metadata-only export can still contain names and descriptions supplied by your application. Full-content export has a size limit and marks shortened content with anthropic.content.truncated. An investigator must be able to distinguish an omitted prompt from one that never existed. Organization data-handling restrictions that force API destinations to metadata do not apply to SDK spans. Review the two paths independently. Content modes and limits.

Use a dummy identifier in an agent or tool name to inspect metadata handling, and a synthetic long prompt to inspect truncation in an approved test destination. Check the stored record after collector processing. Record which fields survive, who can read them, and the destination's retention policy.

Assign the missing-request investigation and permission-evidence review before rollout. Document how to restore disabled destinations. If the application cannot explain a gap, leave that interval unresolved. Require evidence that the relevant controls worked before increasing agent permissions.

Frequently asked questions

  • Does a healthy Claude telemetry destination prove complete coverage?

    No. Healthy describes the last delivery. Reconcile known requests against received spans and check workspace scope, sampling, client export, and documented exclusions separately.

  • Where do denied Managed Agents tools appear in OpenTelemetry?

    The API does not emit a tool span when the auto permission policy denies the use or the application denies it through user.tool_confirmation. Preserve permission decisions and session evidence separately; an empty tool-span query does not prove that no tool was attempted.

Browse all