@poddingue
Thanks - great question, and the answer is simpler than you might expect.
Every tool in the catalog is classified right in its description: read, write, admin, dangerous. That classification ships with the DADL itself - nobody has to sort 267 endpoints by hand before letting an agent near them.
From there it is a ladder:
Each agent (or user) gets a maximum access level. Our reviewing agent is capped at "read" - so a VDI delete is not blocked with a warning, it is simply not on the table. And this holds even though the gateway itself holds an admin token towards XO: the agent's reach ends at the classification, not at the token. The model cannot talk its way past a label.
Exceptions are a one-line override: "read-only, but snapshot_vm is allowed" - or the other direction, "writes allowed, but nothing classified dangerous".
For the fine-grained cases - "read-only, except never touch this one VM" for example - there are policies that can filter on parameters, not just functions.
Underneath it all, one rule: fail-closed. If any check cannot complete, the call does not run.
The detail we find most underrated: refused attempts are logged as first-class events. A reviewing agent that suddenly asks for a delete is not a near-miss - it is a signal, because it usually means the model read something it should not have trusted. Which is your Insights piece's "boundaries drawn in advance", applied literally.
Happy to go deeper on any of this - the boundary question is exactly what the gateway exists for.
