AI agent acts without approval

Problem Context

• The agent can call tools, send external messages, spend money, issue refunds, change access, update customer records, deploy code, delete data, submit forms, publish content, or trigger downstream workflows.
• The UI may describe the agent as preparing, researching, drafting, or working while side effects are already committed.
• Users may have approved a broad prompt, plan, or recommendation but not the exact payload, target, timing, or downstream consequence that executed.
• Approval can be required by policy, confidence, source gaps, cost, permissions, customer impact, legal risk, security risk, or separation of duties.
• The agent may need different treatment for safe read-only steps, reversible draft steps, gated side-effect steps, emergency bypass, and post-action recovery.

Selection Rules

• Flag this anti-pattern when an AI agent or automation executes a high-impact side effect without showing and requiring approval for the exact action and payload first.
• Flag it when a broad Run, Continue, or Looks good control authorizes hidden tool calls, sends, edits, purchases, deletes, deployments, or access changes.
• Use human approval gate for the corrected runtime checkpoint when the agent is paused before an armed step and needs an eligible human decision.
• Use agent plan preview when users need to inspect proposed steps before execution starts; plan review does not authorize unlisted future side effects.
• Use agent progress trace when users need live monitoring after execution starts; progress visibility does not replace approval for risky steps.
• Use tool-use visibility when users must inspect exact tool names, inputs, outputs, permissions, and payloads; tool detail supports approval but is not the gate itself.
• Use dangerous-action review when a single high-impact manual action needs payload review outside an agent run.
• Use automation rule builder when users are authoring reusable future behavior rather than approving one armed runtime step.
• Allow low-risk read-only agent steps to run without approval only when the UI clearly scopes them as read-only and they cannot create external side effects.
• If emergency bypass is allowed, show who can bypass, why, what will execute, how rollback works, and how the bypass is audited.

Required States

• Read-only step allowed state with no external side effect.
• Approval required before side effect state.
• Payload preview state with target, action, tool, data, cost, recipients, environment, or access scope.
• Eligible approver and self-review blocked state.
• Approve and resume state that revalidates the displayed payload.
• Edit before approve state that creates a new payload version.
• Reject, cancel, stop run, and rollback available states.
• Stale approval refused state for changed input, target, source, model, policy, or payload.
• Emergency bypass state with elevated permission and required reason.
• Bad silent execution, broad consent, hidden tool call, post-action approval, stale approval, self-approval, no rollback, and audit-only states.

Interaction Contract

• The agent distinguishes read-only steps, draft steps, reversible local changes, and external side-effect steps before execution.
• Side-effect steps cannot run until the interface shows the action, target, payload version, tool, approver rule, risk, and resume consequence.
• A broad instruction, plan acceptance, confidence score, progress trace, or notification does not authorize hidden future side effects.
• Approval is valid only for the displayed payload and expires when target, input, source, model, policy, tool permission, or threshold changes.
• Approve resumes only the named gated step unless the UI explicitly lists additional authorized steps.
• Reject, cancel, edit, stop, rollback, and escalation outcomes leave the run in a named state with reason and recovery path.
• Post-action audit records must say the action already happened and provide rollback, report, or escalation controls when possible.
• The audit trail records what the user saw before approval, who approved or bypassed, what executed, and whether recovery was attempted.

Implementation Checklist

• Inventory all agent tools and mark read-only, draft-only, reversible, externally visible, money-moving, access-changing, destructive, deployment, publication, and customer-impact steps.
• Define which steps require approval by policy, risk, confidence, source status, cost, data sensitivity, target environment, recipient scope, or separation-of-duties rule.
• Render proposed side-effect steps with payload preview, diff, target, tool, evidence, risk, approver eligibility, timeout, and downstream consequence before execution.
• Require explicit approve, edit, reject, cancel, stop, or bypass controls for gated steps, and block self-approval where policy requires independent review.
• Revalidate payload hash, target, source freshness, model version, policy version, approver role, and tool permission immediately before resuming the gated step.
• Separate plan preview, progress trace, tool-use visibility, approval gate, dangerous-action review, and audit trail data so users can tell proposed, armed, executing, and completed actions apart.
• Provide post-action recovery for bypassed or unauthorized execution: stop future steps, rollback, revoke, notify affected users, report incident, and inspect audit trail.
• Test hidden side-effect tools, broad prompt consent, stale notification approval, self-approval, edited payload, emergency bypass, failed resume, rollback, mobile approval, keyboard flow, and high-zoom payload wrapping.

Common Generated-UI Mistakes

• Treating Run agent as permission to execute every hidden side-effect step.
• Sending a customer message or issuing a refund while the UI still says the agent is drafting.
• Showing an approval card after the tool already executed.
• Letting the requester approve their own high-impact automation step.
• Using high confidence, source grounding, or a green progress state as a substitute for authorization.
• Hiding the exact tool input, recipient list, amount, access target, deployment environment, or deletion scope.
• Providing no stop, rollback, cancel, report, or escalation path after unauthorized execution.

Critique Questions

• Which agent steps are read-only, draft-only, reversible, externally visible, destructive, money-moving, access-changing, or customer-impacting?
• What exact action, target, payload, tool, and version will execute after approval?
• Can the user distinguish proposed work, armed gated work, running work, completed work, and audit history?
• Who is eligible to approve, who is blocked from self-review, and what happens if the approval becomes stale?
• What recovery exists if the agent already acted without approval?
• Would human approval gate, agent plan preview, agent progress trace, tool-use visibility, dangerous-action review, or automation rule builder solve the actual problem?