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?
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?