client can use signing to ensure that the script has not been tampered with during transit and that the script indeed originates from the vendor and not an attacker trying to social engineer an operator into running an attack script. PowerShell can be set to allow execution of otherwise blocked scripts (e.g. originating from an untrusted zone) if the script has been digitally signed using a trusted digital certificate. Multilevel execution policies A company may want to enforce execution restriction globally within the company and/or certain parts of the company. It may want to set a policy for running signed scripts but allow certain parts of the company to set their own policies for zoned restrictions. PowerShell allows script blocking policies to be enforced at multiple levels: Local machine, current user etc. A higher level policy overrides a lower level policy, e.g. if a policy is defined for the local machine it is in place for all users of the local machine, only if it is left undefined at the higher level can it be defined for the lower levels. Restricted shell subset Several shells can be started or be configured to start in a mode where only a limited set of commands and actions is available to the user. While not a security boundary (the command accessing a resource is blocked rather than the resource) this is nevertheless typically used to restrict users' actions before logging in. A restricted mode is part of the POSIX specification for shells, and most of the Linux/Unix shells support such a mode where several of the built-in commands are disabled and only external commands from a certain directory can be invoked. PowerShell supports restricted modes through session configuration files or session configurations. A session configuration file can define visible (available) cmdlets, aliases, functions, path providers and more. Safe data subset Scripts that invoke other scripts can be a security risk as they can potentially execute foreign code in the context of the user who launched the initial script. Scripts will usually be designed to exclusively include scripts from known safe locations; but in some instances, e.g. when offering the user a way to configure the environment or loading localized messages, the script may need to include other scripts/files. One way to address this risk is for the shell to offer a safe subset of commands which can be executed by an included script.