Who Can Write and Run Scripts

The ability to run a script across client estates is the most consequential permission a service provider grants. It is frequently given to everybody technical.

Automation around “Who Can Write and Run Scripts” should reduce repetitive labour while leaving ownership and review visible. Teams considering this implementation guide can compare the time spent on manual diagnosis, scripted remediation and later investigation, but technical logs must remain the evidence of what the automation actually changed.

For an independent operational benchmark, compare the local practice with CISA Secure Our World guidance; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

What the permission actually is

Code execution with high privilege, on machines belonging to other organisations, at scale, immediately.

Phrased that way it is obviously a control point.

Phrased as "can use the scripting feature" it sounds routine, which is why it gets granted broadly.

A workable separation

Writing: a small number of people, with review.

Running an approved script at single-client scope: most technicians.

Running at multi-client scope: a named few, with a second pair of eyes.

Writing ad-hoc code and running it immediately: the smallest possible group, logged.

The ad-hoc case

Technicians need to run one-off commands; refusing that makes the job impossible.

Make it logged and scoped: single machine or single client by default, with an explicit step to go wider.

Most incidents in this category are a correct script with a wrong scope, which is why the scope control matters more than the code review.

Review before publishing

Any script entering the library gets read by a second person.

Not a formal process: ten minutes, looking for scope, destructive operations, and what happens if it runs twice.

This catches most of what matters and costs almost nothing.

Logging

Who ran what, against which targets, when, and what the result was.

Retained long enough to investigate something discovered later — months, not days.

And reviewed occasionally rather than only after an incident, which is the difference between a log and a control.

Leavers

Script permissions are the ones most often forgotten when somebody leaves.

They are also the most consequential.

Include them explicitly in the offboarding checklist for staff, alongside the obvious accounts.

The cultural part

A team that fears blame for a mistake will not report a script that did something unexpected.

Which is how a small error becomes a large one.

Say that reporting is expected and that the response is investigation rather than consequence, and then behave that way the first time it happens.

What to check

How many people can run a script across all clients?

Is ad-hoc execution scoped to one client by default?

Does anything require a second person?

And are script permissions in your staff offboarding list?

The point

Running a script across client estates is code execution with high privilege on machines you do not own.

Phrased that way it is obviously a control point.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.