KPATH

How is KPATH deployed and what does each tier entail?

KPATH runs self-hosted in your AWS, Azure or Google Cloud estate, on premises, air-gapped, or as a managed service KPATH runs. In every tier keys stay in your custody and evidence lands in your SIEM and your write-once storage. The tier changes who operates KPATH, nothing else.

Any cloud or none: the tier changes who operates KPATH, never who holds the keys or where the evidence lands.

KPATH is any framework, any cloud or none. The deployment tier decides who operates KPATH and what network your agents depend on at runtime. It does not change the scope, the key custody model or where the evidence goes.

The tiers

Tier Who runs it Where keys live Where evidence lands Network dependency at runtime
Self-hosted in your cloud (AWS, Microsoft Azure, Google Cloud) Your platform team, in your own estate Your vault or key service in that cloud Your SIEM and your write-once storage Your cloud network only. No runtime dependency on KPATH-operated infrastructure
On premises Your platform team, in your data centre Your on-premises vault or key service Your SIEM and your write-once storage Your network only. No runtime dependency on KPATH-operated infrastructure
Air-gapped Your platform team, inside the isolated environment A vault or key service inside the same environment Storage and SIEM inside the same environment None outside the environment
Managed by KPATH KPATH operates the service Your vault or key service. Keys remain in your custody Your SIEM and your write-once storage Agent traffic reaches the KPATH-operated service at runtime

Two things hold across every row. Keys stay in your custody, because KPATH is a crypto user, not a custodian. And the evidence goes to systems you already read: your SIEM for the stream, and write-once storage you control for retention.

Availability and failure behaviour

Being on the path is what lets KPATH allow or refuse a call while it is happening, so the path has to be as available as the systems behind it. You decide the failure behaviour in advance, per agent and action, and the choice is made before anything is enforced. In monitor mode a gap is raised rather than quietly waved through.

If you already run enforcement points

Enforcement points of your own do not have to be replaced. They can ask KPATH for a decision rather than sending traffic through it, and every decision is recorded in the same audit record. The idea is described on the decision API page.

What does not change with the tier

The scope is the same in every tier: KPATH governs the envelope and reads only the payload values you declare for a rule. So is key custody, with credentials encrypted under a key in your vault or key service. So is the evidence, signed, tamper-evident and verifiable without trusting KPATH. And every deployment starts in monitor mode, whichever tier it runs in.

FAQ

Common questions

Can KPATH run without any connection to the internet?

Yes. KPATH supports air-gapped deployment. Policy, keys and evidence all stay inside the isolated environment.

Is KPATH a single point of failure?

You decide in advance what a failure does, and the behaviour is set before anything is enforced, so an outage produces the outcome you chose rather than one the vendor chose for you.

Do we have to route traffic through KPATH?

No. Existing enforcement points you already run can ask KPATH for a decision instead of sending traffic through it.

Where do the keys live in the managed tier?

In your custody. In every tier, credentials are encrypted under a key held in your own vault or key service. KPATH is a crypto user, not a custodian.

Published Updated

The first step

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.

Book a monitor-mode pilot See the platform