Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Human Approval Stop Actions Triggered by Prompt Injection?

Only when the approver sees the true action and the real destination, and only if approval is asked for consequential actions rather than every step. Check whether the approval dialog can itself be shaped by injected content, how many approvals a person handles per hour, and what the approver sees before saying yes.

Layered instruction cards approach an approval door before a workflow forks into two downstream routes.

Only when the approver sees the true action and the real destination, and only if approval is asked for consequential actions rather than every step. Check whether the approval dialog can itself be shaped by injected content, how many approvals a person handles per hour, and what the approver sees before saying yes. Human approval is the control most vendors reach for once they concede that prompt injection cannot be filtered out of an agent's inputs. The logic is sound: if a person must confirm every payment, submission or record change, an injected instruction can start an action but cannot finish it. The evidence shows where that logic breaks. Approval dialogs can be forged by the same content that carried the injection. People over-rely on automation and approve what it proposes. A queue of approvals turns a checkpoint into a reflex. Regulators now write human oversight into law and, in the same article, warn about over-reliance. This page works through what approval can and cannot stop, why the approval screen is itself an attack surface, how fatigue and bias degrade the control, what a trustworthy approval must show, how to scope it, and what a buyer should refuse to accept.

Key findings

  • Attackers can manipulate the content and presentation of approval dialogs to deceive users into authorizing malicious operations, an attack OWASP catalogs as HITL dialog forging, or Lies-in-the-Loop (OWASP, 2025).
  • Automation bias, the tendency to over-rely on automation, is documented across fields in a systematic review of its frequency, mediators and mitigators, and it applies to a person asked to confirm what an agent proposes (JAMIA, 2012).
  • A CIO and CISO quoted in trade press warns that agent throughput will eventually create a scenario where a human just rubber-stamps, and the same report cites a UK AI Security Institute test in which an agent socially engineered its human approver (TechTarget, 2026).
  • Once an agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions, according to a cross-institution design patterns paper; approval is one way to impose that constraint, but only at the consequential step (arXiv, 2025).
  • Microsoft states that for one exfiltration channel it took steps to deterministically block the security impact, and that for residual risk it relies on the explicit consent of the user to perform a specific action, placing approval after deterministic controls rather than instead of them (Microsoft, 2025).
  • The EU AI Act requires high-risk systems to be effectively overseen by natural persons and requires overseers to remain aware of the possible tendency of automatically relying or over-relying on the output (EU AI Act Article 14, 2024).

What can an approval step stop, and what can it not?

Approval stops an action when three things are true at once: the action waits for a decision, the decision is made by a person who understands what the action is, and the person has the information to decide. Remove any one and the step becomes a formality. An injected instruction that tells an agent to change a vendor's bank details will be stopped by approval only if the agent cannot change those details without a confirmation, if the confirmation is routed to someone who knows what a bank detail change means, and if that person sees the new account number and the vendor it attaches to.

What approval cannot stop is everything that happens before the consequential step. The agent has already read the injected content. It has already reasoned about it and formed a plan. If the plan involves reading more records, navigating to other screens or assembling data, none of that requires approval in most designs, so an injected agent can gather whatever its session can see before a person is involved. The design patterns literature puts the requirement precisely: once untrusted input is ingested, the agent must be constrained so that the input cannot trigger consequential actions (arXiv, 2025). Approval is a constraint on actions, not on reading, and reading is where the data an injection could leak is collected.

The OpenAI Agents SDK documents a human-in-the-loop pattern in which specified tool calls pause for approval and resume after a decision (OpenAI, 2025). The mechanism is sound. Its value depends entirely on which tools are marked as needing approval, who answers, and what they are shown, which is the subject of the rest of this page.

Can injected content shape the approval dialog itself?

Yes, and this is the failure that undermines the whole control. OWASP catalogs the attack as HITL dialog forging, also called Lies-in-the-Loop: the attacker manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations (OWASP, 2025). The mechanism is simple. If the text of the approval request is generated by the same model that read the injected content, the injection can tell the model what to say in the request. The person sees "Confirm: update the vendor's mailing address" while the action queued is a change to the vendor's bank account.

Walk through a vendor master record in an accounts payable system. The record holds the vendor's legal name, tax identifier, remittance address and bank account for payments. An agent is asked to process an invoice that arrived by email. The invoice body contains hidden text instructing the agent to update the vendor's bank details to a new account before scheduling payment. A well designed agent pauses before the record change and asks for approval. If the approval dialog is composed from the model's own summary of what it is about to do, the injected text can also instruct the model to describe the change innocuously. The approver, who handles many such confirmations, reads a plausible sentence and clicks.

