Control level
| What | Level |
|---|---|
| Tool calls | Enforced with a policy hook in /etc/github-copilot/policy.d |
| MCP rules that name a server | Not covered: the hook input does not name the MCP server separately |
| Model traffic | Not routable: no supported setting sends Copilot's requests elsewhere |
| GitHub Copilot usage | Monitored through the vendor connector (seats, usage and metrics) |
This is the most strongly proven of the vendor tools. Copilot CLI 1.0.98 was run for real, offline, with the compiled policy file and the real endpoint agent: a denied rm -rf was refused, also with disableAllHooks in the developer's settings and with the agent binary missing, and an allowed ls ran.
1. Write the policy and enrol the machine
Write rules in Agent policy (Agent policy) and enrol the machine with the endpoint agent (Deploy). The agent fetches the policy compiled for the copilot-cli engine and installs policy.d/keystone.json in /etc/github-copilot/policy.d.
Policy hooks there must be root-owned, are not turned off by disableAllHooks, and run regardless of folder trust.
2. How failures and asks behave
- A crash or non-zero exit of the hook denies the call.
- A timeout lets the call through, so Govern's hook always answers before its deadline.
- Copilot CLI supports asking, so
askrules ask the developer.
Check the gaps on Agent policy > Policy preview with the engine copilot-cli.
A hook file in a repository (.github/hooks) is not locked and only advisory. Only the root-owned policy directory gives the Enforced level.
Monitoring Copilot
GitHub Copilot seats, usage and metrics come in through a vendor audit connector; see Evidence.