Why four questions
Every vendor in this category describes the same capabilities: identity, policy, kill switch, audit. What the words hide is whether the capability acts on the call or reports on it afterwards.
The Verify-Enforce-Stop-Prove test strips the words away. Each question has a pass and a fail that can be demonstrated on live traffic in a proof of concept. It applies equally to a vendor’s product, a gateway with a policy tab, and a platform you build yourself.
1. Verify
The question. Can the product check who is calling, and for whom, against the identity system you already run, on every call?
A pass looks like this. Every call carries the agent’s identity, with an owner and a risk tier. The product checks that identity with your identity provider rather than accepting it from a header. High-risk agents can be required to present a workload identity that the identity provider verifies, rather than a name the agent asserts about itself. When the agent acts for a person, the call carries the person too, and policy can insist the person is verified before a high-risk action proceeds. An agent whose identity fails verification is refused.
A fail looks like this. Identity is a string the agent sends about itself. The product knows an API key arrived but not who holds it. The person behind the request is absent from the call, so a customer’s instruction and a prompt injection look the same. Agents built by other teams or vendors are outside the scheme entirely.
2. Enforce
The question. Can the product apply the decision before the action happens, on this call, for this agent, this action, this target, right now?
A pass looks like this. The product sits on the path of the call. Policy is per action, not per agent, and tiered to risk. A budget is enforced on the call, so the limit stops the spending. A high-risk action stops and waits for a named person to approve it, inline, and the approval lands in the same record as the action. If any check fails, the call stops there and the refusal is recorded.
A fail looks like this. The product flags a risky call, logs it, and lets it proceed. Approval is a review meeting. Budget is a report that arrives after the money moved. Policy lives inside the agent’s own code, where a prompt injection can rewrite it.
3. Stop
The question. Can the product stop an agent and everything that agent set in motion, immediately, and keep it stopped?
A pass looks like this. Any agent, or a whole chain of agents, can be stopped at once. The chain loses the credentials it relied on. The stop holds without waiting for a token to expire or a deployment to roll back. Afterwards, a record anyone can check shows that nothing in the chain was authorised after the stop. The product also notices out-of-pattern behaviour and pauses high-risk agents automatically.
A fail looks like this. Revoking the agent leaves the payments agent it called still running and the transfer still going out. The stop depends on credential expiry. There is no way to show what did and did not happen after the stop.
4. Prove
The question. Can someone who does not trust the vendor verify what happened?
A pass looks like this. Every call, decision and outcome is written to a tamper-evident record that ties the action to the agent, the authority it acted under and the time. The record is signed and tamper-evident, streamed to your SIEM as it happens, and ready for write-once retention. An auditor can verify, offline, that the record has not been altered, without access to the vendor’s console. The record contains who acted and what was decided, never a secret or a message body.
A fail looks like this. The evidence is a dashboard. Export produces a CSV nobody can validate. The record and the console that renders it are the same system, so the vendor is asking to be trusted. A log you control is not evidence.
Running the test
Run it on one realistic chain, not on a feature list. Set up an assistant that calls a payments agent that moves money. Present an agent whose identity your identity provider will not verify; attempt a payment above the budget and one that requires approval; stop the assistant after it has handed off to the payments agent; and hand the record to someone outside the project to verify offline. Each step passes or it does not.
How KPATH answers
Verify. Every call carries the agent’s identity with an owner and a risk tier, checked against the identity provider you already run rather than accepted from a header. High-risk agents can be required to present a verified workload identity. When an agent acts for a person, policy can insist the person is verified too. Failed verification is refused.
Enforce. KPATH is on the path. Risk-tiered policy, budget enforced on the call and attributed per agent, human approval inline for high-risk actions, your guardrails run inline as a policy step. Every decision recorded. Your identity provider decides; KPATH enforces.
Stop. Kill switch for any agent or a whole chain; the chain loses the credentials it relied on and stays stopped without waiting for expiry or rollback. Behaviour watch flags out-of-pattern agents and pauses high-risk ones automatically. A containment proof shows nothing in the chain was authorised after the stop.
Prove. A signed, tamper-evident record of who acted and what was decided, streamed to your SIEM and exported to write-once storage you control. A third party can check the record offline, without trusting our console.
Start in monitor mode: observe only, enforce no policy, rewrite no agents. Run the test against what you see, then flip to enforce by repointing egress.