How do you govern a team's AI coding agents?
Give each developer's coding harness its own identity, set policy on what it may reach across repositories, internal systems and the web, route its tool calls through one governed MCP endpoint that fans out to approved tools, and keep a tamper-evident record of every call. Start in monitor mode, so no policy is enforced until you decide.
One governed endpoint per team, one identity per developer, one record of what the harness reached.
The problem a team actually has
A coding harness is an agent with a shell. Claude Code, Cursor's agent and GitHub Copilot's agent read repositories, call internal services over the Model Context Protocol, fetch from the web and run commands. Each harness ships its own permission model, and each of those models is set per machine and per developer.
That leaves three gaps
Nobody holds one list of what the harnesses can reach.
Policy lives where the developer can edit it.
The only record of what happened is whatever the harness wrote on that laptop.
GitHub's own documentation notes that once an MCP server is configured for Copilot coding agent, the agent uses the server's tools autonomously and does not ask for approval before using them. The same is true of any harness a developer has told to stop asking.
What the KPATH Developer Edition governs
The Developer Edition puts the enforcement point KPATH uses for enterprise agents in front of a team's coding harnesses.
Claude Code
Cursor
GitHub Copilot
KPATH
One governed MCP endpoint- Repositories
- Internal systems
- The web
- Approved MCP tools
Identity per developer.
Every call from a harness carries the identity of the developer it acts for, with an owner and a risk tier behind it. Your identity provider decides who exists. KPATH enforces at the moment the harness acts.
Policy on reach.
Policy names which repositories, internal systems and web destinations a harness may reach, per developer and per team, rather than one flat setting for everyone.
One governed MCP endpoint.
The team's KPATH presents a single endpoint that fans out to every approved tool. Tool servers, and the credentials they need, sit behind it. KPATH adds the real credential for each system on an allowed call, and the harness never sees it.
One setting governs the model calls.
Point a harness's model base URL at the team's KPATH and every model call carries the developer's identity. Policy can cap tokens and requests per developer and per team, only the models policy allows are offered, and the cost lands against the developer who spent it. KPATH speaks the OpenAI and Anthropic API formats, so the harness needs no other change, and stopping a developer ends a reply mid-stream.
The harness's own web access.
A harness with a shell can reach the internet directly. Route that traffic through KPATH and each destination is allowed or refused by policy, every connection is recorded, and stopping a developer closes the connections they have open.
A record you can check.
Every call, allowed or refused, lands in a signed, tamper-evident record that can be streamed to your SIEM. It records who acted and what was decided, never a secret and never a message body, and it can be verified without trusting KPATH.
Guides for each harness
Govern Claude Code
Claude Code keeps its permission rules. KPATH decides, per developer, what those rules are allowed to reach.
Read the guide →Govern Cursor's agent
Cursor's agent reaches tools through one endpoint your team governs, not a dozen servers each developer configured.
Read the guide →Govern GitHub Copilot's agent
Copilot's agent uses MCP tools without asking; KPATH is the part that decides whether it should.
Read the guide →The governed MCP endpoint
One route for the harness, every approved tool behind it, one policy per developer, one record of every call.
Read the guide →Who adopts it, and why
The team that adopts it is usually the one already answering for the harnesses: a platform or developer productivity group that handed out the tools and now gets asked what they can touch. The alternative on offer is a per-machine arrangement nobody can audit, and an approval prompt the developer turns off in the first week.
What changes is that reach is decided outside the harness, a developer holds one credential rather than one per tool server, and the record of what the agent did lives somewhere other than the machine that did it.
The enterprise beachhead
The harness on a developer's laptop is the first agent most organisations run against real systems. The team that governed it will soon be asked how to govern the agents the business is building.
Nothing changes in the model. The identity provider is still the policy decision point, and KPATH is still the enforcement point. What KPATH Enterprise adds is depth: identity for every agent in the estate, governance of agent-to-agent chains, a kill switch that stops a whole chain and proves the stop held, evidence-grade audit, and air-gapped or on-premises deployment. A team that starts here has already named its callers, its targets and its policy, so expanding is a matter of scope, not a re-platform.
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. In between, the inventory fills in from real calls, including tools and destinations nobody registered, so policy is written against what the harnesses actually did.
See the KPATH platform →Common questions
Which coding harnesses does the KPATH Developer Edition govern?
Claude Code, Cursor and GitHub Copilot, and everything those harnesses reach: repositories, internal systems and the web.
Does KPATH read the code or prompts the harness sends?
No. KPATH governs the request envelope, meaning identity, target, action, size and delegation chain. It does not read your source, your prompts or your tool results.
Do developers have to change how they work?
Barely. The harness sends its tool calls to the team's governed MCP endpoint instead of to a list of tool servers. Nothing is rewritten, and developers keep their harness, their model and their prompts.
Can we start without blocking anything?
Yes. Every deployment starts in monitor mode, which observes only, enforces no policy and rewrites no agents. Only a failed credential or an agent you have explicitly stopped is refused. You switch to enforce by repointing egress.
Published Updated
Start in monitor mode. See everything before you enforce anything.
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. See the agents already running in your estate before you decide what to enforce.