Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Which Coding Agent Actions Need a Human Approval?

Approve four things: the first use of a credential, anything that spends money, anything irreversible such as a delete, force push or production deploy, and anything outside the grant. Everything else should run under the grant, and the list should be written down before the run begins.

A credential reference travels from a browser record through a bounded route to a separate API destination.

An approval dialog is cheap to add and expensive to get wrong in both directions. Ask for too much and the reviewer clicks through; ask for too little and a force push lands on the main branch on a Friday afternoon. The line that holds is drawn by the action rather than by the tool, and it survives a change of agent: four kinds of action stop for a person, everything inside the authority the run already carries proceeds, and the argument turns on keeping that authority narrow enough to be worth trusting.

This page states the four items, then tests them against what five vendor pages document about approvals, credentials, identity and spend. It works one record type throughout, a four-item approval list attached to a repository settings page, and it closes on the control class that makes such a list auditable rather than aspirational. The distinction that matters at each step is between what an agent may do and what its model was shown when the action was proposed. The four items also work as a test on any tool: name one action the agent takes, then ask which of the four it is and what the run would have to record to prove it.

Key findings

  • Cursor's Agent Security page states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," which puts the prompt on a command or a connection and leaves a first credential use, a spend and a production deploy outside it (Cursor, 2026).
  • OpenAI's Codex documentation asks for approval "to edit files outside the workspace or to run commands that require network access," a boundary rule rather than a list of consequential actions, and it does not describe how credentials are stored in a local session (OpenAI, 2026).
  • Stripe's documentation states that restricted keys tagged for an autonomous agent "are automatically subject to approval rules," with a designated reviewer for payouts, refunds and configuration changes, the spend item handled at the key (Stripe, 2026).
  • FINRA's 2026 oversight report, as summarized by Debevoise & Plimpton, flags that agents "may act without human validation and may take actions that exceed the user's actual or intended scope or authority," the argument for the fourth item (Debevoise & Plimpton, 2026).
  • A governed environment replaces the values on a screen with consistent tokens before any model reads it, so an agent proposing a key rotation works from DEPLOY_004, never the key itself (Does an AI Agent Need Human Approval Before It Takes Action?).
  • Real values resolve only at the approved destination, when a named person approves the action, and every approval with that name is written to a record that exports to the organization's own monitoring (What Is an AI Control Record?).

Which coding agent actions belong on a four-item approval list?

The four items are the first use of a credential, anything that spends money, anything irreversible, and anything outside the grant. They are stated for actions an agent takes on a rendered page, because that is the surface an environment can govern: a repository settings page, a cloud console, an issue page. A governed browser environment covers what the agent reads and does there, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Each item appears on a page as often as in a shell: a deploy key is rotated on a settings page, a spending cap is raised in a billing console, a release branch is deleted from a repository page.

Each item is a decision. The first use of a credential settles the scope, destination and lifetime that later calls inherit, which is why the tenth call needs no prompt. A spend commits a card or a budget line. An irreversible action removes what a rollback cannot restore: a delete, a force push over shared history, a production deploy that replaces what is serving traffic. Anything outside the grant is the residual item, for destinations the grant did not name.

The example is a four-item approval list on a repository settings page. Item one, rotate the deploy key and use it for the first time. Item two, raise the continuous integration spending cap. Item three, delete the release branch the last production build came from. Item four, add an outside collaborator with write access. A person approves each, and the rest of the run proceeds on the authority it already carries.

The criterion is reversibility rather than severity. Whether a deleted branch comes back depends on a retention setting, whether a force push can be undone depends on a copy elsewhere, and whether a deploy rolls back depends on the previous artifact still existing. Those are questions with answers a person can check before answering the prompt.

Why does a short approval list beat approving every action?

A prompt that repeats the same shape stops carrying information. A person who sees the same approve button fifty times in a morning spends attention on the first few and pattern-matches the rest, and an action crafted by an attacker is built to look like the rest. The case for four items is not that four approvals are faster than fifty, though they are, but that four approvals can each be read.

The vendor defaults show where prompts currently land. Cursor's documentation states that "by default, terminal commands need your approval" and describes its run modes as "best-effort guardrails rather than a hard security boundary," so the default prompt follows the tool rather than the consequence (Cursor, 2026). A prompt per command makes a person the rate limiter for an agent that never tires, and the job attracts the least attention at the moment it needs the most.

A long list also feeds the attack it is meant to stop. OWASP catalogs human-in-the-loop dialog forging, in which the content and presentation of an approval dialog are manipulated so the user authorizes a malicious operation, and a person trained to click without reading supplies exactly that authorization (Does Human Approval Stop Actions Triggered by Prompt Injection?).

