Automation needs a clear handoff to people.

What is guarded automation?#

Guarded automation is a workflow that can perform useful work while preserving explicit limits on what it may read, change and commit. The limits belong to the executing application and its operating policy, not merely to a sentence asking an automated agent to be careful. OWASP's excessive-agency guidance identifies excessive functionality, permissions and autonomy as relevant causes of harmful agent behavior. An automation that can prepare a proposal does not necessarily need authority to execute it.

Write an action contract before choosing tools. Replace a broad request such as process this case with named operations: retrieve an authorized record, prepare a draft, propose a change, obtain approval, submit the change and verify the result. For each operation, define the identity, resource, environment, input, allowed effect, stop condition and observable completion. This decomposition gives engineering and operations a common language for the boundary. It also exposes where a seemingly small convenience adds a much larger capability, such as turning a report generator into an external messaging tool.

Separate preparation from consequential commitment#

Human review belongs where a material consequence becomes a commitment. Let automation prepare evidence and a proposed action, but do not assume that a general instruction to continue authorizes every later destination or change. OWASP recommends approval for high-impact agent actions and authorization enforced by downstream systems. A review step should therefore complement narrow permissions, not bypass them after someone clicks approve.

For a proposed approval contract, bind the decision to the exact subject, environment, target resource, before-and-after values, evidence version and intended consequence. Include an expiry or invalidation condition appropriate to the workflow. If the target or underlying record changes during review, the executor should require a fresh decision. Keep ordinary preparation efficient, but make the commitment inspectable. A reviewer who sees only a confidence score or a task name cannot meaningfully approve an operation whose resource set and effect remain hidden.

Model review as a state machine with explicit stop states#

A useful workflow distinguishes preparing, ready for review, approved, executing, verified and unresolved. Rejected, expired and cancelled are legitimate outcomes rather than exceptional inconveniences. Record what may happen in each state and which identity may cause the transition. In a proposed design, preparation cannot execute a commit endpoint, and a reviewer cannot force execution when the downstream authorization check fails. Those restrictions keep the process understandable even when the interface or agent makes a mistake.

Treat unknown outcomes as a separate state. If the connection fails after submission, do not automatically generate another consequential intent. Use the service's supported operation status or idempotency contract to reconcile before proceeding. A cancel request should also have honest semantics: it may stop future work without reversing an operation already committed. Give every unresolved state a named owner and enough non-secret context to investigate, otherwise automation merely moves difficult decisions into an unattended queue.

Choose autonomy from authority and consequence#

The following table is a proposed planning aid for matching execution modes to consequences. It is not a permission grant or a universal risk classification. A local formatting step can still mishandle sensitive input, and a normally reversible update can become consequential in the wrong environment. Evaluate the actual data and destination, not the name of the tool. The most useful initial automation is often a narrow preparation step whose output a person can inspect.

Consider whether a failure can be detected and recovered within the operating model. Automatic commitment is harder to justify when there is no reliable way to establish completion or when the consequences cannot be reversed. Human approval is valuable only when the evidence is sufficient and the reviewer has legitimate authority. Avoid using a nominal review step to make an otherwise unbounded tool appear controlled; the executor must enforce its own resource and action limits.

Fictional worked example: prepare a temporary staging access change#

Consider the fictional product Atlas Review, an internal tool used in an authorized staging exercise. An operator requests temporary read access for a disposable test user to a synthetic reporting workspace. The preparation service can inspect the permitted workspace and draft a proposal, but it cannot grant access. The proposal names the test identity, staging environment, exact workspace, current permissions, requested read-only change and intended end condition. It contains no passwords or authentication tokens.

A reviewer examines the proposal and its evidence, then approves that version. The commitment service independently checks the reviewer's authority, confirms the target remains the same and verifies that the requested permission is permitted in staging. It then applies the narrow change and reads the authoritative membership result. The visible outcome says the selected test identity received the reviewed staging access; it does not merely say the automation completed. This fictional workflow illustrates a design contract, not a claim about a client system or a guarantee that temporary permissions expire without implementation support.

