Deployment models
KPATH governs any framework on any cloud or none. Where it runs is your choice, and the enforcement model is the same in each case.
| Model | Where the enforcement points run | Where the keys stay |
|---|---|---|
| Self-hosted cloud | Your own AWS, Microsoft Azure or Google Cloud estate | Your vault or key service |
| VPC | A private network you control inside your cloud estate | Your vault or key service |
| On premises | Your own data centre | Your vault or key service |
| Air-gapped | A network with no outside connectivity | Your vault or key service |
| Managed service | Run by KPATH | Your vault or key service |
Keys in your custody in every model
Agents carry no credentials. KPATH adds the real credential for each system on an allowed call, and those credentials are encrypted under a key held in your own vault or key service. KPATH is a crypto user, not a custodian. That holds in the managed service as much as on premises.
If you host your guardrail yourself, the content it inspects never leaves your boundary. KPATH itself governs the request envelope, and its record holds no payload.
Redundant enforcement points
An enforcement point in the call path is only acceptable if it is built like the other things already in that path. KPATH runs as several redundant enforcement points, the same pattern you already rely on for your API gateway and your identity provider.
Compare that with the usual alternative, where every team wires its own identity, limits and logging into every agent, and each one fails in its own way.
Failure behaviour you choose in advance
You decide before go-live what happens if KPATH itself has a problem. There are two settings.
| Setting | Behaviour during an outage | When to choose it |
|---|---|---|
| Continue on last decision | KPATH keeps applying the last decision it made for that agent and action | Availability of routine work matters more than a fresh decision on each call |
| Refuse until recovery | Calls are refused until KPATH recovers | The action is high stakes and an unverified call is worse than a delayed one |
Monitor mode raises the gap rather than waving through calls it cannot see. Nothing in any mode silently lets an unverified call through.
A decision API for existing enforcement points
Some estates already run enforcement points of their own: an API gateway, a service mesh, an MCP gateway. They do not have to be torn out. An existing enforcement point can ask KPATH for the decision instead of sending traffic through it. KPATH then acts as the decision service for identity, policy, budget, approval and chain state, and the existing point applies the answer.
Either way, your identity provider stays the policy decision point. Your identity provider decides. KPATH enforces, or tells your enforcement point what to enforce.
What KPATH does not replace
KPATH replaces nothing in the stack. Keep your identity provider, your guardrails engine, your agent platform and your existing APIs. It adds the enforcement layer the rest of the stack was never designed to provide, and it sends its evidence to the tools your security operations team already watches.
Evidence stays inside your boundary
Every decision streams to your SIEM as it happens and lands on write-once storage. In an air-gapped deployment the whole chain of evidence, from enforcement point to SIEM to retention, stays inside the gap, and the record can be verified there without contacting anything outside.
KPATH Enterprise scope
Air-gap and scale are KPATH Enterprise capabilities, alongside identity depth, chain governance and evidence-grade audit. KPATH Developer Edition is self-serve and governs coding harnesses; it is covered on the platform engineering page.