The scope is fixed and short. 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.
The envelope, and nothing beyond it
Every one of those fields is metadata about the request rather than the request itself. Together they are enough to verify the agent, decide whether this call is allowed, and record what was decided. They are also the whole of what KPATH takes.
Agents carry their own identity and nothing else. They hold no system addresses and no credentials. On an allowed call KPATH adds the real credential for the target, and the agent never sees it.
What KPATH never sees
- The payload. The body of the request is not read by KPATH.
- Secrets. Credentials for governed systems are encrypted under a key held in your own vault or key service. KPATH is a crypto user, not a custodian.
- Message bodies. The audit record contains no message body and no secret.
This is a scope decision, not a configuration option. An enforcement point that inspected content would have to hold content, and the value of KPATH’s record depends on it not doing so.
Where guardrail inspection runs
Content inspection is a separate job from enforcement, and it belongs to the guardrail you already chose. KPATH invokes your guardrails engine as a policy step and records the verdict.
It works with the guardrail you already run, including your own content scanner. When the guardrail is self-hosted, the content it inspects stays inside your boundary. KPATH sees whether the guardrail passed or refused the call, not what the guardrail read.
Retention is metadata only
What KPATH retains is the record of the call: who acted, on whose authority, what was decided, and the outcome. That record is signed, tamper-evident and streamed to your SIEM, ready for retention on write-once storage you control.
Nothing in the record is a secret or a message body. An auditor reading the record learns which agent did what and whether it was allowed. They do not learn the contents of the request, because the record never held them.
KPATH sets no retention period of its own. How long the record is kept is what you set on the write-once store, and your SIEM keeps its copy under its own policy.
What a security review asks
Reviews of an inline component come down to exposure: what does it hold, and what would an attacker get from it. For KPATH the answer is the envelope and the record. No payload, no secret, no key.