Two places Copilot reaches tools
GitHub Copilot’s agent runs in two shapes, and each reaches tools its own way.
In the editor, the developer’s agent mode calls tool servers over the Model Context Protocol. GitHub documents an organisation and enterprise policy, named MCP servers in Copilot, that is disabled by default for Copilot Business and Copilot Enterprise and must be turned on before agent mode can use MCP at all.
Copilot coding agent is the other shape. It runs on a repository rather than a laptop, started by an issue or a pull request, with tool servers a repository administrator has declared. GitHub is direct about the consequence: once a server is configured, Copilot uses its tools autonomously and does not ask for approval before using them. An administrator can limit which of a server’s tools are exposed, which is a useful control, but it is a list of names. It is not a decision per developer, per action and per system, and it leaves no record an auditor can check.
What a team gets to decide
With KPATH on the path the agent’s tool calls travel, both shapes answer to the same policy.
- Who is acting. Every governed call carries an identity with an owner and a risk tier. For a developer in the editor, that is the developer. For the coding agent, which acts on a repository rather than for a person at a keyboard, it is the agent’s own identity, owned by the team that owns the repository.
- What that caller may reach. Which tools, which repositories, which internal systems, which web destinations, per developer and per team, decided on each call rather than once at setup.
- What it may spend. Budget is checked on the call itself and attributed back to the caller and the originating request.
- When a person has to agree. Policy can require a human to approve before a high-risk action proceeds.
- What stops. An agent, or a whole chain it set off, can be stopped and stays stopped.
An agent that starts reaching for systems it never used, or produces a run of refusals, is flagged, and a high-risk agent can be paused automatically. The harness holds one credential and nothing else: KPATH adds the real credential each system needs on an allowed call.
What gets recorded
Every call, allowed or refused, lands in a signed, tamper-evident record: who acted, which tool, which target, what was decided and why. It streams to your SIEM and is ready for write-once retention. It never holds a secret, a prompt or a message body, and an auditor can verify it has not been altered without trusting KPATH.
KPATH governs the request envelope: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount.
Why this matters more for a coding agent
A coding agent runs unattended, on a schedule set by an issue or a pull request, with tools it will use without asking. That is the clearest case for enforcement outside the harness. Deploy in monitor mode first: observe only, enforce no policy, rewrite no agents. Watch what the agent actually reaches for over a week of real work, then flip to enforce by repointing egress.