Three parts, usually confused
Governance programmes for AI agents tend to collapse three different things into one word.
The first is the decision: which agents exist, who owns them, what each is allowed to reach and do, what limits apply. This is policy, and it belongs with the people and systems that already decide access for everything else in the business.
The second is enforcement: applying that decision at the moment an agent acts, so a forbidden action does not happen. This is a property of the path the call takes, not of a document or a dashboard.
The third is evidence: a record that shows the decision was applied, to every call, in a form someone outside the team can check.
A programme with only the first part has governance on paper. A programme with the first and third can describe what went wrong. Only a programme with all three can stop it.
The identity provider decides
The right place for the decision is the identity provider you already run. It issues identities, holds ownership, and expresses what each identity should be allowed to do. In access-control terms it is the policy decision point.
KPATH does not replace that. It works with the identities you already issue and enforces them per action. Your identity provider decides. KPATH enforces.
Agents built by other teams and outside vendors arrive with their own identities. A vendor’s agent presents a verified identity and is checked like any other; one whose identity fails verification is refused outright. An estate governed only inside each agent’s framework never covers those callers.
Something must enforce
An identity provider cannot act on its decision when an agent makes a call. It is not on the path. Neither is a governance console that reads traces after the fact, nor a policy document, nor a review meeting.
Enforcement means a point that every governed call passes through, that can allow or refuse the call before the payload reaches the target. It has to be able to do a small number of concrete things on the call itself:
- verify that the identity presented is real and, when the agent acts for a person, that the person is verified too
- apply the policy for this agent, this action, this target, right now
- hold a high-risk action until a named person approves it, inline, not in a review later
- enforce a budget on the call so the spend limit stops the spending instead of reporting on it
- refuse everything downstream when an agent or a chain is stopped
None of those is a decision. Each is the act of carrying a decision out.
Why governance inside the agent fails
The common shortcut is to put the rules in the agent: in its system prompt, its framework hooks, its tool wrapper. That puts the control inside the thing you are trying to control.
Framework-level governance runs in the agent’s own code, which is exactly what a prompt injection captures first. A hijacked agent can decide anything it likes. Enforcement that sits outside the agent, on the path its calls have to travel, is not the agent’s to override. It also covers the agents other teams built, which self-governance never will.
Why one policy for everything also fails
The opposite shortcut is to lock everything down: one strict policy, every agent, no exceptions. That fails too, just more slowly. A read-only reporting agent drowns in sign-off built for one that can move money, while a genuinely powerful agent slips through on controls meant for a chatbot.
Gartner’s guidance makes the same point from the other direction: applying one blanket policy to every agent, harmless or high-stakes alike, is a leading cause of agent programme failure rather than a form of safety. The answer is control that matches the action. Tier agents by what they can do, read, write, spend, act without review, and set the controls to the tier.
Evidence closes the loop
A governance decision that cannot be shown to have been applied is an assertion. The record that closes the loop has to tie each action to the agent that made it, the authority it acted under, the decision taken and the outcome, and it has to be tamper-evident so an alteration is detectable.
A log you control is not evidence. KPATH writes a signed, tamper-evident record of every call, streamed to your SIEM and ready for write-once retention, that an auditor can verify without trusting KPATH’s console. It records who acted and what was decided, never a secret or a message body.
Where KPATH sits
KPATH is the policy enforcement point. Your identity provider remains the policy decision point. Every governed call passes through KPATH before the payload reaches the target; it verifies identity and principal, applies least-privilege policy, budgets and human approval, can stop one agent or an entire in-flight chain, and records the result.
It governs the request envelope only: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount. Keys stay in your own vault or key service.
Deploy in monitor mode first: observe only, enforce no policy, rewrite no agents. See the estate, set policy against how agents actually behave, then flip to enforce by repointing egress.