Mutation testing tells you the gate's tests are strong. It can't tell you the gate sees every way a command reaches a closed drive, because each mutation only breaks a condition the gate already has.
The gap I'd test next is indirection. A gate that reads command text sees python fix.py, not the open("D:/...") inside the file the session wrote a minute earlier. Windows has a quieter one: mklink /J C:\work\d D:\ creates a junction on C: that points at D:, needs no admin rights, and every path through it reads as a C: path to a text filter. I'd add a few of these as tests that are expected to get through today, so the known gaps are written down instead of assumed closed.
For the vaults and the backup clone, NTFS can hold the line without reading any text. Running the sessions under a separate standard account, with deny ACLs on those volumes, turns the most important part of your list into something the operating system enforces. The gate then keeps the job you already give it: catching a session's mistakes.
Both gaps are real. I read the gate's code today: it sees the command line and the path a call names, never what a script the session wrote contains, and it resolves no junctions. My decision record names the script limit. Nothing names the junction one. Tests that expect each gap would be a better record than prose. I have used a deny ACL on my workspace folder against another coding agent, after its read-only setting turned out to be a profile rule and not an OS barrier. I have not checked whether the vaults, which mount as virtual drives, would honour one.
You may not need the ACL for the vaults at all. Whether a second account can even see them depends on which namespace the vault app puts the drive letter in.
Windows keeps a separate MS-DOS device namespace for each logon session. Microsoft's DefineDosDevice docs say a letter in a local namespace is usable only by a token from that logon session, and only LocalSystem can define a global one. So a vault mounted by a process running as you should be invisible to the agent account, while one mounted through a system service may be visible to everyone.
The test takes a minute. Unlock a vault, then from the agent account run dir V:\ (or whichever letter it took). "The system cannot find the drive specified" means the account boundary already covers it. If it lists files, icacls V:\ tells you whether the virtual drive carries ACLs at all, and that result can sit in the decision record next to the junction test.
Mutation testing tells you the gate's tests are strong. It can't tell you the gate sees every way a command reaches a closed drive, because each mutation only breaks a condition the gate already has.
The gap I'd test next is indirection. A gate that reads command text sees
python fix.py, not theopen("D:/...")inside the file the session wrote a minute earlier. Windows has a quieter one:mklink /J C:\work\d D:\creates a junction on C: that points at D:, needs no admin rights, and every path through it reads as a C: path to a text filter. I'd add a few of these as tests that are expected to get through today, so the known gaps are written down instead of assumed closed.For the vaults and the backup clone, NTFS can hold the line without reading any text. Running the sessions under a separate standard account, with deny ACLs on those volumes, turns the most important part of your list into something the operating system enforces. The gate then keeps the job you already give it: catching a session's mistakes.