DSC File resource lacks explicit permission boundary for remote file system access

PowerShell Desired State Configuration provisions repeatable developer workstations, and the File resource routinely writes configuration files to local or remote targets through UNC paths or CIM sessions. The goal is to restrict those file operations to a least-privilege boundary without relying entirely on operating-system ACLs or custom wrapper scripts.

The uncertainty is that the DSC engine does not impose an explicit permission boundary on the File resource. It runs under the Local System account or whatever credentials the engine receives, and neither Constrained Language Mode nor JEA endpoint restrictions are automatically applied to the underlying file system calls. This leaves an unresolved design question about whether DSC should enforce JEA-style constraints natively or require explicit delegation credentials, with behavior that can vary between PowerShell versions and deployment scenarios.

Which explicit permission boundary should administrators configure for the DSC File resource when targeting remote paths, and does the DSC engine apply any built-in sandbox or Constrained Language Mode limits to file system operations in current supported PowerShell releases?