Fictional worked example: reject changed proposals and reconcile uncertainty#

Atlas Review's next test changes the requested workspace after approval. The commitment service rejects the stale proposal instead of applying the earlier approval to a new resource. Another test uses a reviewer without grant authority: the draft remains inspectable, but execution is denied. A third makes the evidence incomplete, so the tool requests clarification rather than inventing why broader permission is needed. These checks distinguish useful preparation from legitimate authority to commit.

Finally, the sandbox simulates a lost response after the access change is applied. Atlas Review records the operation identifier and moves to unresolved. It checks the authoritative operation result before allowing another commitment, then displays the verified membership state. The exercise also confirms that the configured end condition removes the temporary test access and that a failed removal reaches an operational owner. Completion and expiry are separate observations. The report names these synthetic cases and versions rather than claiming all future access changes are safe because a reviewer was once involved.

Verify the authoritative outcome beyond a successful click#

Browser automation checks are useful but bounded. By default, Playwright checks relevant actionability conditions before a standard locator.click(), including visibility, stability, event reception and enabled state. Using force can bypass some checks, so it must not be treated as equivalent verification. Those conditions make an interaction more dependable; they do not establish that the selected account is correct, that a reviewer has permission, or that the destination committed the intended business change. A clickable button on the wrong record remains the wrong operation.

Pair interaction checks with workflow checks. Confirm identity, environment, target and proposal version before submission. After submission, inspect a result that the application treats as authoritative: the changed record, durable operation status or documented service outcome. Do not use a toast as the only evidence if it merely acknowledges receipt. In a test environment, deliberately interrupt the response and inspect resulting state. If completion remains uncertain, stop dependent work and expose the next safe reconciliation step instead of continuing on the assumption that a successful interaction means success.

Give reviewers evidence without building a secret store#

A review record should explain what was proposed, what supported it, who approved the specific version, what executed and what result was verified. OWASP's logging guidance recommends interaction identifiers for linking relevant events and cautions against recording secrets such as passwords, access tokens and session identifiers. Use explanatory identifiers and appropriate resource metadata, not credential values, to connect preparation, approval and execution.

Separate evidence needed for the decision from information that would merely make the record larger. Show current and proposed values, provenance, age and uncertainty. Restrict access to sensitive operational context and define retention or deletion with its owner. A rejected proposal can contain confidential material even when no action occurs. Let reviewers correct or reject without copying the full evidence into another channel. A practical audit trail should support investigation and accountability while remaining proportionate to the workflow's actual data and consequence.

Verification checklist, tradeoffs and next steps#

Start with one workflow and specify its permitted transitions, identities and observable result. Test preparation, rejection, changed evidence, denied authority, lost response and recovery using synthetic information. Review the operator experience as well as the executor: people must be able to inspect the proposal, understand what approval permits and pause unresolved work. Track meaningful outcomes such as corrections, failed verification and unresolved items without inventing an overall success percentage from an incomplete log.

Guarded automation has operating costs. Narrow tools need maintenance, approval can create backlog and verification can expose integrations with weak completion semantics. Review fatigue is a real design concern, but removing all review is not the only response; improve evidence and reserve deliberate commitment for consequential boundaries. No architecture guarantees correct human decisions or eliminates every automation failure. The next useful deliverable is a tested action contract with an explicit limit, not a broad promise that the workflow can now run unattended forever.

• Define each operation's identity, target, environment, permitted effect and completion evidence.
• Keep preparation capabilities narrower than consequential commitment capabilities.
• Bind approval to an exact version and invalidate it when the consequence changes.
• Enforce authorization in the executing application or downstream service.
• Distinguish rejection, cancellation, expiry, completion and unknown outcome.
• Verify the authoritative result and reconcile uncertain writes before another commitment.
• Retain proportionate non-secret evidence and assign an owner to unresolved work.