GitHub Copilot Audit Logs: The Missing Prompt Record

A pull request at 16:18 UTC adds a dependency, an engineer accepts a Copilot suggestion, and the next build passes. GitHub can show repository and enterprise activity around that work. A separate question matters during review: which code context crossed an LLM endpoint, under whose identity, and which policy applied?

GitHub documents enterprise audit-log review and provides controls for Copilot content exclusion. Those documents define important administrative evidence. They do not turn a repository event into a per-request model-call record.

TL;DR

• GitHub Copilot audit logs should be reviewed with repository evidence and model-request evidence, while preserving identity and content-exclusion context rather than treating everything as one undifferentiated export.
• Enterprise audit events can show configuration and access activity; request-level records establish the code context, originating identity, route and policy, plus the outcome at AI egress.
• Repository permissions, local IDE controls, runner execution and stolen credentials, as well as GitHub provider operations, sit outside DeepInspect's HTTP AI enforcement boundary.
• My view is that a software organization should be able to sample an accepted suggestion and reconstruct its policy path without asking an engineer to remember it weeks later.

An event taxonomy for Copilot reviews

Start with event categories, not a large log download. Enterprise administration events establish who changed Copilot-related settings and when. Repository events establish the codebase and branch context. Identity events show SSO and access lifecycle activity. Content-exclusion configuration shows which paths have a distinct policy treatment.

Each category answers a different question. An audit event for a configuration change can establish governance. A repository event can establish a code change. LLM observability and securing the inference lifecycle address the request-level evidence that proves which code, comments, or prompt context became part of a particular model request.

The distinction becomes visible during a tabletop exercise. Put the timeline on a whiteboard with GitHub administration and a developer workstation, then add a model request. The gap between the last two columns is often where the provenance story stops.

The export should therefore be read as a sequence, not as proof that every stage contains the same level of detail. First identify the administrative event that establishes the relevant setting. Then correlate the repository activity with the developer or agent involved. Finally, look for the request-level record at AI egress. If that last record is absent, the review can still show that a suggestion was accepted, but it cannot show the policy path for the model call itself.

That distinction also prevents an evidence review from assigning the wrong owner. GitHub's audit history can answer questions about a setting or repository action. A request record can answer what the application presented to the model route and what decision was made before the response returned. The two records should be correlated without pretending that either one replaces the other.

The request record that closes the gap

For every HTTP AI request, preserve an originating human or agent identity, the application identity, model route, request class, policy version and outcome, plus timestamp. When permitted by policy, add a protected reference to the relevant code context or a stable hash. The record needs enough detail to support correlation without creating a second repository of sensitive source code.

This is also where content exclusions and code classification meet. GitHub's documented exclusions can shape platform configuration. A request-bound policy decision can separately evaluate the actual route and content class presented by the application at egress. Both layers have value because they operate at different points.

NIST's software and AI agent identity project emphasizes identity and delegated authority, with action lineage. That framing is useful when an IDE plugin, a CI agent, and a human developer all participate in one change.

Boundary ownership stays explicit

DeepInspect can inspect HTTP AI traffic between authenticated users or agents and LLM endpoints. It can evaluate application-supplied identity context and policy before the call, then generate a per-decision audit record. That scope covers the model egress decision, including an IDE or agent flow that reaches a compatible endpoint.

GitHub repository permissions, branch protection, secret scanning, local IDE extensions, CI runner execution, code signing and IAM lifecycle, plus provider-side service administration, remain outside that boundary. Credential theft also requires dedicated identity and incident-response controls. Clear ownership makes a review stronger than a claim that one proxy governs the whole developer toolchain.

DeepInspect

DeepInspect provides an independent enforcement point for HTTP AI calls from authenticated users or agents to LLM endpoints. It binds an application-supplied origin identity, route, content classification and policy version, then records the decision before the response is returned.

In a Copilot-related architecture, that evidence complements GitHub's administrative and repository audit history. Repository governance, local developer controls, CI execution and GitHub settings, while IAM remains an adjacent control domain.

Book a technical deep dive at deepinspect.ai.