The agent's next request is the problem

An AI agent is a program that decides what to do next after reading something. That one property is what makes it useful, and it is also what puts its next network request within reach of whoever wrote the thing it read.

This was in scope from the start rather than retrofitted when it became the topic of the year. Policy here is written against identity, and identity includes non-human identities, AI agents, MCP and delegated tool execution.

Today's controls are almost all inside the agent

The controls people actually deploy are good ones: a tool allowlist that decides which functions or MCP servers the agent may call, a confirmation step before something consequential, and guardrails — usually another model reading the text. None of these is naive, and this page is not arguing against any of them.

It is pointing at one structural property they share. All three run inside the agent's own stack: the allowlist is enforced by the framework, the confirmation is rendered by the same process, and the guardrail is a model reading the same kind of input. They sit on the same side of the trust boundary as the thing being manipulated. That is not a criticism of how they are built. It is where they are.

A tool allowlist is not a reachability list

This is the concrete version, and it is the part most worth checking against your own deployment. An allowlist decides what the agent may call. It does not decide where the agent can get to.

Give an agent a shell, a code interpreter, a browser tool, or any single tool that can make an HTTP request, and its real reach is not the list — it is everything the host it runs on can reach on the network. A subprocess is not bound by the framework's policy, because the framework is not in that call path. The allowlist and the blast radius are two different sets, and only one of them is written down.

So the useful question about an agent is rarely "can it be tricked" — assume it can — but "what can it reach on the day it is". That question is answered by the network, not by the framework.

Which is what a control point outside the agent is for

The Edge does not read the agent's account of itself. It sees a flow and decides it against identity, device, posture and policy — the same way it decides every other flow, whichever framework, model or tool produced it, and whether or not that tool was on anyone's list. Egress is egress.

Prompt injection is lateral movement with a new first step

The shape is familiar. Something the attacker influences produces a next hop that nobody intended: on an endpoint it is a compromised process reaching its neighbour, and with an agent it is a poisoned document producing a request to an internal API. The stage is the same stage, and so is the answer — the next hop has to be authorised, and by default it is not.

What is actually built for this

• Non-human identity is a first-class subject (nhi, agenttool), so a policy can be written about an agent rather than about the human whose token it borrowed.
• Delegated grants are explicit, persisted and revocable (delegatedgrant). An agent acting on someone's behalf does so under a grant that exists as a record, and that record can be withdrawn.
• Step-up approval happens out of band (humanapproval). This is the one that answers the section above directly. An in-process confirmation is requested by the same stack that was manipulated; this one is not, so an attacker who controls what the agent reads does not thereby control the answer.
• Every hop between internal systems is authorised (eastwest) — including the ones an agent makes from a machine that is already inside.
• An agent that goes dark is cut off (revocation) rather than assumed to be fine because it has stopped answering.
• Every decision is audited. When an agent does something surprising, "what did it try to reach, and when" has an answer that does not depend on the agent's own account of itself.

What this does not do

It does not stop an agent from being tricked. Nothing on the network can: the trick happens inside the model's context, and by the time a request exists the persuasion has already succeeded. Anyone selling you network enforcement as a defence against prompt injection is selling you the wrong layer.

What it does is constrain what a tricked agent can reach, and record what it tried. That is the same shape as everything else on this site: one stage of the problem, named — and the neighbouring stages left to the tools that own them.