The platform team’s problem
Four teams, four frameworks, no registry. Agents get built independently across the business, most have no named owner, and the rules live in whichever team wrote them. Meanwhile every developer with a coding harness is already running an agent that reaches repos, internal systems and the web, with whatever credentials were to hand.
The platform team is asked to govern all of it without slowing anyone down. The order of work matters: start where the agents already are, inventory what else exists, then enforce.
Step one: the coding harnesses
KPATH Developer Edition is the beachhead. It governs developers using AI coding harnesses, including Claude Code, Cursor and Copilot, and everything those harnesses reach: repos, internal systems, the web.
The mechanism is a single governed MCP endpoint per team. A developer’s harness is pointed at the team’s KPATH rather than at a dozen individual tool servers. KPATH fans the request out to every approved tool, applying per-developer policy on the way. The harness keeps its model and prompts; the tools keep their protocol; the platform team gets one place to decide what each developer’s agent may reach.
| Without a governed endpoint | With a team’s KPATH endpoint |
|---|---|
| Each developer configures tool servers by hand | One MCP endpoint per team, fanning out to every approved tool |
| Credentials for repos and internal systems live in harness configuration | Agents carry identity only; KPATH adds the credential on an allowed call |
| No record of what a harness reached | Every call recorded, allowed or refused |
| Policy is whatever the developer set | Per-developer policy set by the platform team |
Adoption is self-serve, so the platform team does not have to run a rollout project to get the first team on.
Step two: inventory the estate in monitor mode
The coding harnesses are the agents you know about. The rest of the estate is the problem. Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Each agent needs a small change to send its calls to KPATH with its own identity, and none is rewritten.
The inventory fills in from real calls and holds both halves: what is calling, and what it reaches. That includes the console agent configured in a vendor’s assistant studio with no repository for a code scan to find, the pilot that never ended and still holds a write-access service account, the over-credentialled helper that needs one table and holds the whole database, and the partner’s agent arriving on an integration signed off years ago. It becomes representative once a normal business cycle has passed, since some agents only run weekly or monthly.
The governed directory can be the directory agents search, or sit alongside the Backstage or ServiceNow catalogue you already keep, or be skipped so only calls are governed. Different parts of the estate can use different arrangements.
Step three: owners, tiers, policy, enforce
With the inventory in hand, adopt what should exist by giving each agent a name, an owner and a risk tier. Retire what should not; turning off finished pilots is the cheapest risk reduction available. Then write policy against how agents actually behave and flip to enforce by repointing egress.
From that point every call is checked for identity, policy, budget and human approval, and budgets are enforced on the call rather than reported at month end. Spend is attributed per agent and rolled up to the originating request, which is the number finance has been asking the platform team for.
What the platform team keeps
Nothing gets torn up. Your identity provider stays the policy decision point and KPATH consumes the identities it issues, including the workload identities it verifies for high-risk agents. The guardrails engine you already run stays, invoked inline as a policy step. Your SIEM stays and receives every decision. Keys stay in the team’s vault or key service. Existing enforcement points can ask KPATH for a decision rather than routing traffic through it.
KPATH runs as several redundant enforcement points, the same pattern as the API gateway and identity provider the platform team already operates, with failure behaviour chosen in advance.
When KPATH Enterprise follows
Developer Edition covers the developer workflow. When agents act on real systems, moving money, changing records, running regulated workflows or delegating to other agents, KPATH Enterprise adds identity depth, chain governance, evidence-grade audit, air-gap and scale. The path in is the same enforcement point and the same inventory; the platform team extends what it already runs.