We wrote a white paper. It is out today: you can read it here or download the PDF.
Why write one at all? Mostly because we kept having the same conversation. Someone asks what makes an AI agent dangerous, and the answer tends to arrive as a list — prompt injection, data leakage, rogue tool calls, hallucination — with no particular structure to it, and no way to tell which parts are genuinely new and which we have been solving for decades. We wanted to write down the structure we have been using ourselves, plainly enough that it is useful to someone with no intention of ever buying anything from us.
So the paper tries to explain the field rather than sell into it: what agents actually are, how they are built, why they are and are not different from the software you already run, and what the full menu of approaches to securing them looks like — isolation, access control, prompting, gateways, guardrails, runtime enforcement — with what each does well and where each stops. Every claim about our own product sits in a clearly marked box. Skip all of them and the map should still be worth having.
The argument, briefly
Most of what makes agents dangerous is old. A single destructive action — dropping a table, wiring a payment that should not have been wired — is a problem we have had for as long as we have had software, and we have mature controls for it: permissions, least privilege, approvals, isolation. Agents inherit those problems, and the same controls still apply.
Content is the second danger. The text flowing into and out of the model can be harmful in itself: a secret in an outbound message, or a malicious instruction hidden in a document the agent reads and then obeys. That is the prompt-injection family, and per-step checks — guardrails — are the natural defence.
What is new is the path: the sequence of individually-permitted actions an agent strings together at run time. An agent reads a customer record it is allowed to read, then sends a message it is allowed to send. Each step passes every check that looks at it. The combination is an exfiltration that neither permission, on its own, forbids.
Every stateless control misses this by construction, and not because the tooling is immature. Identity sees one action and one resource. A content filter sees one message at a time. Neither holds the history of the task, so neither can evaluate a step in light of what the agent has already done. That, as far as we can tell, is the one genuinely new thing agents add — and it is what most of the paper is about.
Thanks
The paper is a good deal better for the people who argued with it. Our thanks to Jeroen Janssen (Belastingdienst), Andriy Podstavnychy (Arcadis), Bart Jansen (ING), Rob Guikers (Rabobank), Niels Tailleur (Datashift) and Koko Visser (Valcon), amongst others, whose feedback changed real arguments rather than just wording.
If you disagree with the central claim — that the path is the right object of governance — that is the discussion we would most like to have.