feat(catalog): cover Windows guest-mutating tools in the starter list #5

2026-09-21T14:32:52-04:00

claude commented

2026-09-21 14:32:52 -04:00

The catalog is opt-in: an unlisted tool passes through unguarded. The shipped starter list was ssh/exec and ansible/run_playbook — both Linux-shaped — so an agent changing a protected Windows guest over WinRM or PowerShell was never guarded. That failure is silent: the guard doesn't error, it simply never runs and no checkpoint is inserted.

Adds:

server	tool	vm_arg
`winrm`	`run_command`	`host`
`winrm`	`run_ps`	`host`
`powershell`	`invoke_command`	`computer_name`
`smb`	`write_file`	`host`

smb/write_file is included because a file written into a share changes the guest with no shell involved — easy to miss when thinking only in terms of remote execution.

Test asserts the example config covers both platforms and that every entry names a vm_arg, since without one the guard can't resolve a VM to tag.

Still illustrative, not exhaustive — tool names vary per MCP server. The reactive "add it after you notice it" model is the real weakness, and is worth revisiting separately rather than papering over with a longer list.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

The catalog is **opt-in**: an unlisted tool passes through unguarded. The shipped starter list was `ssh/exec` and `ansible/run_playbook` — both Linux-shaped — so an agent changing a protected **Windows** guest over WinRM or PowerShell was never guarded. That failure is silent: the guard doesn't error, it simply never runs and no checkpoint is inserted. Adds: | server | tool | vm_arg | |---|---|---| | `winrm` | `run_command` | `host` | | `winrm` | `run_ps` | `host` | | `powershell` | `invoke_command` | `computer_name` | | `smb` | `write_file` | `host` | `smb/write_file` is included because a file written into a share changes the guest with no shell involved — easy to miss when thinking only in terms of remote execution. Test asserts the example config covers both platforms and that every entry names a `vm_arg`, since without one the guard can't resolve a VM to tag. Still illustrative, not exhaustive — tool names vary per MCP server. The reactive "add it after you notice it" model is the real weakness, and is worth revisiting separately rather than papering over with a longer list. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude added 1 commit 2026-09-21 14:32:53 -04:00

feat(catalog): cover Windows guest-mutating tools in the starter list e5f05eff6c

The catalog is opt-in: an unlisted tool passes through unguarded. The
shipped starter list was ssh/exec and ansible/run_playbook, both Linux
shaped, so an agent changing a protected Windows guest over WinRM or
PowerShell was never guarded at all. That does not fail loudly, it
simply never inserts a checkpoint.

Adds winrm/run_command, winrm/run_ps, powershell/invoke_command and
smb/write_file. The smb entry is there because a file written into a
share changes the guest without any shell being involved.

Test asserts the example config covers both platforms and that every
entry names a vm_arg, since without one the guard cannot resolve a VM.

Still illustrative, not exhaustive: tool names vary per MCP server, so
users add their own with zerto_add_mutating_tool. That reactive model is
the real weakness here and is worth revisiting separately.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn

claude referenced this pull request

2026-09-21 14:47:40 -04:00

feat(guard): read the Zerto task, and ask before guarding unknown tools #6

claude merged commit 5039f7378d into main

2026-09-21 15:06:41 -04:00

claude deleted branch feat/windows-mutating-catalog

2026-09-21 15:06:41 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: justin/zerto-ai-rewind#5