Skip to main content
Route complete audit telemetry from Claude for Excel, PowerPoint, Word, and Outlook to your own OpenTelemetry (OTEL) collector. This gives you control over retention and encryption and lets you feed the data into a SIEM or observability platform. This capability is available to Claude Enterprise organizations and to direct-provider deployments on Amazon Bedrock, Google Cloud Vertex AI, Azure AI Foundry, or an LLM gateway.

​
What the collector receives

When a custom collector is configured, the add-in sends trace data for every user turn. Each turn produces a tree of spans covering the prompt, each model call, each tool execution, file uploads, and context compaction. For the setups described under Set up the collector, all span attributes are included. They carry user-generated content: prompt text, tool inputs and outputs, and document URLs. The allowlist filter that strips sensitive attributes on the Anthropic path does not run on this path. One normalization still applies: MCP connector tool names are recorded as the literal mcp_tool rather than the connector-specific name. For these setups, assistant response text is not included. Your organization owns the collected data; treat the endpoint as containing prompt and document content when you scope access controls and retention. When the collector is instead delivered by an administrator-managed settings document, such as the one Claude for Government delivers, the add-in follows that document: it includes only the content categories the administrator selected, sends one log record per prompt, model call, and tool call to {your_url}/v1/logs, and sends the spans only while the administrator has turned traces on. One of those categories is Claude’s responses: when selected, the reply is recorded as response on each model call’s span and sent as its own log record, office_agent.assistant_response. Each turn’s spans and log records also name the signed-in member as user.email and user.account_uuid, and with a Claude for Government sign-in the organization as organization.id, except a model call Claude makes while running a tool, which is reported with the model and token counts only. The add-in sends these log records to such a collector: Auxiliary model calls the add-in makes for itself, such as context compaction (the agent.compaction span), the short progress headline shown while Claude works, and connection checks, yield no log record. Every record except office_agent.assistant_response carries event.name, duration_ms, and the attributes of the span it reports, as listed in the span reference, minus tool output and the reply text. office_agent.assistant_response carries event.name, the reply as response and response_chars, model, request_id, and the same surface, session, member, and organization attributes as its model call. Metrics are not sent to custom collectors. The office_agent.* counter namespace routes to Anthropic only. Every counter increment is also recorded as a span event on the active span, so the same signals are recoverable from the trace stream. Telemetry is sent over OTLP/HTTP to {your_url}/v1/traces, and the log records above to {your_url}/v1/logs. gRPC is not supported because of Office WebView constraints.

​
Endpoint requirements

The add-in exports telemetry from each user’s browser: the taskpane at https://pivot.claude.ai posts directly to your collector, so every export is a cross-origin request. The endpoint must:
  • Answer the OPTIONS preflight with Access-Control-Allow-Origin covering https://pivot.claude.ai and Access-Control-Allow-Headers covering Content-Type plus any headers you configure, such as Authorization.
  • Return the same Access-Control-Allow-Origin header on the POST response.
Managed OTLP ingest endpoints such as Grafana Cloud are built for server-to-server export and generally do not answer browser CORS preflights. Point the add-in at an OpenTelemetry Collector you run, configure the cors block on its OTLP HTTP receiver, and have that collector forward to your backend. The collector makes the authenticated call to your backend, so no credential needs to appear in export headers that reach every signed-in user’s browser.

​
Set up the collector

Configuration differs by how your users sign in.

​
Claude Enterprise organizations

An organization administrator sets the collector endpoint in the Claude admin console under Organization settings, Office agents. Two settings are available:

​
Direct-provider deployments

Deployments that authenticate against Bedrock, Vertex AI, Foundry, or a gateway supply the same two keys through the customer-configuration channels described in Use Claude for M365 with third-party platforms. The claude-for-msft-365-install setup plugin writes these for you. To set them by hand, use any of the three channels below. Later channels override earlier ones: manifest parameters are read first, then Entra claims, then the bootstrap response. Manifest URL parameter. Append the keys to the taskpane URL in your custom manifest, with otlp_headers after # so the credential stays out of server request logs.
Entra ID directory extension. Register the keys as directory extension attributes and assign them per user through Microsoft Graph. The add-in reads them from the user’s ID token via Nested App Authentication. extn.otlp_endpoint maps to otlp_endpoint and extn.otlp_headers maps to otlp_headers. Bootstrap endpoint response. Include the keys in the JSON body your bootstrap endpoint returns.