The four items survive both problems because each is a decision the automation cannot make on its own. A rule can decide whether a command matches a pattern; it cannot decide whether this deploy is the one that should wait for a named reviewer. That judgment needs context a person holds and the model does not, which is why the list stays short enough to keep in mind.

What do the vendors themselves say?

Each page below places the decision somewhere other than the four items.

Cursor's Agent Security page states that "by default, terminal commands need your approval" and that "all MCP connections need your approval," and it describes its run modes as "best-effort guardrails rather than a hard security boundary," while not describing how credentials are stored or protected (Cursor, 2026).

OpenAI's Codex documentation states that "locally, Codex uses an OS-enforced sandbox that limits what it can touch" and that "by default, the agent runs with network access turned off," which places the control on the sandbox and the network rather than on a list of actions, and it does not describe credential handling inside a local session (OpenAI, 2026).

The 1Password and Browserbase announcement states that "Secure Agentic Autofill allows AI agents to authenticate with web services without ever exposing credentials" and lists "Human-in-the-loop authorization: Real-time approval prompts via 1Password mobile or desktop," with no technical detail on how the injection works, so it documents an approval at authentication, not a list of actions (1Password and Browserbase, 2025).

Stripe's API keys page states that a live secret key is displayed "one time" and that restricted keys tagged for an autonomous agent "are automatically subject to approval rules," a spend control at the key that does not reach a delete, a force push or a production deploy (Stripe, 2026).

Teleport's Agentic Identity Framework states that "your agents need a verifiable, cryptographic identity tied to where they're running, not a shared API key" and marks most of the capabilities it lists as in progress or not started, so it argues for an identity an approval could attach to (Teleport, 2026).

Dimension Cursor, per its documentation What a buyer should verify
What triggers a prompt Terminal commands and MCP connections, by default Whether the prompt follows the action or the tool
First use of a credential Not described Which approval covers the first call and what it names
Spend Not described Whether payouts and billing changes have a designated reviewer
Irreversible action Not described Whether delete, force push and production deploy stop
Outside the grant Run modes called "best-effort guardrails rather than a hard security boundary" Whether a new destination is refused or only logged
Record Not described Screens read, actions taken, approver by name

Which actions are irreversible enough to stop?

Irreversibility is a property of the record, not of the verb. A delete removes an object and may leave a copy in a retention tier; a force push replaces shared history and may survive in a developer's local clone; a production deploy replaces what is serving traffic and may roll back from the previous release. The question at the approval is what restoring the old state would take, and for many actions nobody in the room knows.

Dependency changes belong on the list for the same reason. Datadog's 2025 report states that "throughout 2024, Datadog identified thousands of malicious PyPI and npm libraries in the wild," which makes an install a change to code that will run rather than a change to a list (Datadog, 2025). Removing the package afterward does not undo what it did while it was installed.

Verizon's 2026 report states that "of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in," which moves the question from who holds a password to what a change puts into production (Verizon, 2026). The deploy is the last gate a change passes before it faces the internet, and it is the cheapest place to stop a bad one.

A launch sequence shows how many commitments hide inside a single task. Five of the steps in a GPU instance launch commit the account to something a rollback cannot recover, and those five are the ones that stop for a person (How to Use AI Agents to Launch an EC2 GPU Instance). An account setup goes further: an agent given a root key holds a credential that no approval list can bound, which is why the cloud reference tells teams not to create root access keys at all (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?).

Where does an agent act outside its grant?

A grant is a statement of scope, and the failure it invites is scope wider than the work. OWASP's Top 10 Non-Human Identities Risks defines secret leakage as the "leakage of sensitive NHIs such as API keys, tokens, encryption keys, and certificates to unsanctioned data stores," and its fifth entry covers overprivileged identities (OWASP, 2025). An agent holding a write token it never needs is overprivileged in that sense whether or not it ever misuses the token.

The pattern appears first at setup. Google's security guidance for Workspace administrators states that the super admin account should be used only when needed, a rule written for people that applies with more force to an agent that can open a settings page (Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool?). An agent that signs in as an administrator to change one setting carries a grant that covers every other setting on that page.

Attribution is what makes an outside action reviewable afterward. Teleport's framework offers "Comprehensive audit trails and behavior analysis for agent actions across infrastructure," the property that would put an agent's name on an action that exceeded its grant (Teleport, 2026). The fourth item on the list catches all of this, and the approval that admits an outside action is also the moment to narrow the grant rather than extend the run.

What does a governed environment change?

It changes where the decision sits and what the person deciding is shown. In an ungoverned run the model reads the screen and the approval arrives afterward or not at all, and the person approves a description the model itself wrote. In a governed environment, values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model proposes an action from the token and the approver sees that token on that screen.

