Treating the model as an untrusted but capable dependency is the right starting point. Nobody would give a third party library root access because its documentation was impressive, and the same logic applies to an agent with tools.
The six parts of the control layer you describe are familiar engineering, which is the reassuring point. Least privilege, short lived credentials, change approval, logs, isolation and rollback are all things teams already know how to build. What changes is that they have to be decided before the agent goes live, not added after the first mistake.
Starting agents read only and granting write access one system at a time is the practice I would recommend to any business adding agents to real operations. It also gives a natural milestone structure for a build: each new write permission is a defined step with its own test.
Showing the full outbound payload before anything is sent is a simple rule that prevents most of the embarrassing failures.
Martin Kraus
Founder & Editor at delavo.de | Freelance Product Owner & IT Consultant
Read-only-first with permission-denied by design is a sensible default, because it changes the question from "what can the agent do" to "what has it been explicitly allowed to do". In my view the practical test is how write access gets added later: one narrow, logged grant per workflow is much easier to review than a broad role. The glass-house idea supports that, since a readable record of every action is what makes a grant revocable in practice.