Science1 publisher3 min readPublished
OWASP catalogues an attack that forges the approval dialog guarding AI agents
The write-up names three ways attacker-controlled text can reshape what an approval prompt shows, and cites one Checkmarx demonstration against Claude Code. It carries no measure of how often a doctored dialog actually fools a human.
The Scientist · Science desk
What happened
- OWASP has published a community entry for HITL Dialog Forging, also called Lies-in-the-Loop, in which the content and presentation of an approval dialog are manipulated so users authorize malicious operations that look benign.
- The mechanism is indirect prompt injection: because the agent's proposed operation comes from untrusted content such as web pages, GitHub issues, emails and documents, so does the dialog text describing it.
- Three vectors are listed, including Markdown and HTML injection that dresses attacker text as agent-generated interface elements, and tampering with the one-line action descriptor shown to the user.
- The listed risks include attacker-controlled agent output shown to users, such as failed tests presented as passed, alongside approval of harmful actions.
Compiled by The ScientistSomething wrong?How this is made
Why it matters
- constraint A threat model that leans on human approval to catch injection is drawing its assurance from the same channel the attack arrives on, which limits how much that step can be scored as an independent check.
- decision The buying question about an agentic coding tool changes from whether it asks permission to how the permission prompt is built: who renders it, and whether model-authored markup reaches the screen.
- exposure Anyone able to file an issue in a repository an agent reads is inside the trust boundary of whoever clicks approve, without needing credentials of their own.
- precedent A named entry in the OWASP catalogue gives pentest scopes and vendor questionnaires something to cite, so dialog integrity becomes a line item rather than a researcher's curiosity.
The uncomfortable part is where the approval text comes from. An agent reading a web page, an email, a document or a GitHub issue builds its proposed action out of that content, and the dialog describing the action inherits the same provenance [3]. The human is then asked to check a claim using evidence supplied by whoever wrote the claim. Padding is the crudest form of this: enough whitespace, and the agent's own warning is pushed outside the user's view [5]. OWASP also notes that the dialog is usually the only feedback the user gets [12], which is why tampering with a one-line action summary is worth an attacker's time [6].
What the page does not carry is a rate. There is no count of users shown a forged dialog, no comparison against a clean one, and no breakdown by dialog design [14]. That absence matters most for the user-facing advice: "pay attention to details" [9] has no effect size attached to it, because nobody has published what attention buys. The Checkmarx Zero result is a single agent and a single path, from a GitHub issue to remote code execution in Claude Code [7]. It sits under a heading called Real-World Incidents, but what it establishes is capability, not incidence: a demonstrated path shows that the door opens, without telling you how many people are walking through it.
Count the mitigations and the structure of the problem shows up in the arithmetic. Two of the eight listed items are addressed to users; six are addressed to developers [13]. The developer items are the ones that remove the vector rather than asking someone to notice it: dialogs constructed and rendered by a dedicated function that only processes formatting the developers supplied, with markdown from the model left unrendered, plus a safe API that separates commands from arguments, and tamper protection on the dialog's metadata [10]. That split puts the integrity of an approval prompt in the client's rendering rather than in the vigilance of the person clicking.
OWASP suggests guardrails that inspect the dialog for malicious activity, then warns that this should not be relied on alone, since an LLM-based guardrail is itself subject to prompt injection and false positives [11]. An automated reader of attacker-controlled text has the same structural weakness as the human reader of attacker-controlled text.
The defensible conclusion is narrow. An approval step still catches the agent that blunders, and it does not catch the agent that has been scripted to lie about what it is doing [1]. So a control review that credits "human approves" as a mitigation for indirect prompt injection now needs a condition written next to it, because OWASP recommends HITL for exactly that class of vulnerability [2]: the credit holds only where the dialog is rendered from trusted formatting and the action descriptor cannot be written by the model.
What to watch
- Whether a vendor ships a dialog rendered only by a trusted formatter, with model-supplied markdown stripped, and whether researchers can still forge it.
- Whether anyone runs the experiment the page lacks: users shown padded versus clean dialogs, with approval rates measured.
- Whether dialog forging turns up in an incident report with affected versions and a CVE, rather than in a research write-up.