Unrestricted shell escape for package automation versus restricted mode in CI pipelines

Context

Modern LaTeX workflows often require unrestricted shell escape (–shell-escape) to support packages such as minted, epstopdf-auto, or latexmk’s automatic dependency resolution. At the same time, continuous-integration pipelines and shared build servers must limit the attack surface of untrusted source files.

Constraint

TeX Live and MiKTeX ship with a restricted whitelist that permits only a small set of known-safe commands. The whitelist differs between distributions and can change across releases, so a project that compiles locally may fail on a CI runner without an explicit opt-in. Conversely, granting full shell escape globally defeats the principle of least privilege and exposes the host to arbitrary command execution.

Open questions

1. Is there a documented, distribution-agnostic way to declare per-project shell-escape requirements (e.g., via a texmf.cnf snippet or latexmkrc) that CI systems can honor without manual --shell-escape flags?
2. For workflows that cannot migrate to LuaTeX’s embedded Lua, what sandboxing strategies (containers, seccomp profiles, dedicated build users) are known to contain a compromised \write18 call while still allowing the required external tools?