Agents Are For-Loops. That Is Good News for Security.

If agents were magic, we couldn’t secure them. They aren’t, so we can.

AI agents are not magic. They are workflows with probabilistic decision-making and real-world privileges. Strip away the framing and you find the classical operator feedback loop you already know from Kubernetes controllers and embedded thermostats: observe, decide, act, repeat. The only new element is that the deciding step is a language model.

This is good news, because it means twenty years of distributed-systems security applies almost unchanged. The model is the part you cannot trust; everything around it is the part you already know how to lock down.

LLMs don’t act. Tools do.

A model emits instructions. It’s the tools in the acting step that translate the model’s intent into real-world behaviour- the database write, the refund, the deployment. Which means the security boundary is not the prompt and never was. It’s the tool layer, and tool access is an authorisation problem we have mature answers for: each agent gets its own verifiable identity, each identity gets explicitly scoped grants, and everything ungrated is denied by default.

Note what this replaces. The common pattern today is one shared API key in an environment variable, used by every agent, with the real policy written in the system prompt as a polite request. A permission that exists only as an instruction to a model is not a permission. And a gateway in front of the tools helps less than it appears: a gateway secures a path, it cannot secure a workload it does not run. If the agent can reach the backing service directly, the gateway is decoration.

What a secured for-loop looks like

Identity issued per agent, short-lived and cryptographically verifiable (SPIFFE gives you the standard). Authorisation scoped per tool, per agent, enforced in the runtime. Deny-all as the starting posture, grants as deliberate exceptions. And a signed execution history, so “what did the agent do” has an answer that survives an audit rather than a log file that anyone could have edited.

There is still a weakness in this system: prompt injection against a tool the agent is legitimately granted. If the agent is allowed to send email and a poisoned document convinces the model to send the wrong one, identity and authorisation did their job and the damage still happened. No infrastructure makes a model trustworthy. What infrastructure can do is keep the set of things a misbehaving model can reach small- which turns a catastrophe into an incident.

The deeper treatments: Agent Identity: The Foundational Layer AI Is Still Missing and Why MCP Gateways Are Not Enough.