The question a buyer should ask
A CISO pitched by six vendors this quarter will hear the same words from all of them: identity, policy, guardrails, audit. The words do not separate the products. What separates them is where each product sits relative to the call and what it can do at that moment.
One question settles it. When an agent asks to move money, change a record, or call another agent, can this product refuse the call before it happens? If the answer is no, the product observes. It may observe very well. It is not an enforcement point.
Four things it has to do
The job of an agent security platform reduces to four verbs, applied to every governed call. KPATH publishes them as the Verify-Enforce-Stop-Prove test, and they work as a framework-neutral test of any vendor.
Verify
Every call must carry the identity of the agent that made it, with an owner and a risk tier, and the platform must be able to check that identity against your identity provider rather than take it on trust. When the agent acts for a person, the person must be identifiable and, for high-risk actions, verified.
Verification also covers agents you did not build. A vendor’s or partner’s agent presents its own verified identity and is checked like any other; one whose identity fails verification is refused outright.
Enforce
The decision your identity provider makes has to be applied on the call itself. That means least-privilege policy per action rather than per agent, a budget enforced on the call so the limit stops the spending instead of reporting on it, and inline human approval for high-risk actions, where the call waits until a named person signs it off.
Enforcement has to be tiered. A read-only lookup passes lightly. Anything that can move money, touch regulated data or do something irreversible clears the controls that match its risk, or it does not execute.
Stop
Agents call other agents. One request can set off a chain: an assistant calls a payments agent, which moves money. Revoking one agent leaves what it already started still running.
A platform has to be able to stop any agent, or a whole chain of agents, immediately, and keep it stopped without waiting for a credential to expire or a deployment to roll back. It should also notice when an agent starts acting out of pattern, a burst of calls, new systems, a run of refusals, a credential in the wrong place, and pause high-risk agents automatically.
Prove
Every call, decision and outcome has to land in a record that ties the action to the agent, the authority it acted under and the time. The record must be tamper-evident, so an alteration is detectable rather than invisible, and verifiable by someone who does not trust the platform’s own console.
A log you control is not evidence. If the only proof is a dashboard the vendor renders, you have a report, not a record.
What it should not do
Three things a platform should refuse to do are as telling as the four it must.
It should not read your payloads. Governing an action needs the request envelope: identity, target, action, size, delegation chain. It does not need the message body, and a platform that inspects content has become another place your data lives.
It should not hold your keys. Credentials for downstream systems should be encrypted under a key in your own vault or key service. The platform is a crypto user, not a custodian.
It should not require your agents to be rewritten. Agents keep their framework, model and prompts and make a small change to send their calls through the governed path.
The required-controls checklist
The four verbs describe the shape of the job. The required-controls checklist turns them into ten specific controls an enterprise needs before agents act on real systems:
- identity bound to principal
- least privilege per action
- budget on the call
- human approval inline
- whole-chain stop
- tamper-evident record
- monitor before enforce
- key custody stays with you
- envelope-only scope
- failure behaviour decided in advance
Each is framework-neutral and each has a pass and a fail you can test in a proof of concept. The full checklist, with what each control looks like in practice and how KPATH maps to it, is at the required-controls checklist.
Where KPATH sits
KPATH is the inline enforcement layer for enterprise AI agents. Every governed call passes through it before the payload reaches the target. It verifies the agent’s identity and the principal it acts for, enforces least-privilege policy, budgets and human approval, can stop one agent or an entire in-flight delegation chain, and records what happened in a signed, tamper-evident record streamed to your SIEM.
It works with the stack you run: identities verified against the identity provider you already have, the guardrails engine you already run applied inline as a policy step, evidence streamed to your SIEM. Self-hosted, in your VPC, on premises, air-gapped, or as a managed service.
Deploy in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress.