Agent security: instructions are the weakest control
Securing an agent is difficult for two reasons that compound. Its inputs are untrusted text, which may contain instructions aimed at the system rather than information for it, and the agent has no reliable way to tell the difference between content it should reason about and content it should obey. And its behaviour cannot be enumerated in advance, so there is no complete list of what it might do to check against. The response that comes naturally is to write instructions: tell the system what it must not do. That is the weakest control available, because it depends on correct interpretation in exactly the situations nobody anticipated. The controls that hold are structural. Restricting the credential the agent runs under constrains it regardless of what it reasons its way to, and that distinction between a control and a hope is the whole subject.
Permissions are the ceiling on any bad run
Whatever else is done, the worst outcome of a misbehaving agent is bounded by what its identity is allowed to do. An agent with read-only access to a database cannot delete a record, cannot be talked into deleting a record, and cannot be tricked into it by a document containing clever text.
The practical rule is one identity per agent, scoped to the minimum that agent needs, rather than a shared service account with broad access because it was convenient. The convenient arrangement is the one that makes an incident unbounded.
Where the agent acts on behalf of a user, it should carry that user's permissions rather than its own. A system that retrieves everything and filters the results afterwards will eventually show somebody something they should not see, and it will do so in a way that looks like the system working correctly.
Treat retrieved content as hostile
Anything the agent reads may contain text written to redirect it: a document, an email, a page it fetched, a record a customer filled in. This is not a hypothetical class of attack, it is the natural consequence of a system that takes instructions in the same channel as data.
There is no complete defence at the model layer, which is why the useful measures are around it. Content from outside the trust boundary should be clearly demarcated when it reaches the model. Actions triggered by reasoning over untrusted content should be the most tightly constrained. And anything the agent does after reading external content deserves closer logging than anything it does before.
The design question worth asking early is which content sources are trusted and which are not, written down. Teams that have never drawn that line treat everything as trusted by default, which is the state most systems ship in.
The four controls that actually work
Scoped credentials. Covered above, and the foundation for the rest.
A hard step cap. Prevents the run that explores indefinitely, and bounds both the damage and the bill. It should sit well above normal operation and alert when it fires.
Human approval on irreversible actions. Not on everything, which produces approval fatigue and people clicking yes without reading. The line is reversibility: send, delete, transfer, publish and commit are on one side, and almost everything else is on the other.
Logging with the reasoning attached. The only way to answer why it did that, which is the question asked after an incident. A log of actions without the context that produced them turns a review into guesswork.
The drift that produces most incidents
Few agent security problems begin as a security decision. They begin as a feature. A system that read and summarised acquires a tool that files a ticket, then one that updates a record, then one that sends a message. Each addition is small, each was requested by a user, and none of them triggered a review.
By the time anyone looks, the permissions are wide, the approval flow was designed for a system whose worst outcome was a bad sentence, and the logging retains actions without the reasoning behind them. Nothing was done carelessly and the result is the same as if it had been.
The cheap prevention is a rule rather than a process: adding a tool that writes anything requires the three written items below to be updated first. It takes ten minutes and it is the only mechanism that reliably catches the transition from a system that suggests to a system that acts.
What to write down before an agent ships
Three things, none of them long. What the agent is permitted to do, expressed as the permissions of its identity rather than as prose. Which of those actions cannot be undone. And who approved that boundary, with a date.
That last item sounds bureaucratic and is the one that cannot be reconstructed afterwards. When something goes wrong, the honest answer to who decided this agent could write to that system is either a name and a date or nothing at all, and nothing is a bad answer to give.
Published governance expectations are moving in this direction: Singapore extended its framework to agentic systems from January 2026, and the risk-based regimes in Europe and South Korea ask variations of the same questions. Writing the record during the build is close to free. Assembling it under pressure, later, is not, and the result reads exactly like what it is. More on that on our governance page.
