Per-script approval is a control pattern where a mutating agent workflow is reviewed once before execution instead of approving every individual action. It lowers interaction overhead for multi-step tasks, but it depends on a trustworthy description of intended changes and strong enforcement when that description is missing or misleading.
What Per-Script Approval Means in Agent Workflows
Per-script approval is a coarse-grained execution control for mutating agent workflows. It asks a reviewer to approve the intended change set once, then lets the workflow proceed without pausing for every individual step.
Where Per-Script Approval Fits in Change Control
This pattern sits between fully manual review and fully autonomous execution. It is useful when a workflow includes several dependent actions that are easier to judge as a unit than as isolated commands, especially when the reviewer needs to understand the overall intent, not each sub-action.
Its main value is reduced friction, but that convenience only holds when the script description is accurate enough to represent the real blast radius of the run. If the description is vague, selective, or stale, the approval becomes a weak proxy for the actual effect of execution.
Why the Approval Boundary Matters
Per-script approval works because it shifts the control point from “every action” to “the full planned change.” That also changes the trust assumption: the system must enforce the boundary between what was approved and what the workflow later attempts to do.
When that boundary is reliable, reviewers can make practical decisions about a complete task, such as a deployment, a remediation sequence, or a data update. When it is not, the control can create a false sense of safety by making a broad approval look more precise than it really is.
What Good Per-Script Approval Requires
The control is strongest when the proposed script is specific, deterministic, and easy to compare against what will actually execute. It is weaker when scripts assemble commands dynamically, call out to external services, or branch in ways that are hard to summarize before execution.
That is why per-script approval is best treated as a governance layer, not a substitute for execution-time constraints. The approval should be paired with enforcement that blocks unapproved mutations, tracks what really ran, and preserves an audit trail that can be reviewed after the fact.
Risk and Threat Considerations
Per-script approval can reduce reviewer fatigue, but it also creates a single approval boundary that attackers or faulty automation may try to exploit. The risk is highest when the described script differs from the executed behaviour, or when later steps expand scope beyond what the reviewer understood.
Failure mechanism: A misleading summary, hidden branching logic, or runtime-generated action sequence can cause a reviewer to approve one change set while the workflow executes another. That turns a convenience control into an overbroad trust decision.
Impact: The result can be unauthorized mutations, privilege abuse, data loss, or unintended changes that are harder to catch because the workflow appeared to have been approved at the right level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Per-script approval limits how much authority a workflow receives at once. |
| AU-2 — Event Logging | Approval and execution need auditability to verify what was authorised and what ran. | |
| CM-5 — Access Restrictions for Change | The pattern governs who can make mutating changes and under what approval boundary. | |
| Recommendation — Limit workflow permissions to the minimum needed for the approved script. Log the approved script, executed actions, and any runtime deviations. Require change restrictions so only approved mutating workflows can proceed. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege, | Per-script approval depends on constraining execution authority to the approved change. |
| DE.CM-01 — Anomalies and Events Are Monitored | Deviation from the approved script must be detectable during execution. | |
| Recommendation — Apply least-privilege execution rights to the approved workflow only. Monitor runtime behaviour for actions outside the approved script. | ||
Practitioner Guidance
What to watch for: Use per-script approval only when the approved description is faithful enough to represent the real execution path. The control is strongest for bounded, predictable workflows and weakest for scripts that assemble actions dynamically or depend on hidden runtime inputs.
Governance implication: Treat the approval object as the unit of accountability, then make sure the enforcement layer can prove that execution stayed inside that approved boundary. If it cannot, the control should be narrowed or supplemented rather than trusted as a standalone safeguard.
Related resources from NHI Mgmt Group
- What is the difference between approval per action and approval per script for agentic browser automation?
- How should security teams handle script approval when payment pages change frequently?
- Who is accountable when a GPO logon script is modified without approval?
- What is the difference between AI-assisted script authorization and autonomous script approval in PCI DSS programmes?
