Security · updated 19 October 2026
How PowerScripts keeps admin rights where they belong
PowerScripts lets the help desk run approved PowerShell without holding admin rights. The rights stay with a service account on your server; people get a form for the scripts you grant them, and every run is recorded.
Who can do what
- The service account holds the rights, not the person. A help desk operator can add a mailbox delegate without being an Exchange admin, and never sees the credentials the script runs with.
- Running a script needs a grant, to the person or to an Entra ID or Active Directory group. Scripts you haven't been granted don't appear at all.
- Roles combine: Admin, Script Author, Script Operator, Observer, Configurator and User Manager. Observers and auditors see every run and can run nothing.
- Only the people who maintain scripts see their code. Operators see a form.
- Denied attempts are logged, not just successful runs.
Watch: the help desk is refused Domain Admins, the auditor sees everything and runs nothing (1:43)
Every run leaves a record
- Who ran it, against which target, with which inputs, the full output, the start time and status, and the Git commit of the exact code that ran.
- Secret parameters are masked in the record.
- You can require a ticket number before a script runs, so each change ties back to a request.
- The history is searchable down to the output text, and a run can be reversed where the script declares its opposite.
How a run is contained
- Each run starts its own PowerShell 7 process. When it ends, PowerScripts disconnects every session and stops the process, so nothing carries over between runs or people.
- A readiness check connects to the target and confirms the script's cmdlets are available without running it.
- The Exchange Online, Microsoft Graph, Teams and PnP modules ship inside the package, so the server doesn't download code from PowerShell Gallery at run time.
Sign-in and the web app
- Sign in with Microsoft Entra ID single sign-on, Active Directory domain passwords, or local accounts.
- There is no default password. First-run setup asks you to create the first admin.
- HTTPS uses your own certificate from the machine store, by thumbprint. The service refuses to start if it can't find it.
Connections to your tenants and servers
- Microsoft 365 uses app-only authentication with a certificate or a client secret. A generated setup script creates the Entra app registration and grants the permissions you choose to include. We recommend a certificate.
- On-premises targets such as Active Directory and Exchange each use their own service account, so you can scope each one to what its scripts need.
Where your data lives
- Scripts, settings, run history and stored credentials live on your server: one local database file and a local Git repository. No SQL Server, IIS or containers.
- We never receive your scripts, run output or credentials. The only things the product sends us are listed on the privacy page: registration details at install and trial start, and version numbers and a run count at update.
- Treat the PowerScripts server and its backups like any server that holds service-account credentials: limit who has local admin on it, and protect its disk and backups.
Updates
- The updater checks the package hash before installing, keeps the previous version, and rolls back automatically if the new one doesn't answer. Your data isn't touched.
- Catalog script updates never overwrite your own edited copies.
Reporting a security issue
Email sales@powerscripts365.com with "Security" in the subject. We will confirm we have it and keep you updated until it is fixed.