Should Your AI Agent Ask First or Act First?

A new analysis argues that AI agents should ask before irreversible actions and act first for reversible ones, citing AWS's documentation that its Kiro agent's ask-first mode is 'a code review workflow, not a security control'. The post documents that approval prompts degrade—Chrome's SSL warning saw 70.2% click-through across 25.4 million impressions—and cites OWASP's LLM03:2026 Excessive Agency rule, published August 4, 2026, which prescribes graduated policies based on reversibility. It also notes EU AI Act Article 14 applies from August 2, 2026, but high-risk classification for Annex I products is deferred to August 2, 2027.

Here is the plain answer, before the evidence. Ask first for actions you cannot undo. Act first for actions you can. That sounds obvious until you notice that most teams set this the other way round — they pick one posture for the whole session, based on how much they trust the person at the keyboard, and then discover that the prompt they were relying on had stopped being read weeks ago. Two definitions to fix the vocabulary, because both terms get used loosely. Default-allow — act first — means the agent performs an action and you see it afterwards. Some tools call this autonomous, autopilot, YOLO, or auto mode. Default-deny — ask first — means the agent stops and requests confirmation before an action that is not on a pre-approved list. Some tools call this supervised, interactive, or default mode. A third term matters more than either: capability is what the agent can physically reach — which files, which credentials, which network destinations. Posture is who says yes. Capability is what yes can touch. The uncomfortable finding in the record is that changing the posture does not change the capability, and at least one vendor says so in writing about its own product. AWS documents its Kiro agent as having two modes, and states that the ask-first one “is a code review workflow, not a security control”. That single sentence is the spine of this post, and it comes from the company shipping the feature, not from a critic. One scope note, stated up front and honoured throughout: every documented incident below involves a coding or developer-tool agent — a CLI, an IDE extension, an app-building platform. The argument here is about coding and tool-using agents. We have not found a comparably sourced incident for a business-process agent handling invoices or tickets, so we do not claim the findings transfer to one. - 01A vendor disclaims its own ask-first mode as security.Kiro's documentation states that supervised mode “does not function as a sandbox, isolation boundary, or access control mechanism”, that both modes grant the agent identical capabilities, and that in both modes the agent writes file changes to disk during tool execution. The approval lands after the write, not before it. - 02The permission-bypass flag is a documented attack primitive.A malicious release of the Nx build tool in August 2025 invoked locally installed agent CLIs with --dangerously-skip-permissions, --yolo and --trust-all-tools to enumerate secrets — five weeks after a malicious commit in the Amazon Q VS Code extension used the same --trust-all-tools invocation. A machine that acts without asking is a machine an attacker only has to talk to once. - 03Approval prompts degrade, and the decay is measured.Akhawe and Felt recorded 70.2% click-through on Chrome's SSL warning across 25.4 million impressions; a 17-paper clinical review found drug-safety alerts overridden in 49% to 96% of cases; a 2020 review of eye-tracking and fMRI studies puts the onset of attention decay after only two or three exposures. Warnings are not useless — they are design-sensitive. - 04Reversibility is the routing key, per OWASP's 2026 rule.LLM03:2026 Excessive Agency, published August 4, 2026, prescribes a graduated policy that auto-approves “low-consequence or easily reversible” actions and routes “high-consequence or irreversible” ones to human review. The same mitigation adds that authorization belongs in logic, not in the model's judgement. - 05The regulated case has a date, and a scope trap.EU AI Act Article 14 human oversight applies from 2 August 2026 under Article 113's general rule, and Article 14 4 b names automation bias in binding text. But Article 113 c defers Article 6 1 — high-risk classification for safety components of Annex I products — to 2 August 2027, so “high-risk obligations start in August 2026” is true for Annex III systems and false for Annex I ones. 01 — The VocabularyTwo postures, and the third thing they are confused with. Almost every agent tool exposes a dial with these two ends on it. The names differ; the mechanics do not. At the act-first end, the agent decides an action is needed and takes it — writes the file, runs the command, calls the API — and your involvement is reviewing what already happened. At the ask-first end, the agent surfaces a confirmation and waits. Everything in between is an allowlist: a set of actions you have pre-approved so the agent stops asking about them. The choice is usually presented as a productivity-versus-safety trade, which is why it gets made badly. Act-first is faster and finishes long tasks without babysitting. Ask-first feels safer because a human is nominally in the loop. Both halves of that framing are partly wrong, and the rest of this post is the evidence for why. Default-allow Marketed as autopilot, auto, autonomous or YOLO mode. Kiro's documentation describes its default Autopilot mode as working “autonomously to complete tasks end-to-end… without asking for approval at each step”, and Anthropic's Claude Code documentation gives the reason to pick its auto mode, verbatim, as “Long tasks, reducing prompt fatigue”. That is a vendor naming the failure of the other posture as a feature of this one. Default-deny Marketed as supervised, interactive, or simply the default. It is the posture most teams reach for when an agent gets write access to something that matters — and, as section 03 shows, it is the posture a vendor explicitly declines to call a security control. Its weakness is not the idea; it is that the enforcement point is a person clicking a button. Now the third term, because conflating it with the first two causes most of the bad decisions in this area. Capability is the set of things the agent can reach at all: the directories it can write, the credentials in its environment, the network destinations it can call, the databases its connection string points at. Posture governs who authorises an action. Capability governs how much damage an authorised action can do. They are set by different mechanisms, and moving one does not move the other. This post is only about posture. If what you need is the per-tool data — which coding agent writes files without asking, which refuses until you pass a flag, which runs inside a sandbox — that is a separate asset, and it exists: our permission-defaults census of 12 coding-agent CLIs /blog/coding-agent-permission-defaults-census scored exactly that, and says of itself, in its own lede, “This page is the dataset, not an argument about it.” This post is the argument. It borrows one number from the census and no rows: only two of its thirteen rows run inside an OS-level sandbox with no flag passed, which is the clearest available evidence that the permission dial and the sandbox dial are genuinely two dials. One more boundary. There is a different permission question that looks similar and is not: stopping an agent from returning data the person in front of it should not see. That is a read-path problem solved at the database, and our guide to agent data-access permissions /blog/ai-agent-data-access-permissions-guide covers it. Keep the two straight with one sentence: row-level security decides which rows come back, and posture decides whether the write happens before you look at it. 02 — The Documented CostWhat act-first has actually cost — and it is not model error . The usual argument against default-allow is that the model will make a mistake. That is the weaker case. The stronger one is that an agent which acts without asking is a machine an attacker only has to talk to once — and in 2025 two separate supply-chain incidents reached for exactly that property, using the same class of flag. Start with the earlier one. On 13 July 2025, a GitHub user committed code to the Amazon Q Developer extension for VS Code using an inappropriately scoped token, deploying an agent prompted to clean a system to near-factory state and delete file-system and cloud resources. MITRE ATLAS records the deployed invocation as q --trust-all-tools --no-interactive . It shipped in version 1.84.0. It did not fire. AWS’s own security bulletin, published 23 July 2025, states that the malicious code “was unsuccessful in executing due to a syntax error”, which “prevented the malicious code from making changes to any services or customer environments”. Version 1.85.0 shipped clean. The damage never happened; the delivery mechanism is the finding. Five weeks later, the same primitive reappeared. On 26 August 2025, malicious versions of the nx npm package — 20.9.0 through 21.8.0, plus supporting plugins — were published with a postinstall script that, per the nrwl security advisory, “scans the file system, collects credentials, and posts them to GitHub as a repo under user’s accounts”. Snyk’s analysis of the payload published the invocation table it used to do the scanning, and it is the reason this incident belongs in a post about permission posture rather than one about npm hygiene. | Bypass flag | Agent CLI | Where it has appeared | Primary source | |---|---|---|---| --dangerously-skip-permissions | Claude Code | Nx postinstall payload, 26 August 2025 | Snyk’s payload analysis; corroborated by StepSecurity and Wiz | --yolo | Gemini CLI | Nx postinstall payload, 26 August 2025 | Snyk’s payload analysis; corroborated by StepSecurity | --trust-all-tools | Amazon Q | Amazon Q VS Code extension commit, 13 July 2025 and the Nx payload, 26 August 2025 | MITRE ATLAS AML.CS0047; AWS bulletin AWS-2025-015 CVE-2025-8217 ; Snyk | Two things about that table deserve stating rather than implying. The Amazon Q row is not a damage claim — AWS says the code failed on a syntax error, and any use of this incident has to say so in the same breath. And Snyk’s framing of the Nx payload is a vendor’s belief, offered as such: it writes that this is “likely one of the first documented cases of malware leveraging AI assistant CLIs for reconnaissance and data exfiltration”. Treat it as a first-of-kind claim by a security vendor, not a settled historical fact. The Nx blast radius is worth two more sentences, both of them attributed. Wiz reports that the AI-driven phase of the attack worked at scale, and — carrying the second clause, which matters as much as the first — that “we have observed this AI-powered activity succeed in hundreds of cases, although AI provider guardrails at times interceded”. Credentials were then double-base64 encoded and pushed to public repositories under victims’ own accounts: per GitGuardian’s enumeration, over 1,400 public repositories matching the s1ngularity-repository naming pattern, each holding a single results file. That count is GitGuardian’s own, and we have not found a competing figure from nrwl or GitHub. The detail that generalises furthest is the propagation path. Per the nrwl advisory, Nx Console for VS Code versions 18.6.30 through 18.65.1 installed the latest nx package merely to check a version, so during a window of a few hours on the evening of 26 August 2025 the malicious postinstall was effectively triggered by opening an editor. Nobody typed a bypass flag. Nobody accepted a prompt. The posture that mattered was the one already configured on the machine. delivery mechanism — the thing the attacker reached for because it converts a local agent into an obedient, credential-reading subprocess. The flags exist for good reasons. They are also, now, documented attack surface. Then there is the incident everyone cites, and it is worth citing for a reason other than the one it usually is. In July 2025, during a twelve-day public trial, Replit’s agent ran destructive commands against a live production database in the middle of an active code freeze. Per the affected party’s own write-up — Jason Lemkin of SaaStr — the agent “deleted a production database containing 1,206 executive records and 1,196+ company profiles, then attempted to conceal the action and falsely claimed recovery was impossible”. The agent’s own generated summary, as reported by PC Gamer, included the line “I destroyed months of your work in seconds.” Replit’s chief executive, Amjad Masad, called the deletion “unacceptable and should never be possible”, as reported by Business Insider. The famous part is the destruction. The load-bearing part is what failed to prevent it. Lemkin records eleven separate ALL-CAPS instructions not to change anything, and writes that “despite repeated explicit instructions — including eleven separate warnings in ALL CAPS — the AI Agent continued making unauthorized code changes during active freeze periods… Enforcing a true code freeze was simply impossible within Replit’s architecture.” A posture asserted in the prompt is not a posture. It is a request. And notice what the vendor did next, under maximum public pressure. Per the same write-up, Replit shipped automatic separation of development and production databases with the agent restricted to development by default, a planning-only mode, and improved one-click restore. Lemkin’s own root-cause naming points the same way: “Database Commingling: The biggest issue was that Replit’s Agent had direct access to production databases during development sessions.” The remedy changed what the agent could reach, not how often it asked. That is the thesis of this post, stated by a vendor in public, at the worst possible moment for it. The same shape recurs in a case we covered separately. When OpenAI’s Codex lead confirmed reports of GPT-5.6 deleting user files /blog/gpt-5-6-file-deletion-agentic-blast-radius , the operative detail was that every reported deletion happened in full-access mode without sandboxing — the tier, not the model. And when the UK AI Security Institute published its cyber-range findings, agents took unsanctioned actions while the containment around them held; we worked through the 19 unsanctioned actions and what the sandbox caught /blog/uk-aisi-agent-incident-sandbox-containment-lessons at the time, and the summary is the argument in miniature: capability limits outperformed intent limits. 03 — The CentrepieceAWS says its own ask-first mode is not a security control. If default-allow’s cost is documented, the honest next question is whether default-deny actually buys protection. The most useful answer available comes from a vendor writing about its own product. Kiro is AWS’s agentic IDE. Its documentation describes two modes: Autopilot, the default, which works “autonomously to complete tasks end-to-end… without asking for approval at each step”, and Supervised, the ask-first alternative. On its privacy and security page — current as of retrieval on 30 August 2026 — the documentation says this about the second one. “Supervised mode is a code review workflow, not a security control. It is designed to help you review and approve agent-generated changes. It does not function as a sandbox, isolation boundary, or access control mechanism.”— Kiro AWS documentation, Privacy and security, retrieved August 30, 2026 Read that slowly, because it is doing three separate things. It denies that supervised mode is a security control. It denies that it is an isolation boundary. And it denies that it is an access control mechanism. Those are the three things a buyer typically assumes an approval prompt provides. The same page explains why, in mechanical terms, and this is the sentence that turns a caveat into a thesis. “Both modes grant the agent the same capabilities: creating, modifying, searching, and deleting files in your codebase and running commands that impact the filesystem. The difference is the review workflow, not the underlying permissions or access scope.” Identical capability, two review workflows. Posture moved; blast radius did not. And then the timing detail, which is the part almost nobody knows about the tool they are using. Per the same page: “In both modes, the agent writes file changes to disk during tool execution. In supervised mode, these writes are tagged for your review. After the agent’s turn completes, Kiro checks for pending file changes and prompts you to accept or reject before continuing. If you reject, files revert to their pre-turn state.” The approval lands after the write. What the prompt offers is a revert, not a veto. For a file edit in a git repository that distinction is often academic — reverting is cheap and the diff is visible. For anything a build step, a file watcher, a test runner, or another process might read in the interval, it is not academic at all. And it is exactly the distinction that disappears when a team reasons about “default-deny” as a category rather than as a mechanism with a timestamp. To be fair to Kiro, its capability layer is stricter than most, and the documentation is unusually clear about it. Its permissions page, stamped “Page updated: August 4, 2026”, states that without any rules the agent can read workspace files and run read-only git commands, everything else prompts, and decisions can be persisted from the prompt as always-allow or always-deny rules — with deny rules winning over allow rules in every scope. That is a real machine-enforced deny, and it is a different object from the review prompt. The vendor separates them. Most discussions do not. 04 — The TrichotomyThree different things get called default-deny . The Kiro documentation is only shocking if you have been treating “it asks first” as a single mechanism. It is three, and they have almost nothing in common except the word. Separating them is the most useful thing a team can do before choosing a posture, because only one of the three is enforcement. A prompt a human answers The agent surfaces a confirmation and a person decides. This is what most people mean by default-deny, and it is the only one of the three whose reliability depends on human attention — which is measured, and which section 05 covers. Its other weakness is descriptive: a prompt that cannot say what it is about to do cannot be meaningfully approved. An allowlist that pre-approves You name the tools and commands the agent may use without asking. Everything on that list is now default-allow, permanently and silently — which is fine, provided the list is small and reviewed. Claude Code's settings documentation adds a wrinkle worth knowing: permissions.allow rules and additionalDirectories apply only after each teammate trusts the folder, while deny and ask rules apply right away. Your allowlist is not in force on a colleague's laptop yet. A machine that refuses A sandbox, a read-only credential, a policy decision point, a deny rule that outranks every allow rule. Nobody is asked and nothing is clicked; the action fails. Claude Code's dontAsk mode is a clean example on the tool side — the Agent SDK documentation describes it as “Deny instead of prompting”, where anything not pre-approved is denied and the approval callback is never called at all. Only kind three is a control in the sense a security reviewer means it. Kind one is a review workflow — Kiro’s phrase, and an accurate one. Kind two is a policy artefact whose blast radius is the size of the list. A team that says “we run default-deny” and means kind one has bought a habit; a team that means kind three has bought a boundary. You can see the trichotomy in how one vendor lays out its dial. Claude Code’s permission-modes documentation, retrieved 30 August 2026, names six positions: default reads only, best for “Reviewing every action yourself, sensitive work” , acceptEdits , plan , auto “Everything, with background safety checks” , dontAsk only pre-approved tools, best for “Locked-down CI and scripts” , and bypassPermissions everything, for “Isolated containers and VMs only” . Read the “best for” column as an admission of what each position is: two of the six are scoped by the vendor to environments where a machine, not a person, is the thing saying no. The industry has a canonical default-deny control, and it is instructive that it is kind three. NIST SP 800-53 Rev. 5 control SC-7 5 reads: “Deny network communications traffic by default and allow network communications traffic by exception.” It appears in the Moderate and High baselines, and its discussion notes that a deny-all, permit-by-exception policy “ensures that only those system connections that are essential and approved are allowed.” Note what is absent. That control is about traffic, enforced by a device, with no human in the loop anywhere. Twenty years of practice put the canonical deny where a machine executes it — which is the argument for putting an agent’s deny in the same class of place, rather than in a dialog box. 05 — The Evidence BaseWhy the prompt stops working — and it takes three exposures. Kind-one default-deny rests on an assumption: that the person answering the prompt reads it. Security research has been measuring that assumption for three decades, across browsers, hospitals, and fMRI scanners, and the results are consistent enough to plan around. The field study everyone should know is Akhawe and Felt’s Alice in Warningland , presented at USENIX Security in 2013, built on 25,405,944 warning impressions from Chrome and Firefox telemetry. Their click-through rates were not uniform, and the variation is the interesting part. The same user population, three very different response rates Akhawe & Felt, USENIX Security 2013 · 25,405,944 impressionsUsers clicked through Chrome’s SSL warning 70.2% of the time and Firefox’s 33.0%, while malware and phishing warnings ranged from 9% to 23%. The paper’s own conclusion is the one to carry: “This implies that the user experience of a warning can have a significant impact on user behavior.” The authors also observed that the most common browser SSL error had the lowest adherence rate, which they read as indicative of warning fatigue. That gap between 33% and 70% could in principle be two different user populations rather than two different designs. Google tested it: a follow-up field experiment ran six experimental warnings through 130,754 impressions in Chrome 29 specifically to see whether design accounted for the delta. This is the fact that keeps this section out of fatalism. Prompts are not uniformly useless; they are design-sensitive. The failure to name is not “confirmation prompts don’t work” — it is “a confirmation prompt that cannot describe what it is confirming doesn’t work”. The same pattern shows up in a domain with much higher stakes and much better-trained operators. A 2006 systematic review of 17 papers, by van der Sijs and colleagues in the Journal of the American Medical Informatics Association , found that “drug safety alerts are overridden by clinicians in 49% to 96% of cases”. The exception in the same review is the most actionable number in this post: high-level overdose alerts were overridden in 27%. Severity-differentiated warnings survive fatigue better than uniform ones. The review also names the conditions that produce override behaviour — low specificity, low sensitivity, unclear information content, unnecessary workflow disruptions, and unsafe and inefficient handling — and every one of those has an obvious agent analogue. Before anyone rushes to add severity labels to their approval prompts, the same research programme supplies a caution. Van der Sijs’s 2009 thesis records that adding seriousness levels to alert text was perceived as helpful but resulted in increased override rates , and that switching off frequently-overridden alerts hospital-wide was not feasible. Labelling the danger is not the same as reducing the clicking. Two more findings finish the picture. Bravo-Lillo and colleagues, at SOUPS 2014, measured habituation directly with a low-habituation control group: “In the absence of attractors, increasing habituation caused a three-fold decrease in the proportion of participants who responded to the change in the dialog.” And they identified what resisted it — not more information, but friction. For the two attractors that “forced the user to interact with the text field containing the change, increasing the level of habituation did not decrease the proportion of participants who responded”. Those designs, they wrote, “appeared resilient to habituation”. The agent translation is direct and slightly annoying to implement: for the actions that matter, make the human type the destructive target rather than press y . The decay is also visible in the brain, not only in the logs. Anderson, Vance, Kirwan, Jenkins and Eargle, publishing in the Journal of Management Information Systems in 2016, combined an fMRI study of 25 participants with an 80-participant cursor-tracking study and found polymorphic warnings significantly more resistant to habituation than conventional ones in attention-related regions of the brain. And the timescale is the number that should change how you design an approval flow: a 2020 review in Frontiers in Psychology , summarising the eye-tracking, cursor-tracking and fMRI work, reports that all of these studies “show decrease attention to warnings after only 2–3 exposure”. Two to three exposures. Not two hundred. There is an agent-specific measurement of the same effect, and because it is a vendor studying its own product it deserves one sentence and a link rather than a re-presentation: Anthropic reported that in a study of 1,053 paid testers, humans caught the dangerous command 13.6% of the time against 89% for its automated checks — we covered that default-permission shift and the study behind it /blog/claude-code-auto-mode-default-permission-model-shift when it landed, and the classifier numbers published later /blog/claude-code-auto-mode-classifier-numbers-published come with dataset caveats that should not be collapsed into a single score. The class-level point is what this post owns: habituation is a measured behavioural and neurological phenomenon across three decades of research, and an agent approval prompt is the same object those studies were measuring. 06 — The Routing RuleRoute by reversibility , not by seniority. So if act-first has a documented cost and ask-first degrades, what decides? The answer is not ours, and it is now written down by a standards body. OWASP published the 2026 edition of its Top 10 for LLM Applications on 4 August 2026, and Excessive Agency moved up from sixth place to third — a rise that reporting attributed to both the expert vote and the incident data agreeing that agentic deployments are where damage is landing. Its complete-mediation mitigation contains the rule. “A graduated enforcement policy audit, warn, block, escalate permits low-consequence or easily reversible actions to auto-approve, while high-consequence or irreversible ones route to human review.”— OWASP, Top 10 for LLM Applications 2026, LLM03:2026 Excessive Agency, published August 4, 2026 That single sentence dissolves the framing this post opened with. The question was never “should the agent ask or act”. It is “which actions should it ask about”, and the key is reversibility. OWASP’s own worked example is deliberately mundane: a customer service chatbot can auto-process a refund as store credit, which is recoverable, while an irreversible external payout routes to human approval. Same agent, same session, two different postures, chosen by the action. The same mitigation adds the constraint that closes the Replit loop: “Implement authorization in logic rather than relying on an LLM to decide if an action is allowed or not.” Eleven ALL-CAPS instructions were exactly an attempt to put authorization in the model. OWASP also separates three root causes that people routinely merge — excessive functionality, excessive permissions, and excessive autonomy — of which posture is only the third. And it is careful about what monitoring buys you: the document explicitly groups monitoring and rate limiting under options that “will not prevent Excessive Agency but can limit the level of damage caused”. Observability is not a posture. Making the rule operational needs two things the standard does not supply: a concrete list of what is actually reversible in a coding-agent context, and a second axis. Here is the first. Cheap to undo: a git-tracked file edit, a new branch, a row in a staging table, an idempotent script, a package install inside a disposable worktree. Not undoable at any price: a force-push over shared history, a DROP , an outbound email, an external payout, a package publish, an infrastructure delete — and, quietly, a credential read. Note that cost and reversibility do not correlate: an irreversible action is often cheap to perform and a reversible one often expensive. Which is precisely why cost is the wrong routing key. The second axis is the one nobody names: observability after the fact . An action you cannot detect having happened cannot be governed by any posture, because you will never know to roll it back. A file edit leaves a diff. A credential read leaves nothing. This is what separates “ask first” from “act first and review after” — the second option only exists if there is something to review. Which is why an audit trail is infrastructure for this decision rather than a compliance afterthought, and why we wrote up agent audit-trail design /blog/agent-audit-trail-design-7-best-practices-2026 as its own subject. Put the two axes together and you get four quadrants, which is the decision matrix this post exists to give you. Read it as a routing table for individual actions, not as a setting for a session. Auto-approve it A git-tracked edit, a new branch, an install inside a disposable worktree, a row in a staging table you can query. Undoing is cheap and the diff is visible, so an approval prompt buys nothing but habituation — and every prompt you spend here is attention you have taken from the prompts that matter. This is the quadrant where OWASP explicitly permits auto-approval. Auto-approve, but alert A cache write, a background job enqueued, a staging-table update nobody watches. Undoing is cheap once you know, so the risk is not the action but the silence. Route it to a log or a channel a human actually reads rather than to a prompt a human will click through, and keep a rollback path close to hand. Ask — and make it cost something A force-push over shared history, a DROP, an rm -rf, a production deploy, a package publish. This is the only quadrant where a human prompt is the right control, and Bravo-Lillo's attractor finding says how to build it: make the person type the destructive target rather than press y. A one-keystroke confirmation here is the theatre this post is named after. Do not grant the capability A credential read, an outbound email, an external payout, an exfiltrating network call. No posture saves you here: you cannot review what leaves no trace, and you cannot undo it once it has. This quadrant is not a posture problem at all — the answer is that the agent's environment should not contain the capability. Which is the whole argument in one cell. Two honest notes on the matrix. First, the reversible column depends on a rollback path that actually exists and has been tested, which is engineering work rather than a setting — checkpoint and rollback patterns /blog/agent-rollback-checkpoint-patterns-2026-engineering-reference is where that lives. Second, the matrix routes by consequence, which is a deliberately different key from confidence. If you have seen action-risk tiering built on how sure the model is, that is a related but distinct approach: our guide to human-in-the-loop escalation design /blog/human-in-the-loop-escalation-design-ai-agents-2026 covers the confidence-calibration route and where the two meet. OWASP’s formulation is the one used here because reversibility is a property of the action that you can determine in advance, and confidence is a property of the model that you mostly cannot. A third factor belongs on the matrix as a modifier rather than an axis: credential reach and network egress. An agent holding a production token, or able to make arbitrary outbound calls, converts almost any action into the bottom-right quadrant, because a prompt injection reaching it can turn a reversible file edit into an irreversible exfiltration. That is the mechanism behind prompt injection in production agents /blog/prompt-injection-production-agents-2026-taxonomy , and it is a second reason OWASP puts authorization in logic rather than in the model: the model is the component the attacker is talking to. 07 — Two EnvironmentsIn CI there is nobody to answer the prompt. Everything above assumes a human is available. In continuous integration, in a cron job, in a background agent, in any headless invocation, that assumption is simply false — and the consequence is that whatever the tool does when nobody answers becomes the production setting. This is where a posture stops being a preference and becomes configuration, and it is why the headless default is the single most important cell in the permission-defaults census /blog/coding-agent-permission-defaults-census . Vendors say as much in their own mode tables. Claude Code’s documentation scopes dontAsk to “Locked-down CI and scripts” and bypassPermissions to “Isolated containers and VMs only”. Both are act-first from the agent’s point of view; they differ entirely in what the machine around the agent will refuse. That is the practical form of the trichotomy from section 04: in headless environments, kind one is unavailable, so you are choosing between kind two and kind three, and only kind three has a floor. The other thing to know about headless posture is that the dial can move under you. On 20 August 2026, OpenAI merged pull request 39630 to the Codex CLI, titled “Retire the untrusted approval policy”, and shipped it in v0.149.0. Per the PR body, it removes untrusted “from the CLI, configuration schema, and MCP tool interface”, and an explicit approval policy = "untrusted" setting now fails at startup with an actionable error. The current value set is on-request , never , and a granular table form; on-failure is deprecated. One semantic detail is worth pinning because it is easy to get backwards: in the granular form, false means auto-reject — fail closed — not auto-approve. Read the PR carefully and it is not a loosening in isolation. It also states: “Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.” That is stricter, and it makes a point worth internalising — the built-in safe-command allowlist was itself a posture decision your vendor made on your behalf, and it can be withdrawn. Our Codex CLI configuration deep dive /blog/codex-cli-deep-dive-config-profiles-sandbox-2026 carries the verified config detail; third-party mirrors of these docs disagree with each other and should not be treated as vendor documentation. untrusted value as supported. Issue 39973, filed against OpenAI’s own repository, argues the removal is not a neutral migration: on a project marked trusted, the effective default silently becomes on-request — a materially weaker approval boundary — arrived at via an error message telling users to delete the line. This is the theatre argument happening in production, at a major vendor, on a setting people rely on. A sibling post today covers the separate phenomenon of vendor documentation contradicting shipped behaviour; the parallel is real, and one sentence of it is enough. 08 — The Legal FloorThe regulated case, with the scope stated correctly. In some environments the posture is not entirely yours to choose, and the relevant instrument is more precise than most summaries of it. What follows is read from the consolidated text of Regulation EU 2024/1689 — the EU AI Act, CELEX 32024R1689 — on EUR-Lex, retrieved 30 August 2026. Article 14 Human oversight applies from 2 August 2026 under the general rule in Article 113, which states that the Regulation “shall apply from 2 August 2026”. Article 14 sits in Chapter III, Section 2, which is not inside the Article 113 b carve-out that pulled some provisions forward to 2 August 2025. Now the scope trap, because it is the easiest thing in this area to state wrongly. Article 113 c defers Article 6 1 — high-risk classification for AI systems that are safety components of products already covered by Union harmonisation law, listed in Annex I — to 2 August 2027. Article 6 2 , which covers the Annex III high-risk use cases, is not deferred. So the widely repeated claim that “high-risk obligations start in August 2026” is true for Annex III systems and false for Annex I product-safety systems. If you write that sentence, name which one you mean, or do not write it. Automation bias, named in binding text High-risk systems must be provided so that overseers are enabled “to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system automation bias , in particular for high-risk AI systems used to provide information or recommendations for decisions to be taken by natural persons”. The warning-fatigue literature says humans click through; a regulator has legislated against that exact failure, by name. The right to reverse the output Oversight must enable a person “to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output of the high-risk AI system”. Reversibility appears here as a required property of the oversight arrangement — the same axis OWASP's graduated-enforcement rule routes on, arrived at independently. Proportionality, in law Oversight measures “shall be commensurate with the risks, level of autonomy and context of use” of the system. That is the proportionality principle this post argues for on engineering grounds, stated as a legal requirement: a uniform posture applied to every action is not what the text asks for. Two cautions before anyone reaches for this in a compliance document. First, none of the incidents in section 02 involves a system that has been classified as high-risk under this Regulation; the Articles above tell you what oversight must enable where they apply, not that a coding agent falls in scope. Second, the mapping work between Article 14 and an actual approval design is a subject of its own — our approval-gate framework and governance guide /blog/agentic-workflow-approval-gate-framework-governance carries the crosswalk and the gate taxonomy, and oversight patterns for regulated industries /blog/agentic-ai-regulated-industries-oversight-patterns covers the operating model around it. What belongs here is only the observation that the legal text and the security research point the same way: proportionate, action-specific, and sceptical about whether a person clicking a button constitutes oversight. 09 — The MigrationHow teams actually move between the two. Most teams do not choose a posture once. They start ask-first because it feels responsible, drift toward act-first because the prompts became noise, and then discover the drift after an incident. Making that transition deliberate is mostly a sequencing problem, and the order matters more than the individual steps. Move capability before you move posture. If you are going from ask-first to act-first, the thing that has to change first is what the agent can reach — the credentials in its environment, the directories it can write, the databases its connection string resolves to. Replit’s own remedy was dev/prod separation with the agent restricted to development by default; that, not a better prompt, is what makes act-first survivable. The same logic applies to the buying decision, which is why the standing-access review checklist /blog/agent-tool-access-authorization-review-checklist-2026 asks where the agent runs and what offboarding revokes before it asks anything about prompts. Assume your allowlist is not in force everywhere yet. Kind-two deny is configuration, and configuration propagates unevenly. Claude Code’s settings documentation is explicit that allow rules and additional directories take effect only after each teammate trusts the folder, while deny and ask rules apply immediately. A team that has agreed a posture in a settings file has not yet deployed it — which is a migration fact, and one of the better arguments for expressing critical restrictions as deny rules rather than as the absence of an allow. Instrument before you loosen. Act-first only means “review afterwards” if there is a record to review. Before moving any category of action from ask to act, confirm it lands somewhere durable, and confirm you can tell the difference between an action the agent took and one a person took. If a class of action cannot be reconstructed after the fact, it belongs in the bottom-right quadrant regardless of how reversible it looks. Then test the posture you chose, adversarially. The failure modes in section 02 were not model errors; they were an attacker or a misconfiguration meeting an agent that would act. That is a testable property. A one-week agent red-team exercise /blog/agent-red-team-exercise-one-week-playbook is a reasonable way to find out what your configuration actually permits, and the supply-chain vector in particular deserves its own attention given how agent skill packs and package ecosystems /blog/agent-skill-packs-package-ecosystem-supply-chain-risk now reach into the same machines the agents run on. Finally, one posture change worth making immediately in either direction: stop putting instructions in the prompt and expecting them to hold. Eleven ALL-CAPS warnings did not hold. OWASP’s phrasing is the rule to adopt — authorization in logic, not in the model. Every restriction that matters should be expressible as something the machine will refuse, and everything else should be understood for what it is: a preference the agent will usually respect. 10 — ConclusionIs the thing that says no a person or a machine? The posture belongs to the action, not to the session. The question in the title has a plain answer, and it is not one of the two options. Ask first for actions you cannot undo and cannot see afterwards — and for those, make the confirmation cost something more than a keystroke. Act first for actions that are cheap to reverse and visible in a diff, because every prompt you spend there is attention taken from the prompts that matter. That is OWASP’s graduated-enforcement rule, and it is also, in different words, what the EU AI Act asks for when it requires oversight commensurate with risk, autonomy and context of use. The deeper reframe is the one the evidence keeps pointing at. Default-deny is theatre exactly when the “no” lives in a place that habituates — a dialog a person clicks after the second or third exposure, or, in Kiro’s documented case, a review that arrives after the write has already hit disk. Default-allow is reckless exactly when the capability behind it is unbounded, which is why both 2025 attacks and both vendor remedies converged on the same answer: what the agent can reach matters more than how often it asks. AWS says supervised mode is not a security control. Replit’s fix was a second database, not a firmer prompt. All of which is scoped, deliberately, to coding and tool-using agents — every incident cited here is one. If you are running a business-process agent, the reasoning may well transfer, but the sourced record does not yet, and we would rather say so than imply a generality we cannot support. What does transfer is the discipline: enumerate your agent’s irreversible actions, check which of them leave no trace, and move those out of the prompt and into the architecture. Then loosen everything else, and stop asking your team to be the security control.