What GitHub changed
GitHub’s October 12 update lets enterprise administrators attribute Copilot activity to a user separately from collecting prompts, responses, or tool content. Optional identity fields include the GitHub login, operating-system account, and machine name. Identity capture is off by default.
Administrators can independently configure prompt, response, tool-argument, tool-output, and policy-detail capture; these classes also default to off. The controls cover Copilot CLI, the Copilot app, and VS Code sessions using Agent Host. Explicit managed settings override local choices. GitHub cautions that content capture can include code, files, commands, and filesystem paths.
Source: GitHub: Client telemetry user attribution and configurable capture ↗
Our take: start with the purpose
For someone starting an internship or joining a coding club, AI monitoring can sound abstract until the assistant is working with material you care about. Our interpretation is that an organization should explain the question a log is meant to answer before deciding what to collect. Debugging a failed tool call and measuring adoption are different purposes.
A useful discussion starts with a concrete scenario. Suppose a team wants to understand why an agent repeatedly fails to open a project file. Ask whether an error category would answer that question, whether the full file contents are necessary, and who would actually review them. This does not establish what any particular system supports. It is a way to challenge an unnecessarily broad collection plan.
Identity also deserves its own justification. An aggregate count might be enough for one decision, while investigating an incident could require an accountable record. The people using the tool should be told which situation applies, how long records are retained, and how they can raise concerns. A setting being available does not itself settle those choices.
A conversation you can have this week
If your workplace manages your AI tools, ask the administrator for a plain-language summary of the logging policy. Focus on what is collected, where it goes, who can access it, and when it is deleted. Ask whether your local preferences can be overridden. The point is to understand the operating conditions before submitting sensitive project material.
For a small team you run yourself, write a short proposed policy with one purpose and the minimum information you think it requires. Walk through an example with a teammate. Can they explain what a log would contain without guessing? If not, revise the wording before changing any settings.
This is a suggested transparency exercise, not a legal determination or a review of your organization’s configuration. Good AI governance becomes much easier to discuss when the data flow is specific enough for ordinary users to understand.
Try this, then make it yours.
Ask for a four-part logging summary: collected data, destination, access, and retention.
Follow the signal.
Our reporting starts here. Practical suggestions are our analysis, and vendor performance statements are claims unless independently verified. We haven’t hands-on tested this release.
