The shape of it
Without governance, the set of tools a coding harness can call is a list. Each entry is a tool server with its own address, its own credential and its own settings, held on each developer’s machine. Ten tools, thirty developers, three hundred arrangements, and no one place that says what any of them may reach.
A governed MCP endpoint replaces the list with one entry. The harness talks to a single governed route, and KPATH sits behind it doing four things on every call.
Fan-out to approved tools. The endpoint presents the union of every tool server the team has approved. When the harness asks what tools exist, it sees the ones policy allows for this developer. When it calls one, KPATH routes the call to the right server. The harness never holds a server address.
Policy per developer. Every call carries the identity of the developer the harness is acting for. Policy is written against that identity, its team and its risk tier: which tools, which repositories, which internal systems, which web destinations, what budget. The decision is made at the call, not once at onboarding.
Credentials the harness never sees. The harness carries its own identity and nothing else. KPATH adds the real credential for each tool server on an allowed call. Those credentials are encrypted under a key held in your own vault or key service. A compromised laptop holds nothing that opens a door anywhere else.
A record of every call. Each call, allowed or refused, is written to a signed, tamper-evident log: who acted, which tool, which target, what was decided and why. It is streamed to your SIEM and ready for write-once retention. 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. Tool arguments and results pass through unread.
How it relates to an MCP gateway
An MCP gateway sits in the same position: between MCP clients and MCP servers, routing calls. If you have one, the question is what it checks.
An MCP gateway governs one protocol. It knows about servers and tools. A governed KPATH endpoint checks who the developer is, what that developer may reach across tools, repositories and internal systems, whether a budget has room, whether an action needs a person to approve it, and whether the agent or the chain it belongs to has been stopped. It records each of those decisions, not just the route.
The two are not exclusive. An existing enforcement point can ask KPATH for a decision through the decision API rather than routing traffic through it. The longer comparison is on the MCP gateway page.
Where the endpoint runs
KPATH runs in your own cloud or data centre, on AWS, Microsoft Azure, Google Cloud or on premises, or as a service KPATH runs for you. It works with the identities you already issue through your identity provider, including workload identities for callers that need them.
Monitor first
A governed endpoint starts in monitor mode. Every tool call is recorded and allowed. Only a failed credential or an agent explicitly stopped is refused. Once real work has run through it, the inventory shows which tools each developer used and which systems they reached, including ones nobody registered. Write policy against that, then switch enforcement on.