GitHub Copilot audit logs: what admins can see, by plan, and the gaps

the short answer

Partly. The enterprise audit log keeps Copilot settings, policy and license events plus agent activity on GitHub.com, such as pull requests the cloud agent opened, for 180 days. GitHub says it does not include client session data such as prompts sent to Copilot locally. For local activity, enable OpenTelemetry export in enterprise managed settings, with opt-in content capture, or use hooks.

Audit log retention: 180 days; stream to a SIEM for longer
Agent events: actor:Copilot, with actor_is_agent, agent_session_id and the human user
Not included: Client session data such as local prompts
Local telemetry: Managed telemetry.* OTel export; content capture off by default
Hooks: Repository, user and root-owned policy hooks in Copilot CLI

Copilot Log Sources Compared

GitHub’s audit-log guidance is explicit: the audit log does not include client session data such as local prompts, and it suggests custom hooks that send Copilot CLI events to your own logging. Managed telemetry takes precedence over local settings, SDK configuration and environment variables.

Source	What it records	Gaps
Enterprise audit log, `action:copilot`	Settings, policy and license changes	No session content
Enterprise audit log, `actor:Copilot`	Agent activity on GitHub.com, with `agent_session_id` and the human who started it	Cloud agent activity on GitHub, not local CLI or IDE sessions
API usage record streaming (public preview)	Request and response records, with `body` capped at 1 MB	Only for Enterprise Managed Users or data-residency enterprises; whether `body` holds prompt text is not stated
Managed OpenTelemetry (`telemetry.enabled`, `endpoint`, `capture.*`)	CLI, the Copilot app and VS Code telemetry to your collector; `capture.identity` adds user and host	Content capture is off by default; the fine-grained `capture.*` classes apply to CLI, the app and VS Code Agent Host, while VS Code’s local agent harness honours the legacy `captureContent`; managed telemetry is also supported in JetBrains
Hooks	Whatever your hook logs; policy hooks in `/etc/github-copilot/policy.d/` cannot be disabled	You build the pipeline; hook timeouts fail open

Turn on OTel from Managed Settings

The highest-precedence managed source supplies the whole telemetry object, so include enabled and endpoint alongside capture. Keep prompts and responses off unless you have decided to collect them.

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "capture": { "identity": true, "toolArguments": true }
  }
}

Filling the Gap with a Hook-Level Client

Failproof hooks Copilot CLI (blocking verified on PreToolUse, UserPromptSubmit, PermissionRequest, Stop and SubagentStop) and records each session and policy decision per machine alongside Claude Code, Codex and Cursor sessions. failproofai otel enable copilot routes Copilot in VS Code telemetry to Failproof Cloud through a local relay. failproofai config installs a user-level hook (Failproof supports user and project scope for Copilot CLI). Placing the same command in a root-owned policy.d file, which users cannot remove, is a manual step outside what Failproof installs; test it first, and remember policy hooks still fail open on timeout. See the Copilot CLI policy hooks example.

FAQ

Does the audit log show what developers asked Copilot?

No. GitHub states that the audit log does not include client session data such as local prompts.

How long does GitHub keep Copilot audit events?

180 days. Stream the audit log to a SIEM for longer history.

Can I attribute cloud agent work to a person?

Yes. Agentic audit events carry actor_is_agent, agent_session_id and the user who started the session.

Sources

Checked against the sources below on October 21, 2026. Harness settings, hook capabilities and cloud features change between versions.