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.
On September 27, the managed-settings reference's telemetry section still says CLI and VS Code. Keep that discrepancy in the rollout record. The app announcement establishes the addition; your pilot needs to establish behavior on the exact version and session type you deploy. An app session that exports successfully 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 OTel overview describes traces, metrics, and events. It says prompts, responses, and tool arguments are excluded by default; optional capture can include sensitive code and file contents.
Use the following as an illustrative starting point for the managed JSON file. Replace the reserved example endpoint with your approved OTLP receiver and arrange the receiver's authentication before rollout. Merge the block into the existing policy rather than replacing unrelated controls.
Code source: illustrative configuration using GitHub's telemetry schema.
{
"telemetry": {
"enabled": true,
"endpoint": "https://otel-collector.example.com",
"protocol": "http/protobuf",
"captureContent": false,
"lockCaptureContent": true,
"resourceAttributes": {
"deployment.environment": "copilot-pilot"
}
}
}
The reference accepts http/protobuf and http/json. Use the managed property's documented values; an environment variable or backend tutorial may use a different vocabulary. captureContent chooses what to collect, while lockCaptureContent prevents users from changing that choice. The schema also supports request headers for collector authentication. Avoid placing a broad, long-lived monitoring credential in a policy distributed to developer machines.
Content capture disabled does not mean anonymous. Inspect remaining identifiers, paths, error text, and resource attributes before deciding who can access the backend. Set retention for that copy of the data. Use copilot-pilot to find the acceptance session, and establish user identity separately.
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?
GitHub's September 22 announcement says prompt and response content is excluded by default. Its general OTel documentation also excludes tool arguments by default. Set captureContent to false and lockCaptureContent to true, then inspect the actual app payload before approving collection.
- 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. GitHub's app release establishes managed OpenTelemetry support, but the settings reference still lists CLI and VS Code. Use the CLI schema as a reference and document the fields actually emitted by the app version and session type you deploy.