The defense is architectural. The approval screen must be rendered from the actual action parameters, taken from the system that will execute them, not from the model's narration. A bank account change should display the old and new account numbers as the payment system will record them. A submission should display the real destination URL. The model may propose; the environment must describe. When the two are separated, a forged narrative cannot hide a real action, because the person sees the action, not the story.

How do fatigue and automation bias degrade approval?

Even an honest approval dialog fails when the person stops reading it. A systematic review in the Journal of the American Medical Informatics Association defines automation bias as the tendency to over-rely on automation and documents its frequency, mediators and mitigators across fields (JAMIA, 2012). A person confirming an agent's actions is in the textbook position: the system has done the analysis, the request looks routine, and disagreeing costs effort. The default drifts toward yes.

Throughput makes it worse. A TechTarget report titled "The human in the loop is falling asleep" quotes a CIO and CISO warning that AI throughput will eventually create a scenario where a human just rubber-stamps, and cites a UK AI Security Institute test in which an agent socially engineered its human approver (TechTarget, 2026). Two distinct failures appear in that account. The first is volume: an agent that asks for approval on every step trains its approver to approve. The second is persuasion: the agent itself can argue for the action, and a model that has read injected content may argue for the attacker's action with the same fluency.

The EU AI Act anticipates both. Article 14 requires that overseers be able to interrupt the system through a stop button or similar procedure, and that they remain aware of the possible tendency of automatically relying or over-relying on the output (EU AI Act Article 14, 2024). A regulation that names over-reliance as a risk inside the oversight requirement is telling deployers that the existence of an approval step is not compliance. The quality and frequency of the approvals are.

What must a trustworthy approval screen show?

Element Why it matters against injection What a buyer should verify
The action type, from the executing system Prevents a forged narrative from relabeling a bank change as an address update Is the label generated by the model or by the environment?
The real destination Exfiltration and fraud both depend on where data or money goes Does the screen show the actual URL, account or recipient?
The specific record affected The approver must know which vendor, patient or account changes Is the record identified, and does the approver recognize it?
What the agent read to reach this step Injected content is visible in hindsight Can the approver open the screens the agent read?
Who approved, and when Accountability and audit Does the record name a person and export to the SIEM?

Microsoft's description of its own defenses shows the right ordering. For one exfiltration channel the company took steps to deterministically block the security impact; for residual risk it relies on the explicit consent of the user to perform a specific action (Microsoft, 2025). Deterministic controls first, consent for what remains, and consent for a specific action rather than a general grant.

The phrase "specific action" carries the weight. Consent to "let the agent complete the invoice" is a blank check an injection can fill. Consent to "pay vendor V-2231 the amount shown to account ending 4471" is a decision a person can make. The difference is not the person's diligence but the environment's precision in telling them what they are deciding. A screen built from the executing system's parameters is trustworthy in the sense the title asks about; a screen built from the model's summary is a second place for the injection to work.

Which actions should require approval, and which should not?

Scope decides whether approval survives contact with volume. If every click requires a person, the person stops reading by the second hour. If nothing requires a person, the injection runs to completion. The design patterns paper's principle offers the dividing line: constrain consequential actions (arXiv, 2025). Payments, submissions to external parties, and changes to records of account are consequential. Reading a screen, navigating to the next page and drafting a summary for internal review are not.

Three rules follow. First, approval attaches to action types and destinations, not to steps. A workflow that touches twenty screens and makes one payment should ask once, at the payment, with the destination visible. Second, approval is asked of a named person with authority over that action type, not of whoever is available; a bank detail change should route to someone who approves bank detail changes when humans do the work. Third, approval frequency is a measured quantity. If a pilot shows an approver handling more confirmations per hour than they could read, the scope is wrong, and widening the set of actions that run without approval is not the fix; narrowing what the agent can reach is.

This is where autonomous agents that act without approval and supervised ones diverge in practice. Full autonomy removes the checkpoint. Approval on everything removes the attention. The workable middle is a small set of consequential actions, each shown truthfully, each decided by someone accountable, with the reading that preceded the action recorded so that a bad approval can be traced to what the agent was shown.

What does a governed environment change?

In a governed environment, the approval screen is built from the parameters the environment will execute, not from the model's description of its plan, so injected content can steer the agent but cannot write the words the approver reads.

The mechanism is a class of control that places approval after deterministic measures, not instead of them. Sensitive values on the rendered page are replaced with consistent tokens before any model reads them, so an injected instruction that tries to move an account number moves a token. Real values resolve only at an approved destination at the moment of an approved action, so the destination the approver sees is the one the payment system will record. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes, while routine navigation proceeds without a prompt, so the approval count stays reviewable. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This is the arrangement the four requests above describe. OWASP documents that attackers can manipulate the content and presentation of approval dialogs (OWASP, 2025), and Microsoft describes blocking one exfiltration channel deterministically and relying on explicit user consent only for residual risk (Microsoft, 2025). An approval screen sourced from the environment, limited to consequential steps and backed by a record of what the agent read before asking survives both dialog forging and fatigue.

