When building is the right answer
Most teams that ask this question should build, at least at first. If you have a handful of agents, all on one framework, reaching a few internal services, and the worst a bad call can do is a wasted afternoon, then the gateway you already run can carry the controls you need. Give each agent a client credential, allow-list its targets, rate limit it, write its calls to the log you already keep, and put a kill switch behind a feature flag. That is a week of work for one engineer and it is proportionate to the risk.
We would rather say this early than sell an enforcement layer to an estate that does not need one. KPATH earns its place when all three conditions below hold together, and not before.
The point at which it stops being enough
Three conditions, taken together, are the signal.
Many-to-many. Dozens or hundreds of services with a growing agent population that needs to reach them, where hard-wiring every agent-to-service pair has stopped being practical. Allow-lists that were a config file become a directory, and the directory needs policy of its own.
Multi-framework. Different teams building on different agent frameworks, with no single message format and no common way of calling things. The scripts you wrote for one framework do not apply to the next, and the controls drift apart as each team moves at its own pace.
High stakes. Agent actions that touch regulated data or money, where someone will eventually ask which agent did this, on whose authority, and prove it. A log that the same team can edit does not answer that question. A log you control is not evidence.
Any one of these can be handled by hand. All three together is the point at which running agents safely without an enforcement point stops being realistic, because the work moves from writing controls to proving them across a surface that no single team owns.
What a built gateway usually does not do
A gateway plus scripts handles identity, allow-lists, rate limits and logging well. The Verify-Enforce-Stop-Prove test asks four things that tend to be left out, because each is a project in itself.
| Question | What a script-based gateway usually has | What passes the test |
|---|---|---|
| Verify | A client credential per agent | Workload identity verified by the identity provider, with an owner and a risk tier; the human principal verified where policy demands |
| Enforce | Allow-lists and rate limits | Risk-tiered policy, budget enforced on the call, human approval inline for high-risk actions |
| Stop | Revoke one credential | Stop one agent or a whole in-flight chain, and the chain loses the credentials it relied on |
| Prove | A log in the team’s own store | A signed, tamper-evident record an auditor can verify without trusting the operator |
Chains are the case that breaks most built gateways. Revoking one agent leaves whatever it started still running. Stopping the chain means knowing the chain existed, which means carrying the delegation chain in every request from the start.
Cost of ownership, as categories
We will not invent numbers. The categories are the same whichever way you go, and they are listed in the order most teams underestimate them.
- Initial engineering. The proxy, the policy checks, the log. This is the part everyone budgets for and it is the smallest.
- Identity integration. Issuing workload identities, binding agents to owners and risk tiers, verifying the human principal, and handling credentials so agents never hold them. Every identity provider change lands here.
- Policy authoring and maintenance. One policy language across frameworks, tested and versioned, with human approval steps that do not stall real work. This grows with the number of teams.
- Evidence. A record an auditor accepts: tamper-evident, exported to write-once storage, verifiable without trusting the people who run it. Building this once is hard; keeping it credible through upgrades is the ongoing cost.
- Containment and incident response. A kill switch that stops chains, a way to prove nothing was authorised after the stop, and the runbooks around it.
- Operations. Redundant enforcement points, a decided failure mode, on-call, upgrades, and the drift cost as each framework, model provider and protocol changes underneath you.
A vendor moves the first, fourth and fifth categories off your team and shares the second and third. It does not remove the sixth, and it adds licence cost and a dependency. Whether that trade is worth it depends on the three conditions above and nothing else.
How to decide without committing
Run the estate in monitor mode before you decide. KPATH’s monitor mode observes only, enforces no policy and rewrites no agents; the inventory fills in from real calls, including agents nobody registered, and no policy is enforced until you switch. If the estate you see is small, on one framework and low stakes, keep your gateway and your scripts. If it is many-to-many, multi-framework and high stakes, you now have the evidence for the buy decision and a policy draft written against how the agents actually behave.
Flip to enforce by repointing egress.