​
Attribute size cap

Prompt, reply, tool-input, and tool-output attributes are truncated in the add-in at 4,000 characters each by default and marked with a trailing …[truncated]. Set the otlp_attr_max_chars configuration key to a positive integer to change the cap. Values are clamped to between 256 and 32,000. Before raising the cap, confirm your collector and tracing backend accept attribute values of the configured size: many backends truncate or drop over-limit attributes at ingest, and a dropped span is lost from the audit trail entirely.

​
Deployment modes

The audit trail differs slightly depending on the sign-in path. Claude Enterprise (OAuth): full audit trail including user identity (user.email, user.account_uuid, organization.id), MCP server metadata, and file-upload spans. Direct provider (Bedrock, Vertex AI, Foundry, gateway): core audit trail with prompts, tool inputs and outputs, and document URLs. No Claude user identity, MCP metadata, or file-upload spans. Attribute activity to a user by correlating session.id against your identity provider or gateway logs.

​
Span reference

Each user turn produces up to five span types. agent.query is the root; agent.stream and agent.compaction are its children; agent.tool_execution is a child of agent.stream; file.upload arrives as a separate root span. The four agent.* spans each carry agent.surface (sheet, doc, slide, or mail), agent.vendor (m for Microsoft), and session.id, and with Claude sign-in user.email, user.account_uuid, and organization.id, so each can be filtered on its own. file.upload carries session.id and, with Claude sign-in, user.email; correlate it to a turn by session.id and timestamp, since it has its own trace ID. Attributes marked content carry user-generated data. Attributes marked Claude sign-in only are populated only when users sign in with a Claude account. Attributes marked managed settings document only are sent only to a collector delivered by an administrator-managed settings document, and only when the administrator selected the attribute’s category, as described under What the collector receives.

​
Resource attributes

These are set on every span.

​
agent.query

Root span, one per user turn. SpanKind INTERNAL.

​
agent.stream

One span per model API call, child of agent.query. SpanKind CLIENT. The add-in requests prompt caching on every call. Cache token attributes are set from the provider’s response and omitted when the provider does not return them.

​
agent.tool_execution

One span per tool call, child of agent.stream. SpanKind INTERNAL. This is the primary record of what the model did to the document.

​
agent.compaction

One span per automatic conversation summarization when context nears the window limit, child of agent.query. SpanKind CLIENT. Also carries office.platform and office.version beside the identity attributes the other agent.* spans carry.

​
file.upload

One span per uploaded file, emitted as its own root span rather than under agent.query. SpanKind CLIENT. Claude sign-in only. Also carries session.id and user.email. Correlate to the turn by session.id and timestamp.

​
Span events

Spans carry timestamped events for lifecycle transitions:
  • agent.query: exception, file_upload
  • agent.stream: first_token, stream_complete, stream_error
  • agent.tool_execution: tool_init, tool_run, tool_result, tool_error
  • agent.compaction: compaction_start, compaction_complete, compaction_error
  • file.upload: exception
Every internal product counter also records a span event with the same name on the active span. For example, office_agent.token.usage is emitted on each agent.stream span with token_usage.type (input, output, cacheRead, or cacheCreation), token_usage.model, and token_usage.token_count. Surface-specific events include office_agent.cell_edit_collision_total on Excel when a user is mid-edit while a tool writes, and the Word document-edit funnel (office_agent.doc_edit_received_total, doc_edit_parsed_total, doc_edit_applied_total, doc_proposed_edit_reviewed_total). PowerPoint and Outlook add no events beyond the common schema.

​
Reconstruct a user session

The span tree produces a complete, ordered transcript in both deployment modes. For Claude Enterprise deployments, filter agent.query spans by user.email or user.account_uuid and session.id, order them by timestamp, and read user.message and document.url for each turn. Then follow each agent.query span’s trace ID to its agent.tool_execution descendants, ordered by timestamp, to see what was attempted (tool.input), the result (tool.output), and how it was approved (tool.accept_decision). For direct-provider deployments, filter agent.query spans by session.id to isolate one session, use document.url to identify the file, and correlate the session against your Entra sign-in events, gateway access logs, or bootstrap endpoint logs to attribute it to a user. Per-turn reconstruction then follows the same trace-ID walk.