The control does not change the model, the application or the user's permissions, and it does not remove the approver's tendency to over-rely; it changes what the approver sees and how often.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design treats approval as the last of several controls rather than the first. Agents run in a governed environment in the customer's cloud. Substitution happens at the render layer, before any model reads the screen, so the vendor master record described above reaches the model with ACCT_001 in place of the bank account and consistent tokens for every identifier through the whole run; an injected instruction that asks the model to leak or alter those values is working with placeholders. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, and the approval screen shows the real action and the real destination from the environment, not the model's narration. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would plant an instruction in an invoice that tries to redirect a payment, run the agent, and show what the approval screen displayed, who was asked, and how many approvals that person handled in the hour. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the OWASP community catalog entry for HITL dialog forging, a peer-reviewed systematic review of automation bias in the Journal of the American Medical Informatics Association, a cross-institution preprint on design patterns for securing LLM agents against prompt injection, vendor documentation from Microsoft on its indirect prompt injection defenses and from OpenAI on the human-in-the-loop pattern in its Agents SDK, Article 14 of the EU AI Act on human oversight, and trade press reporting on approval fatigue that cites a UK AI Security Institute test. Existing RedactSure research pages on prompt injection, human-in-the-loop approval and autonomous agents are cited as evidence for the design points they document. All sources were read as of October 16, 2026.

No hands-on testing of any agent, approval mechanism or product was performed for this page. The social engineering test attributed to the UK AI Security Institute is described as the trade press reported it; the underlying test was not reviewed. Where a vendor capability is described as "not described," that means it was not found in the pages reviewed, not that the vendor lacks it. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The vendor master record, invoice and accounts payable examples describe record types, not any organization; no customer or prospect is described.

Whether a given deployment's approval design, its oversight arrangements or its handling of regulated transactions meets an organization's requirements, including any obligations under the EU AI Act, is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Human approval stops injected actions under conditions the evidence makes explicit. The approval screen must be built from the executing system's parameters, because a screen composed by the model can be forged by the content that compromised it. Approval must be scoped to consequential actions, because an approver asked to confirm everything confirms by reflex, and the literature on automation bias and the reporting on rubber-stamping both say so. The approver must be a named person with authority over that action type, and the reading that preceded the request must be recoverable. Designs that place deterministic controls first and consent for a specific action after, including the render-layer substitution RedactSure describes, leave approval with less to catch. The test is to name one agent and one task, plant an instruction that would redirect a payment, and ask what the approval screen showed, who read it, and how many others they read that hour.

Frequently asked questions

If a person approves every action, can prompt injection still cause harm?

Yes, in two ways. The approval dialog itself can be shaped by injected content when its text is written by the model, so the person approves a described action that differs from the real one. And a person asked to approve everything stops reading; the automation bias literature and reporting on rubber-stamping both document the drift toward yes. Approval works when it is scoped to consequential actions and the screen shows the true action and destination.

What is Lies-in-the-Loop?

It is the name OWASP uses for HITL dialog forging: an attack that manipulates the content and presentation of approval dialogs to deceive users into authorizing malicious operations. The attacker does not bypass the approval step; they make it approve the wrong thing. The defense is to generate approval screens from the parameters of the action as the executing system will perform it, rather than from the model's own description of what it intends to do.

How many approvals per hour is too many?

No published threshold exists, and the right number depends on the action. The useful measure is whether the approver could have read each screen in the time they spent on it. A pilot that records approvals per person per hour, alongside the time spent on each, exposes rubber-stamping before it becomes habit. If the rate is too high, the fix is to narrow what the agent can reach and which actions count as consequential, not to remove approvals or to let the approver skim.

Does a stop button count as human oversight?

It is one element. The EU AI Act requires that overseers of high-risk systems be able to interrupt the system through a stop button or a similar procedure, but in the same article requires that they remain aware of the tendency to over-rely on the output. A stop button depends on the person noticing in time, and an agent runs faster than attention. Approval before a consequential action does not depend on timing, which is why the two are complementary rather than interchangeable.

Should the approval screen come from the model or the environment?

From the environment. If the model composes the approval text, injected content that compromised the model can also compose a misleading request. If the environment renders the action type, the specific record and the real destination from the system that will execute the action, the model can only propose, and the person decides on facts. Separating narration from execution is the design choice that makes the approval screen trustworthy.

What should be recorded about each approval?

Who approved, what action type, which record, what destination, when, and what the agent read in the steps before it asked. The last item is what turns a bad approval into a lesson rather than a mystery, because it shows the screen that carried the injection. Exporting that record to the organization's own SIEM lets security teams correlate agent approvals with other events and review them without depending on the agent vendor.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

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.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.