Two ways to scale your scripts

Author: Alexander Ivanyuk, Senior Director, Technology

Every script you run on a customer endpoint is operational software with administrator privileges. It deserves the same lifecycle discipline you would apply to any other production code — review, attribution, versioning and retirement. NIST SP 800-53 controls CM-7 (Least Functionality) and SI-7 (Software Integrity) make this expectation explicit; CIS Critical Security Controls v8 Control 16 makes it practical at SMB and MSP scale. Whether a script was written by a senior engineer last Tuesday, cloned from a vendor template or generated by AI, the standards expectation is identical.

The customer base scales operational scripting in two distinct ways:

• Strategy A — Reuse: Clone trusted Acronis-shipped templates. Of all active scripts on the platform, about 38.9% are clones of an existing source, and a small set of Acronis built-in scripts — six of them, each cloned by 500 or more distinct tenants — now generates about 32.5% of all clone copies. The single most-replicated source is present in roughly 6.8% of all script-using tenants.

• Strategy B — Generate: Use AI to write new scripts. About 15.6% of active scripts are AI-generated, and an aggressive minority of tenants — about 13.9% of classified script-using tenants — writes most of their scripts that way.

The regional picture frames the decision. Three patterns are visible across the top markets by classified-tenant count: AI-origination markets (Brazil, Mexico, Italy, France, South Africa, Botswana, Colombia, India and others) lean into AI generation and clone little inside that cohort; AI-augmentation markets (Australia, Singapore, the United Kingdom) use AI but keep cloning heavily alongside it; cloning-dominant markets (Spain, Denmark, Austria, Switzerland) stay with established templates. None is wrong; each requires a different control posture.

Key takeaways:

• Cross-tenant reuse is concentrated: Six Acronis built-in scripts, each used by 500+ distinct tenants, generate about 32.5% of the platform's clone copies; the top 28 templates account for about 69.5%. The most-replicated single template reaches about 6.8% of all script-using tenants.

• About 15.6% of active scripts are AI-generated: The AI-heavy cohort is about 13.9% of classified script-using tenants, and inside that cohort about 74.4% of every script is AI generated.

• Substitution is real: Average clone share is about 26.5% in AI-heavy tenants, 41.7% in AI-mixed, and 55.9% in no-AI tenants. AI tenants substitute generation for cloning rather than layering one on top of the other.

Scripts run with the privileges of the account that launched them. On a managed endpoint that is usually administrative — enough to read any file, change any setting, install or remove software or persist a foothold. Every script is therefore trusted-by-default software, and every modern standard treats it as such regardless of where it came from.

NIST SP 800-53 Rev. 5 control CM-7 (Least Functionality) requires that systems run only the functions necessary for their mission — for an SMB or MSP, a curated and reviewed set of operational scripts, not whatever a technician forwarded from a forum thread. Control SI-7 (Software, Firmware and Information Integrity) requires verification of software integrity before execution; cloned and AI-generated scripts both qualify as software under it.

NIST AI Risk Management Framework 1.0 is the dedicated guidance for AI-generated artefacts. Its four functions — Govern, Map, Measure, Manage — describe how to keep AI-augmented operations accountable: Know what AI is producing, how it is used, and how to roll back when it goes wrong. ENISA's Multilayer Framework for Good Cybersecurity Practices for AI is the European parallel, treating AI-generated operational artefacts as requiring data-quality, transparency and human-oversight controls beyond a hand-authored equivalent.

CIS Critical Security Controls v8 translates the same principles into a practical checklist: Control 4 (Secure Configuration) treats scripts as configuration; Control 16 (Application Software Security) treats them as software with a lifecycle. OWASP secure-coding and configuration-as-code guidance is the open practitioner reference for input validation, error handling, secrets management and reproducibility. The point is not that scripts are uniquely dangerous; it is that the discipline modern frameworks expect of any operational software applies to scripts regardless of authorship.

