Least privilege, per agent
A procurement agent that reaches for a treasury transfer is refused at the call. A claims agent cannot touch payroll. Each agent reaches the systems its job needs and is refused everything else. That is the whole of least privilege, applied to non-human callers, and KPATH applies it on every request rather than once at onboarding.
Two things make it hold. Agents carry no system addresses and no credentials, so there is no way to reach a system by going around KPATH. The decision is also made outside the agent, on the path its calls have to travel, so a hijacked agent cannot decide its own permissions.
This is the Enforce step of the Verify-Enforce-Stop-Prove test.
Where the decision comes from
Your identity provider is the policy decision point: it issues agent identities and decides what should be allowed. KPATH is the policy enforcement point: it acts on that decision at the moment an agent makes a call. Your identity provider decides. KPATH enforces.
Risk tiers drive strictness
Every agent identity carries a risk tier, and the tier drives how strictly the agent is treated. High-risk agents face tighter rules than low-risk ones, rather than one flat ruleset for everything.
| Control | Low-risk agent | High-risk agent |
|---|---|---|
| Identity | Verified agent identity | Can be required to present a workload identity your identity provider verifies |
| Acting for a person | Person named | Policy can insist the person is verified |
| Sensitive actions | Routine actions go straight through | Stop and wait for a named person |
| Guardrail | Runs as policy sets | Runs, scaled to tier, verdict recorded |
| Out-of-pattern behaviour | Flagged | Paused automatically |
What is checked on every call
Identity, budget, policy and human approval are checked on every request, not signed off once at onboarding. KPATH checks that the agent’s verified identity, owner and risk tier are what policy expects, that this agent may take this action against this target, that the spend limit has room for the call, that any person the action requires has approved it, and that your guardrail passes the request.
A call that fails any check is refused and the refusal is recorded. Only a call that passes every check is given the real credential for the target system.
Human approval, inline
Some actions should never be an agent’s alone: moving money, blocking a card, filing with a regulator, releasing a hold. Policy can make any such action wait for a named person. The wait happens inline at the call rather than in a review after the fact, so the action does not occur until the approver signs it off, and the approval is captured against the call it released.
Routine actions go straight through. A person is required where the stakes demand one and nowhere else.
The request goes to the people who can decide it, where they already work: Slack, Microsoft Teams, ServiceNow, Jira or the KPATH console. Policy names who may approve, how many approvers an action needs and whether they must come from different teams. Two exclusions always apply: the person who registered the agent, and anyone on the team that owns it, can never approve its requests. Who could approve is fixed when the request opens, so a later change of ownership cannot clear the way. A request nobody answers escalates to the next group, and one that runs out of time expires. The agent is told the outcome.
Slack
Microsoft Teams
Jira
Limits on the amount
A transfer of ten pounds and a transfer of ten million are the same call to most controls: the same agent, the same action, the same endpoint. The difference is a number inside the request.
KPATH policy can read that number. Rules set brackets on it: below one line the call goes through, above it a person decides, beyond another it is refused outright. Currencies can be named, so a limit written in pounds is not applied to a request in yen. When a call is refused, the record names the limit it crossed.
KPATH proposes which fields carry the amounts, from the tool descriptions and API documents it already holds and from the shape of requests it has seen. It proposes and a person confirms. Nothing is adopted automatically, because a field carrying pence mistaken for pounds would put a limit out by a factor of a hundred.
Budget as a policy check
A team’s spend limit can be enforced on the call itself, so the budget stops the spending instead of reporting on it afterwards. Spend is attributed to each agent either way and rolled up to the request that started the chain. Budgets are covered in detail on the budgets page.
Your guardrails, as a policy step
Content inspection catches prompt injection and unsafe payloads, but a guardrail does not know who is calling. KPATH invokes your guardrail inline as a policy step, scaled to the agent’s risk tier, so identity and content safety land as one enforced decision. Every verdict is recorded.
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 guardrail you already run does the content work, and if you host it yourself, the content it inspects never leaves your boundary.
A prompt is not a control
Most agent frameworks let you write the rules into the agent. An agent’s instructions can say never release a sanctions hit. A prompt injection can rewrite those instructions. KPATH enforces the limit on the call itself, outside the agent, so it holds whatever the agent has been talked into. It also covers agents other teams and outside vendors built, which self-governance never will.