On September 22, 2026, GitHub added enterprise-managed OpenTelemetry to the Copilot app. Security teams can route agent activity to an approved monitoring backend. That creates two rollout decisions: which activity must arrive, and which content must stay out of that export.
Start with content capture disabled and locked. Send a harmless app session through the intended deployment, inspect what the collector receives, and keep the result with the policy revision. An enabled setting cannot tell you whether a missing trace means no activity, a different account, or a broken export path.
The procedure below is a proposed administrative acceptance check based on GitHub's documentation. General Analysis has not tested it in a Copilot deployment. For controls around the agent itself, use the broader coding-agent security baseline.
Establish app support without extending it to every surface#
The dated announcement explicitly names the Copilot app and the telemetry property in managed-settings.json. It does not specify a minimum app build or promise identical signals across all Copilot products.
The current managed-settings reference includes the Copilot app. Fine-grained capture works in the CLI, app, and VS Code sessions using Agent Host. VS Code's local agent harness supports identity capture and the older combined content setting, but not separate switches for the five content classes. Check the exact harness in your pilot; a successful app export leaves cloud-agent coverage unanswered.
Record the app build, operating system, signed-in account, billing enterprise, and whether the session runs locally or elsewhere. A trace arriving from a developer's separate CLI process does not establish that the app pilot worked.
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.
Keep content collection an explicit decision#
GitHub's October 12 update separates identity capture from five content classes: prompts, responses, tool arguments, tool output, and policy details. All six default to off. Identity capture can export the authenticated GitHub login, local operating-system account, and machine name without collecting those content classes.
The OTel overview explains which content may enter an export. Capture can expose source code, file contents, commands, reasoning, and workspace paths. Enable a class only when the investigation needs it.
This illustrative configuration assumes the pilot has approved user and machine attribution. Otherwise, set identity to false. Replace the example endpoint with your approved OTLP receiver, configure its authentication, and merge the block into the existing policy.
Code source: illustrative configuration using GitHub's telemetry schema.
{
"telemetry": {
"enabled": true,
"endpoint": "https://otel-collector.example.com",
"protocol": "http/protobuf",
"capture": {
"identity": true,
"prompts": false,
"responses": false,
"toolArguments": false,
"toolOutput": false,
"policyDetail": false
},
"captureContent": false,
"lockCaptureContent": true,
"resourceAttributes": {
"deployment.environment": "copilot-pilot"
}
}
}
The reference accepts http/protobuf and http/json. captureContent is the older shorthand for the five content classes; it never enables identity. An explicit capture value wins for that class. The managed values above keep content disabled; lockCaptureContent also prevents local settings from enabling an otherwise unspecified content class. It does not govern identity. The schema supports request headers for collector authentication, but avoid distributing a broad, long-lived credential to developer machines.
Content capture disabled does not mean anonymous. The example deliberately collects identity. Inspect the actual identifiers and resource attributes before deciding who can access the backend, and set retention for that copy. Use copilot-pilot to locate the acceptance session and check attribution against the intended account.
If an investigation later needs captured content, document the specific missing evidence and approve collection for the necessary population and period. Also review copies forwarded from the collector. Deleting one dashboard does not establish that every downstream copy was removed.
Verify the policy source before diagnosing the collector#
For server delivery, place copilot/managed-settings.json on the default branch of the selected .github-private governance repository. The setup guide ties delivery to the user's enterprise Copilot license. When several entities supply licenses, check Usage billed to in the user's Copilot settings.
Server changes normally reach supported clients within about an hour; restarting or signing in again triggers a refresh. Record that refresh in the pilot. Do not keep changing the collector URL while the app still has an older policy.
Device policy can explain a different destination. GitHub's deployment precedence puts MDM before server settings, then managed files, then user settings. Its restrictive-composition exceptions concern sandbox and permission rules. Check all telemetry delivery sources instead of assuming the most recently committed repository value wins.
For example, suppose the server policy points at a new receiver but a device policy still specifies the old receiver. A quiet new dashboard is consistent with that conflict. Inspect the effective configuration and both receivers before classifying the user as inactive. Keep general policy-delivery troubleshooting in the managed permissions guide.
Separate repository validation from session evidence#
GitHub added its in-product settings validator on September 25. Under enterprise AI controls → Agents, Copilot settings validation reports problems in the managed file, team mappings, and referenced team files, with the affected file and JSON path. Correct the source file, commit to its default branch, and reload the page.
After validation, you still need to establish which client fetched the result and whether its exporter reached your receiver.
Use a disposable workspace with dummy text for the next check. Note a short time window, ask the app to read the fixture, and confirm that a tool request actually occurred. Find the corresponding session at the intended collector. Inspect the raw payload available at ingestion as well as the backend view, since processing can remove fields or entire records.
These are recommended acceptance criteria, not observed test results:
| Check | Evidence to retain | Decision if it fails |
|---|---|---|
| Intended app and account received the policy | App build, account/license source, policy revision, refresh time and available client diagnostics | Resolve delivery before changing export settings. |
| The known session reached the intended receiver | Session and trace identifiers, timestamps, receiver and backend records | Investigate routing, authentication, TLS and processing. |
| Content capture stayed disabled | Payload inspection using dummy prompts and tool data; effective capture setting and lock | Pause expansion and identify the source of unexpected content. |
| Tool activity can be followed | Observed tool spans or events linked to the known session | Record the missing operation or field as a coverage gap. |
| Export failure is visible to operators | A documented collector-health alert and a safe outage drill in the pilot | Do not describe silence as successful monitoring. |
GitHub's CLI OTel reference documents invoke_agent, chat, and execute_tool spans. It includes conversation and tool-call identifiers; tool arguments and results require content capture. Those fields are useful starting points for inspection, but retain the schema actually emitted by the app. Do not treat a CLI field list as a guarantee of app completeness.
For a suspected external write, check the destination system's history. For adoption or unknown MCP usage across a reporting period, use the separate Copilot CLI metrics review.
Decide what happens when telemetry stops#
The cited app release does not promise that an agent stops working when the collector is unavailable. If a workflow requires monitoring as a condition of access, decide which independently enforced control will pause that workflow and who operates it. An exporter configuration is insufficient evidence of that behavior.
Approve the pilot when the intended app session arrives, its payload matches the collection policy, and missing delivery produces an actionable signal. Keep the app version and policy revision with that decision so an upgrade or routing change has a concrete acceptance record to repeat.
Frequently asked questions
- Does Copilot app OpenTelemetry include prompts by default?
No. All six capture classes default to false. Explicitly disable prompts, responses, toolArguments, toolOutput, and policyDetail in managed telemetry.capture, keep captureContent false and lockCaptureContent true, then inspect a harmless session's payload. Choose identity capture separately.
- Does a valid managed-settings file prove that app telemetry is arriving?
No. Repository validation checks configuration errors. Verify the intended account and client, refresh the policy, and find a known app session in the intended collector. Record delivery failures separately from periods with no observed activity.
- Can the CLI telemetry schema be assumed to cover every Copilot app session?
No. The current settings reference includes the Copilot app, but supported capture controls vary by client and harness. Verify the fields emitted by the exact app version and session type you deploy; a CLI field list does not prove complete app coverage.
