There is a question that comes up late in most automation projects, usually from someone in quality, and it is a better question than it first sounds: what can this thing reach?
Whatever the answer is, that is now your validation scope. Which makes "off by default" less of a security posture and more of a scoping decision.
Capability is scope
If a validation tool can drive a browser against any URL, then any system reachable from that host is in the conversation. If it can reach hosts over SSH, the estate is in the conversation. Nobody intended that; it is simply what the capability implies, and an impact assessment that ignores it is incomplete.
The practical consequence is that every capability you ship enabled is one you have to reason about, document, and re-reason about at every periodic review. Capabilities that are off are not zero cost, but they are much cheaper: you are asserting that a thing is disabled, which is checkable.
Three switches worth having
- The module. Automated execution off entirely unless a business turns it on. Most organisations adopting a validation platform do not start with automation, and there is no reason for the capability to exist in their installation before they ask for it.
- The heavy dependencies. Browser automation drags in a browser engine — a large, frequently-patched dependency with its own CVE stream. Behind a build flag, so an installation that does not automate UI testing does not carry it at all.
- The reach. Which hosts, which environments. A tool configured to reach only the qualified test environment cannot accidentally be pointed at production, and that is a much easier sentence to write in a validation plan than a procedural control.
We ship all three off in GxP Copilot for exactly this reason. It occasionally means an extra step during setup, and it means the answer to "what can it reach?" is a short, checkable list rather than an argument.
The failure this prevents
The scenario is mundane rather than dramatic. Somebody copies a working test configuration to investigate an issue, changes the target to reproduce something, and runs it. The target is production.
Nothing malicious, nobody incompetent — a normal Tuesday. If the tool is capable of reaching production, procedure is the only thing standing between that Tuesday and a deviation on a live system. If it is not capable, the step simply fails, and the failure is the control.
This is the same argument as refusing a general command step, applied to configuration rather than to step types: make the wrong thing impossible rather than discouraged.
Writing it into the validation plan
State the default posture, the enabled capabilities, and who authorised each. It reads well and it is verifiable:
"Automated execution is disabled by default. It is enabled for the Validation environment only, authorised by [role] on [date]. Browser automation is not included in this installation. The engine is configured to reach the hosts listed in Appendix B and no others."
An inspector can check every clause of that against the system in about five minutes, which is the point. See EU Annex 11 & Annex 22 compliance for how this fits with wider computerised system expectations.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.