Three properties follow. A named person confirms what is tokenized before the run and approves each consequential action while it is pending, which is Supervised Delegation and what makes a four-item list enforceable rather than advisory. Real values resolve only at the approved destination, at the moment of the approved action, so a deploy key reaches the settings page the person approved and never the transcript. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question, the difference is what an approval is an approval of. A list in a policy document records an intention, and a prompt that shows an action description records the model's own account of what it is about to do. A list enforced at the render layer records a decision, with the token the model saw and the name of the person who answered for it. That is the property that lets four items survive an audit and a new engineer.

Methodology and limitations

This page rests on five vendor documentation pages, a law firm summary of a regulator report, a standards entry from OWASP, two industry reports and existing RedactSure research pages. Quoted facts are cited to the page that states them and are given as that page words them, and figures from industry reports are cited as reported rather than as independently measured. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. They were read for what they say about approvals, credentials and identity rather than for what they leave out.

RedactSure did not test any of the named products hands-on. Where a page is silent on a point this page relies on, that silence is reported as silence and not as evidence that the behavior is absent. Vendor features change, and the page carries its date, so a release after that date is unreviewed until the test at the end is repeated. That is a limit of the record, not a finding about any product. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a four-item approval list on a repository settings page, and not an organization.

Determinations about whether an approval flow meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test of the organization's own agent against its own list, repeated after each release. A team that keeps that test and its record together has an answer for the reviewer who asks why an action ran without a person, and for the one who asks why it stopped.

What the record shows

Four items carry the argument, and each is a decision a person can still make after the run has started: the first use of a credential, a spend, an irreversible action, and anything outside the grant. The vendor pages show where those decisions sit today, on a command, a connection, a sandbox boundary or a restricted key, which is close to the action and short of the consequence. The research record shows what a long list costs: prompts get clicked, dialogs get forged, and an overprivileged identity turns one approval into many. What a governed environment adds is the record of what the model saw when it proposed the action; RedactSure's environment is built on that property. Before relying on the list, a team should name one agent and one task, predict which of the four items it would stop for, then run the task and compare what it did against that test.

Frequently asked questions

Which coding agent actions need a human approval?

Four kinds: the first use of a credential, anything that spends money, anything irreversible such as a delete, a force push or a production deploy, and anything outside the grant. Everything else runs on the authority the grant already carries. The list stays short on purpose: a person who reads four decisions in a morning reads them, while a person who clears fifty prompts in a morning learns to click. Write the four items down before the run starts.

Can one approval cover a whole task?

Yes, if the approval names what the task may do: which credential, which destination, which operations, and how long the authority lasts. That is what separates a grant from a prompt at every step, and it is why a task inside its terms should not interrupt anyone. The limit is the fourth item, since an operation or a destination the grant did not name sits outside it and needs its own approval. The value of the grant is in those terms rather than in the click.

Does a sandbox replace the approval list?

No. A sandbox bounds where an agent's commands can reach, which OpenAI's Codex documentation describes as an OS-enforced sandbox that limits what it can touch. A bound is not a decision about consequence: a command inside the sandbox can still delete a branch, raise a spending cap from a settings page, or force push over shared history. The sandbox narrows the radius, and the four-item list decides which actions inside that radius wait for a person. The two controls answer different questions, and a team needs both.

Why does the first credential use need its own approval?

Because it is the moment the terms are set. The scope, the destination and the lifetime that later calls inherit are chosen there, so the first approval decides what the tenth call may do. Later calls inside those terms spend a decision already made. A team that approves every call but never the terms has approved the volume rather than the range, and the range is what an audit and an incident review will ask about.

What should an approval record contain?

The action proposed, the screen the model read when it proposed it, the token or value the action was about, the name of the person who approved or refused, and the time. A record that holds only the action cannot answer whether the approver saw what the model saw. Ask for the screen and ask for the name, because a role such as reviewer or owner identifies nobody after the fact. A screenshot of the dialog is not that record.

How does a team start without creating approval fatigue?

Start by counting what currently stops and why. Most defaults stop per command or per connection, which produces volume without consequence. Move the stops to the four items, write the grant for everything else, and review the list after a month against the actions that actually ran, including the ones that surprised nobody. A stop that has never changed an outcome belongs inside the grant, and an incident that surprised the team means an item is missing from the list.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Makes a Four-Item Approval List Enforceable

The vendor controls reviewed decide what an agent may do and record the action afterward, while the approver reads a prompt written in the model's own account.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before, the agent reads the deploy key on the repository settings page and proposes the rotation in a prompt of its own wording. Inside the governed environment the page renders DEPLOY_004 instead, and the approver's decision is recorded beside the screen the model read.

RedactSure is deploying now with enterprise and government customers. Cursor calls its run modes "best-effort guardrails rather than a hard security boundary."

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An approval list is only enforceable when the agent does not write the prompt. Bring a rotation your team approves and see, with test values, the decision recorded beside the screen the model read. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.