Cloning is the older and broader scaling pattern. A tenant copies an existing script — its own or a vendor's — modifies it where needed and runs it. The platform records this, which lets us measure how scripts travel across tenants. The table below groups source scripts by how many distinct tenants cloned them.

Button

Button

The distribution is steeply concentrated. The chart below plots the cumulative share of clone copies against the cumulative share of source scripts, most-cloned first.

Button

Button

Six Acronis built-in platform-catalog scripts are each cloned by 500 or more distinct tenants. Together they generate about 32.5% of every clone copy on the platform, and the single most-replicated source is present in roughly 6.8% of all script-using tenants. Together with the next band down (100–499 tenants), a few dozen scripts account for the majority of operational reuse. This is the structural reality of MSP-delivered scripting: Most operators converge on a small set of broadly useful templates and fork them per customer.

This is mostly good news. Convergence on a small set of trusted templates is the cheapest way to scale operational coverage, and CIS Control 4 explicitly recommends standard configurations as a baseline. Every one of the six is a Windows PowerShell template; no Linux clone appears anywhere among them. Reuse, as a strategy, is overwhelmingly a Windows-administration phenomenon on this platform.

Two governance signals sharpen the point. First, every one of the six carries credentials in at least some of the tenants that cloned it — these scripts authenticate to something, so a defect propagates with privilege, not just with logic. Second, the share of clones marked approved ranges only from about 63.5% to 78.8% across the six, meaning a quarter to a third of the copies of even the most-trusted templates run without a recorded review. That gap — heavy reuse, partial review — is precisely the discipline Strategy A demands.

Button

Button

The newer and faster-spreading pattern is AI-assisted authoring, a built-in feature of Acronis platform. Splitting all script-using tenants by how much of their catalog is AI-generated produces three working modes — no AI, AI-mixed, and AI-heavy (tenants with fewer than three scripts are excluded as statistically insignificant).

Button

Button

Button

Button

The AI-heavy cohort is small in tenant terms — about 13.9% of classified script-using tenants — but inside it about 74.4% of every script is AI-generated. These organizations have shifted their primary authoring mechanism toward AI generation, a different operational model from hand-authoring or template cloning. The discipline AI generation demands is output verification: AI is a fast and capable author but has no preference for what counts as production-ready and no memory of what a customer's environment can tolerate.

The NIST AI RMF Measure function is the operational anchor to review the output, attribute the prompt, version the script as any other code change, and instrument it for behavioral drift. ENISA AI guidance adds the procurement-side counterpart: Ask the same questions of your AI provider that you ask of any software supplier.

Looked at together, the two strategies are substitutes, not complements. AI-heavy tenants clone substantially less than no-AI tenants, with AI-mixed tenants sitting cleanly in between.

Button

Button

Practically, when a tenant adopts AI for scripting, the AI-generated scripts substitute for what would otherwise have been clones-and-modifications of a shared template. Tenants are not stacking AI on top of cloning; they are choosing between them. The implication for an organization deciding which path to take: Develop the discipline of one strategy, not a hybrid that combines the weaknesses of both. If you lean toward cloning, build source-curation discipline. If you lean toward AI, build output-verification discipline. Few organizations do both well from the start.

Pivoting the cohort data by country — using each customer's deployed-resource geolocation — reveals three distinct regional patterns. The chart positions each country (with at least ten classified script-using tenants) by the share of its tenants that are AI-heavy and the clone share within that AI-heavy cohort.

Button

Button

Button

Button

AI-origination markets — Brazil, Mexico, Italy, France, South Africa, Botswana, Colombia, India and others — combine an above-average AI-heavy share with low clone share inside that cohort. These are the markets where AI is used to generate new scripts rather than recombine old ones. The discipline question is output verification: Review what the AI produced before it runs on a customer endpoint, instrument it for drift and treat the AI-generated catalog as a code-managed asset.

