What zero trust already says
NIST’s zero trust architecture, SP 800-207, starts from one assumption: no asset or account is trusted because of where it sits on the network. Every request is evaluated against policy before access is granted. The same document separates two jobs. A policy decision point decides whether a request should be allowed. A policy enforcement point sits on the path and carries that decision out.
The UK’s National Cyber Security Centre says much the same in its design principles, starting with “know your architecture, including users, devices, services and data”, then using policies to authorise requests and authenticating and authorising everywhere.
Most teams summarise it as three principles: never trust, always verify; least privilege; assume breach. None of that changes when agents arrive.
What changes when the caller is an agent
Zero trust programmes were built around people and the devices and services they use. An agent is a different kind of subject, in four ways.
It calls systems on its own, many times a minute, with nobody watching each call. It usually acts for someone else, a customer, an employee or another system, so a request often carries two identities: the agent’s and the one it acts for. It hands work to other agents, so one request can become a chain of calls across systems nobody planned together. And it can be talked into things. An instruction hidden in a document, a web page or a tool result can change what it does next.
A check at login, or a role granted once at onboarding, does not cover any of that. The decision has to be made on each call the agent makes.
The three principles, applied to agents
| Principle | What it asks of an agent estate | Where KPATH does it |
|---|---|---|
| Never trust, always verify | Every call carries the agent’s own identity, with an owner and a risk tier, and, when it acts for a person or system, their identity too. Nothing is allowed because of where the call came from. | Identity on every call |
| Least privilege | Policy is written for this agent, this action and this target. An agent never inherits the permissions of the person who started it, and never holds the credentials of the systems it reaches. | Policy per action |
| Assume breach | Plan for an agent being turned. Limit what any one agent can reach, stop it or its whole chain the moment something looks wrong, and keep a record that shows what happened. | Whole-chain stop and audit evidence |
Where the enforcement point has to sit
Firewalls and network segmentation contain zones and applications. They were never designed to contain an individual agent, because the agent’s calls look like any other well-formed request to an approved service.
Controls built into the agent itself, in its code, its framework or its system prompt, sit inside the thing you are trying to control. Whatever manipulated the agent can reach them too.
So the enforcement point for agents belongs on the path of the call, outside the agent, where every call has to pass and the agent cannot change the rules. Your identity provider stays the policy decision point. The enforcement point acts on its decision at the moment the agent calls.
Content inspection is one layer, not the whole answer
Much of the writing on AI security focuses on what a prompt says, and for good reason. Prompt injection hides instructions in content, and guardrails that inspect content catch some of it.
But a guardrail cannot know who is calling, what that caller is allowed to reach, or what the rest of the chain has already done. Assume breach means planning for the injection that gets through. When it does, the call should still meet a decision about identity, authority and scope before it reaches a system, and the stop should reach every agent the compromised one set in motion.
KPATH runs the guardrail you already chose as a policy step on the call, and makes the identity and scope decision alongside it. It governs the request envelope and does not read your payload itself.
What stays the same
Agent controls are additive. Your firewalls, web application firewalls, segmentation, identity provider and SIEM all keep their jobs. What they were not built to do is decide, on each call, whether this agent may take this action for this person, and stop the whole chain if not. That is the gap an agent enforcement point fills.
For the risks this addresses in OWASP’s terms, see KPATH and the OWASP Top 10 for Agentic Applications.