Is it safe to route AI agents through KPATH?
KPATH governs the request envelope and reads only the payload values you declare for a rule. Keys stay in your own custody. It runs in your cloud, on premises, air-gapped, or as a managed service. You choose its failure behaviour in advance, and its audit record can be verified without trusting KPATH.
KPATH decides on the envelope, not the payload; your keys stay yours; and the record it produces can be checked without taking KPATH's word for it.
The short version, for a security review
Putting anything on the path between your agents and your systems is a decision a security team should make slowly. What follows is the short version of what KPATH does with that position, and the pages it links to carry the rest.
What KPATH sees
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. Message bodies and the contents of what an agent sends are not inspected by KPATH, and its audit record holds no secret and no message body.
If you run a content guardrail, KPATH invokes the guardrail you already chose as a policy step and records the verdict. A self-hosted guardrail keeps the inspected content inside your boundary.
What does KPATH see? →Who holds the keys
Keys stay in your custody, in your own vault or key service. Credentials for each governed system are encrypted under a key you hold. KPATH adds the real credential on an allowed call, the agent never sees it, and KPATH never holds the key. KPATH is a crypto user, not a custodian.
Where it runs
KPATH runs in your own AWS, Microsoft Azure or Google Cloud estate, on premises, or fully air-gapped. A managed service run by KPATH is also available. In every tier, keys remain in your custody and the evidence lands in your SIEM and your write-once storage.
How is KPATH deployed? →What happens when it fails
You decide the failure behaviour in advance, and it is set before anything is enforced. Monitor mode raises the gap rather than waving through calls it cannot see. If you already run enforcement points of your own, they can ask KPATH for a decision instead of routing traffic through it.
Monitor mode enforces no policy
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress. Only a failed credential or an agent you explicitly stopped is refused before that.
A log you control is not evidence.
The KPATH audit record is signed and tamper-evident, and you can check it yourself: run KPATH's standalone verifier against an export and it tells you whether anything was altered. The record lands on write-once storage in your custody.
How do you verify a KPATH audit log? →Every page in Trust
What does KPATH see?
KPATH sees the request envelope: the agent's identity, the target it is calling, the action it is asking for, the size of the request and the delegation chain behind it. It does not read the payload, apart from values you declare for a rule, and its record holds no secret and no message body. Retention is metadata only.
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.
How do you verify a KPATH audit log without trusting KPATH?
You export the record to write-once storage you control and run KPATH's standalone verifier against it. The record is signed and tamper-evident, so the verifier reports whether anything was altered, removed or inserted since it was written. It runs offline, and KPATH's console is not involved.
The checks people run before routing agents through anything.
Does KPATH read our payloads?
Only the values you declare for a rule, such as a payment amount. KPATH governs the request envelope, meaning identity, target, action, size and delegation chain, and its audit record contains no secret and no message body.
If attacks hide in prompt content, why doesn't KPATH read the payload?
Because reading content is your guardrail's job, and KPATH runs the guardrail you chose inline, as a policy step on the call. What content inspection cannot know is who is calling, what that caller may reach and what the rest of the chain has done. KPATH decides that part. So an injection that gets past the content check still has to get past identity, authority and scope before it reaches a system, and your data does not pass through another store that reads it.
Who holds the encryption keys?
You do. Keys stay in your own vault or key service. KPATH is a crypto user, not a custodian.
What happens if KPATH fails?
You decide in advance. The failure behaviour is set before anything is enforced, so a failure produces the outcome you chose rather than one the vendor chose for you.
What does monitor mode put at risk?
No policy is enforced in monitor mode. KPATH observes calls, inventories agents and services, and enforces no policy. Only a failed credential or an agent you have explicitly stopped is refused.
Does KPATH need a cloud connection?
No. KPATH runs self-hosted in your AWS, Azure or Google Cloud estate, on premises, or fully air-gapped. A managed service run by KPATH is also available for teams that want it.
Which agent frameworks does KPATH work with?
Any framework. Agents make a small change to send their calls through KPATH and keep their framework, model and prompts. Nothing is rewritten.
Does KPATH replace our identity provider?
No. Your identity provider stays the source of identity. KPATH consumes the identities it issues and enforces the decision at the moment the agent acts.
Can the audit record be verified without trusting KPATH?
Yes. The record is signed and tamper-evident. A third party runs KPATH's standalone verifier against an export and learns whether anything was altered, with no access to KPATH's console required.
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.