The framing that failures with different surfaces share the same underlying causes matches what I keep finding on the seller side. I run pay per call endpoints, and every incident traces back to a boundary nobody wrote down: what this caller may spend, call, or change. The isolation list is useful because it makes those unwritten limits enumerable.
Thanks for the shoutout, Chris! I love the 5 boundary framing. Certainly helps simplify and visualize things.
When we put together the OWASP ASI Top 10, we organized it around what the defender experiences instead of where isolation breaks. It's the right call for that audience, I think, because nobody opens a ticket that says "loss of isolation at the agent-tool interface." They say the agent "went rogue".
In my own "dirty mapping" of the top ten onto the five boundaries, most of them fit somewhere. Two don't.
ASI09 is Human-Agent Trust Exploitation, and there's no interface to isolate. The agent did exactly what it was built to do, and a person believed it more than they should have. You can sandbox the runtime all day, and that failure still lands, because it happened in someone's head.
Rogue Agents, ASI10, is stranger. You don't catch it at an interface. You find it months later, usually because whoever stood the thing up moved teams and nobody inherited it.
So where does trust calibration live in a boundary model? Maybe it doesn't, and maybe that's fine...
I need to drop a short note here on ASI09: Exploitation presumes intent andanthropomorphizes behavior that is neither intentional nor exploitative. It is entrained.
The agent-execution boundary is the one I'd have teams start with. Refusal training that holds up in a chat box falls apart once the same model is clicking buttons and submitting forms. So the control has to live in the runtime, not the prompt, where an unsafe decision can still get blocked before it turns into an action. How are you seeing teams draw the line between the model that decides and the runtime that acts?
I think the critical boundary is not model versus runtime, but proposed action versus authorised execution.
The model can propose and assemble an action, but it cannot create or widen the mandate to execute it.
We are putting that control in the runtime, not the prompt. Before an action reaches the commit point, an independent runtime enforcement control outside the model checks the exact proposed consequence against authority already established by the organisation: the permitted action, purpose, resource, destination, route, limits, and current state and conditions.
That is different from simply asking whether the model has tool access or whether its service identity is valid. Access provides capability. It does not establish that this particular action is authorised.
The boundary is proposed action on one side and authorised execution on the other. The model remains free to reason and adapt, but it cannot convert its own decision into authority to act.
The framing that failures with different surfaces share the same underlying causes matches what I keep finding on the seller side. I run pay per call endpoints, and every incident traces back to a boundary nobody wrote down: what this caller may spend, call, or change. The isolation list is useful because it makes those unwritten limits enumerable.
Thanks for the shoutout, Chris! I love the 5 boundary framing. Certainly helps simplify and visualize things.
When we put together the OWASP ASI Top 10, we organized it around what the defender experiences instead of where isolation breaks. It's the right call for that audience, I think, because nobody opens a ticket that says "loss of isolation at the agent-tool interface." They say the agent "went rogue".
In my own "dirty mapping" of the top ten onto the five boundaries, most of them fit somewhere. Two don't.
ASI09 is Human-Agent Trust Exploitation, and there's no interface to isolate. The agent did exactly what it was built to do, and a person believed it more than they should have. You can sandbox the runtime all day, and that failure still lands, because it happened in someone's head.
Rogue Agents, ASI10, is stranger. You don't catch it at an interface. You find it months later, usually because whoever stood the thing up moved teams and nobody inherited it.
So where does trust calibration live in a boundary model? Maybe it doesn't, and maybe that's fine...
I need to drop a short note here on ASI09: Exploitation presumes intent andanthropomorphizes behavior that is neither intentional nor exploitative. It is entrained.
The agent-execution boundary is the one I'd have teams start with. Refusal training that holds up in a chat box falls apart once the same model is clicking buttons and submitting forms. So the control has to live in the runtime, not the prompt, where an unsafe decision can still get blocked before it turns into an action. How are you seeing teams draw the line between the model that decides and the runtime that acts?
I think the critical boundary is not model versus runtime, but proposed action versus authorised execution.
The model can propose and assemble an action, but it cannot create or widen the mandate to execute it.
We are putting that control in the runtime, not the prompt. Before an action reaches the commit point, an independent runtime enforcement control outside the model checks the exact proposed consequence against authority already established by the organisation: the permitted action, purpose, resource, destination, route, limits, and current state and conditions.
That is different from simply asking whether the model has tool access or whether its service identity is valid. Access provides capability. It does not establish that this particular action is authorised.
The boundary is proposed action on one side and authorised execution on the other. The model remains free to reason and adapt, but it cannot convert its own decision into authority to act.