AI-augmentation markets — Australia, Singapore and the United Kingdom — use AI alongside a strong cloning culture; their AI-heavy tenants still clone heavily. The pattern is "AI helps me make a better clone," not "AI replaces my cloning." It is a sensible transitional pattern, but it doubles the governance load — both cloning discipline and AI output verification apply.

Cloning-dominant markets — Spain, Denmark, Austria, Switzerland and Netherlands — stay with established templates and use AI sparingly. The United States is a distinctive case: AI use is widespread, yet its no-AI tenants clone more heavily than almost any other market. The discipline question in these markets is source curation: Know which templates you depend on, who maintains them, and how you would replace one if it became compromised.

The customer base is scaling operational scripting through two patterns: Template reuse and AI-assisted creation. Reuse remains the more established model, while AI generation is emerging as a narrower but increasingly important alternative. Customers are not simply adding AI on top of existing practice; many are beginning to choose between two different operating models.

Cross-tenant cloning is highly concentrated around a small number of widely replicated Acronis built-in scripts. This reflects the operational reality of MSP-delivered scripting at scale: A proven playbook spreads quickly across many tenants, which is efficient but means a defect in a master propagates with privilege to every tenant that cloned it. AI-generated scripting shows a different profile — less broadly distributed, but where adopted it can become the dominant authoring method for a tenant, shifting the control emphasis from upstream template quality to output verification.

The two approaches currently behave as substitutes rather than complements. Tenants that rely heavily on AI clone less, while tenants with little or no AI usage continue to depend strongly on established templates. Customers are selecting different governance models rather than converging on a single hybrid. Regional behavior reinforces the point: Some markets are moving toward AI-led creation, others use AI as an augmentation layer on top of active cloning and others remain primarily template driven. None is inherently wrong, but each requires a different control model, and a single governance approach will not fit all segments.

The practical through-line is to treat scripts as operational software whether they are cloned, hand-written or AI-generated, and to match the discipline to how the tenant creates and reuses them. Cloning-primary operations need source governance; AI-primary operations need generation governance; operations that do both need explicit controls for each, or they inherit the risks of both models without the discipline of either.

Inventory the scripts you have, tagged by authorship (written, cloned, AI-generated). A simple two-column list is enough for an SMB; the value comes from refreshing it quarterly. This is the smallest unit of practice under NIST SP 800-53 CM-7.

Pick one primary strategy: Cloning-primary teams build a master-source register; AI-primary teams build a five-line review checklist — inputs, outputs, error handling, secrets handling and idempotency — applied to every AI-generated script before production. CIS Controls v8 Control 16 is the practical reference for either path. Re-review any cloned script in production for more than six months; stale clones inherit the assumptions of the source on the day they were cloned, not the day you read this.

Your aggregate impact is larger than any single SMB's, and the discipline expected of you scales with customer count. Maintain a partner-side master catalog of the scripts you clone into customer tenants — every clone traceable to a known master, every master with a named owner.

Define an AI-use policy for your technicians: Mandatory human review on PowerShell or shell scripts, prohibited operations; the NIST AI RMF Govern function makes this expectation explicit. Track downstream clone counts of every script that originated with you, because each customer holding an old version is one who has not received your latest fix. Make scripting governance a contractual deliverable in regulated-vertical engagements, framed against CIS Controls v8 or the NIST Cybersecurity Framework 2.0 Protect and Detect functions.

Treat AI-generated scripts as code, not text. Review them before they run on a customer endpoint, version them in source control, and attribute the prompt and model that produced them — the NIST AI RMF Measure function captures this expectation.

Adopt the four operational checks: Inputs validated, outputs handled, errors handled, secrets not embedded; OWASP secure-coding cheat sheets are the practitioner reference, and most AI-generated script failures in production are one of these four. Re-verify AI-generated scripts after any change to the environment they touch — OS upgrades, agent updates, policy changes — because the AI author is not aware of those changes and a human must be. ENISA's Multilayer Framework for Good Cybersecurity Practices for AI is the most accessible European-side reference for AI governance at SMB and MSP scale.