What is the difference between approval per action and approval per script for agentic browser automation?

Approval per action interrupts the workflow after every mutating step, which is safe but hard to use for multi-step tasks. Approval per script lets the model describe the full intended change once, then run the entire sequence if approved. That reduces friction, but it increases the importance of accurate write descriptions and independent safety checks for the whole script.

Why approval per action and approval per script solve different safety problems

Approval per action treats every mutating step as a separate decision point, so the human sees and approves each write, send, or change before it happens. Approval per script shifts the review to the plan level, where the human approves the proposed sequence once and then lets execution continue. The practical difference is not just convenience, it is where the safety boundary sits.

For short or highly sensitive tasks, per-action approval gives stronger interruption and tighter user control. For longer tasks, it can become noisy enough that people either slow down or stop trusting the tool. Approval per script is better when the task is a coherent workflow and the user can judge the whole intended change up front.

That trade-off matters because agentic browser automation often combines navigation, form filling, account changes, and data movement in one run. A script-level approval model only works if the proposed script is readable, specific, and faithful enough that a human can understand the end state before execution begins.

What changes in the agent’s permission model

Per-action approval narrows the agent’s effective authority to one step at a time. The agent may still prepare a sequence, but it cannot assume the next write, click, or submission will be allowed without another checkpoint. That reduces blast radius, especially when a page can trigger side effects that are not obvious from the immediate action.

Per-script approval gives the agent broader temporary authority after the script is accepted. That makes multi-step work smoother, but it also means the initial description becomes the main control surface. If the summary is vague, incomplete, or misleading, the human may approve a change they would not have accepted step by step.

The core distinction is therefore a control design choice: per-action optimizes for granular consent, while per-script optimizes for workflow continuity. In practice, the safer model depends on whether the task is simple enough for stepwise review or whether the end-to-end outcome is the real thing the operator needs to judge.

Why script-level approval needs stronger guardrails

Script-level approval is only defensible when the system can show the full intended write path, not just the first obvious click. In browser automation, hidden consequences often appear after navigation, redirected forms, repeated submissions, or state changes across multiple tabs. A good approval prompt needs to describe those downstream effects clearly enough for the reviewer to reason about them.

That is why independent safety checks matter more at script approval time. The system should still validate scope, destination, and permitted action classes before execution, even after a human has approved the plan. This is especially important when the script can touch accounts, sessions, payments, content publication, or other irreversible states.

For browser-based agents, controls such as site scoping, profile isolation, and confirmation boundaries are part of the same trust decision. See the Browser and Computer-Use Agent Security Guide for the surrounding controls that keep browser automation bounded. For approval design itself, the AI Agent Authorisation Guide explains why per-action authorization, delegated authority, and human approval are complementary rather than interchangeable.

Risk and Threat Considerations

Script-level approval increases the impact of a bad description, a poisoned prompt, or a manipulated plan. If the reviewer approves the wrong intent, the agent can carry that mistake through an entire sequence before the next human checkpoint appears.

Failure mechanism: An attacker or faulty instruction changes the proposed workflow, hides an important write step, or exploits user fatigue so the whole script is approved as if it were harmless. In browser automation, that can turn a single consent decision into multiple unauthorized or irreversible changes.

Impact: The result can be broader data exposure, account modification, unwanted submissions, or abuse of the user’s authenticated browser session. The larger the script, the more the risk shifts from one mistaken click to a compound change that is harder to unwind.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agent approval model changes how much authority a browser agent gets.
	ASI02 — Tool Misuse	Browser automation can misuse tools when a script is over-broad or misread.
Recommendation — Apply ASI03 to keep agent actions bounded by explicit, reviewable authorization. Apply ASI02 to constrain tool use to the intended browser actions.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Approval per action versus per script is a privilege-bounding choice.
	AU-6 — Audit Review, Analysis, and Reporting	Script approval needs traceability for what the agent was allowed to do.
Recommendation — Enforce AC-6 so browser agents receive only the access needed for the approved task. Use AU-6 to review agent action logs against the approved plan.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	Per-action checks and script-level bounds reflect continuous verification.
Recommendation — Apply zero-trust principles to verify each high-impact browser action before execution.

Practitioner Guidance

What to verify: Treat the approval artifact as the control, not the prompt length. Before trusting script approval, verify that the description names the target site, the state changes, and the irreversible steps in plain language.

Decision rule: Use per-action approval when the task can cause meaningful side effects at each step or when the reviewer cannot reliably infer the full end state. Use per-script approval only when the full workflow is reviewable, bounded, and easy to compare against the intended outcome.

What practitioners underestimate: The failure mode is usually not the individual action, it is approval fatigue plus ambiguity. The best script-level systems make the plan explicit enough that a human can reject the whole sequence for the right reason before any write begins.

Practitioner takeaway: Per-action approval is a finer safety brake, but per-script approval can be efficient if and only if the plan is specific enough to inspect and the system still enforces independent bounds on what the script may do.