Agent telemetry moves into enterprise-managed settings
GitHub added OpenTelemetry configuration to the GitHub Copilot app on 22 September, giving enterprise owners a central way to export agent-session activity into an OpenTelemetry-compatible monitoring system. The setting is distributed through the enterprise managed-settings mechanism rather than requiring every developer to configure telemetry independently.
The exported data is structured around three signal types. Traces connect steps in an agent session, including model calls and tool use; metrics include measurements such as input and output token counts; and events can record point-in-time actions such as whether a user accepted or rejected an agent edit. That gives operators a common record for following how a session moved from a request through model and tool activity.
The export path uses standard OTLP infrastructure
GitHub documents the receiving side as an OpenTelemetry Protocol endpoint. Enterprises can send data directly to a compatible observability backend or place an OpenTelemetry Collector between Copilot clients and the final monitoring system. Client configuration includes the OTLP endpoint, headers and authentication token.
Managed settings can enforce that configuration across supported Copilot clients and cannot be overridden by users who receive it. GitHub currently lists Copilot CLI, VS Code, the GitHub Copilot app, the Copilot cloud agent and JetBrains IDEs as managed-settings clients, while also warning that individual properties do not necessarily have identical support in every client. The 22 September release specifically establishes OpenTelemetry support in the Copilot app.
Content capture is the sensitive boundary
By default, GitHub says the telemetry does not include prompts, model responses or tool arguments. Administrators can enable content capture, but GitHub explicitly warns that doing so can export sensitive material including source code, file contents and user prompts. The monitoring backend therefore becomes part of the enterprise data boundary when richer capture is switched on.
That choice is operationally separate from turning on basic agent tracing. An organisation can collect execution structure and usage signals without automatically exporting conversation content, then decide whether deeper debugging justifies the additional data exposure. Endpoint credentials, backend retention and access controls still need to be secured by the organisation receiving the telemetry.
Observability adds evidence, not a complete agent-control system
The release gives engineering and security teams a standard way to inspect agent behaviour in systems they may already use for application monitoring. It can help reconstruct unexpected tool sequences, compare token consumption across sessions and connect user edit feedback with the execution trace instead of relying only on a developer's local transcript.
OpenTelemetry does not by itself prevent an unsafe command, prove that every relevant action was captured or replace repository and tool permissions. GitHub's changelog and current documentation establish the data model and enterprise configuration. The practical completeness, performance overhead and usefulness of the resulting traces will depend on the client, capture settings and the monitoring pipeline an organisation deploys.