Skip to main content
AI Agent Clicked "Delete All" Instead of "Read More"Incident
5 min readFor Security Engineers

AI Agent Clicked "Delete All" Instead of "Read More"

In December 2024, researchers at Seoul National University demonstrated a new attack that made AI agents perform unintended actions. This attack succeeded up to 50% of the time against current defenses by corrupting data the AI trusted completely.

This wasn't prompt injection. The attackers never altered the instructions. They manipulated the data itself.

What Happened

Researchers developed agent data injection (ADI) attacks. This technique corrupts trusted data fields that AI agents use to make decisions, such as button IDs, sender names, product descriptions, and file paths. When an AI agent parses this corrupted data, it performs the wrong action while appearing to complete its assigned task correctly.

In one demonstration, an agent intended to click "Read More" but clicked "Buy Now" instead. The agent's logs showed it had completed the user's request to learn more about a product, yet the purchase went through.

The attack works through probabilistic delimiter injection. AI models use delimiters (characters like colons, brackets, or newlines) to separate data fields. Attackers inject carefully crafted delimiter sequences into data fields, causing the model to misinterpret the structure. A button labeled "Read More" becomes "Buy Now" in the agent's interpretation, but the original data remains unchanged in the source.

OpenAI systems were among those tested and found vulnerable.

Timeline

Early December 2024: Seoul National University researchers publish findings on ADI attacks.

Testing period: Researchers demonstrate a 50% success rate against current prompt injection defenses across multiple AI platforms.

Current status: No widespread exploitation documented in production systems, but the attack technique is now public knowledge.

Which Controls Failed or Were Missing

Input validation on structured data: The agents trusted data field delimiters without validation. When an attacker injected probabilistic delimiters into a button ID field, the agent reparsed the structure mid-execution. Standard input sanitization focuses on SQL injection, XSS, and command injection patterns. It doesn't validate delimiter consistency in structured data that the AI itself interprets.

Separation of data and control planes: The agents made decisions based on data that could be modified by external parties. A button ID from a web page, a sender name from an email, a filename from a directory listing. These data points became control signals without any privilege boundary between them.

Logging and audit trails: The agents logged their intended actions ("clicked Read More") but not the actual data they operated on ("button_id: buy_now_corrupted_delimiter_sequence"). Post-incident investigation would show a clean audit trail even though the wrong action occurred.

Model output validation: The agents didn't verify that their parsed interpretation of data matched the source data structure. They trusted their own parsing implicitly.

What the Relevant Standards Require

OWASP ASVS v4.0.3, Requirement 5.1.3: "Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters." The principle extends to any structured data the application parses. If your AI agent treats delimiter-separated data as trusted input, you're violating the control's intent.

NIST 800-53 Rev 5, SI-10 (Information Input Validation): "The information system checks the validity of the following information inputs: syntax, length, and range." For AI agents, this means validating not just the content of data fields but their structural delimiters. A button ID field should contain a button ID, not a delimiter sequence that changes how the agent parses subsequent fields.

ISO/IEC 27001:2022, Control 8.24 (Use of Privileged Utility Programs): AI agents are privileged utility programs. They perform actions on behalf of users with elevated access to systems. The control requires "formal authorization, logging, and restriction of use." Your agent needs to log what it actually did (which button ID it used), not what it thought it did (which action it intended).

SOC 2 Type II, CC6.1 (Logical and Physical Access Controls): The trust service criterion requires that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." If external data can become control signals without validation, you haven't implemented logical access controls over your agent's decision-making process.

Lessons and Action Items for Your Team

Validate data structure before agent processing: Add a preprocessing step that validates delimiter consistency in all structured data your agents consume. If a button ID contains characters that could be interpreted as field separators, reject it or escape it before the agent sees it. This isn't the same as sanitizing for XSS or SQL injection. You're validating that the data structure matches its schema.

Log the raw data, not the interpretation: When your agent clicks a button, logs should show: "Intended action: read_more | Button ID used: btn_7a3f | Raw HTML: [actual button element]". If the button ID and the action don't match, your alert triggers. Most agent frameworks log only the high-level action.

Implement a validation layer between data sources and agent actions: Your agent shouldn't directly consume button IDs from web pages, sender names from emails, or filenames from directories. A validation service should verify that the data structure is consistent, that field boundaries are clear, and that no probabilistic delimiters exist. Only validated data reaches the agent.

Test your agents with delimiter injection: Add test cases where button IDs contain colons, brackets, newlines, and other delimiter characters. Does your agent still perform the correct action? Do your logs show what actually happened? If you can't test this today, you don't have visibility into whether your agents are vulnerable.

Restrict agent capabilities to minimum necessary: If your agent only needs to read data, don't give it write access. If it only needs to click specific button types, whitelist those types. The ADI attack succeeds because agents have broad capabilities and trust their own parsing. Reduce both.

The 50% success rate isn't a theoretical risk. It means half the time, an attacker who can inject delimiters into data your agent trusts will make that agent perform the wrong action. You won't see it in prompt injection filters. You won't see it in traditional input validation. You'll see it when your agent buys something you didn't authorize or deletes data you meant to read.

Start with your highest-risk agents: those with write access, those processing external data, those making financial decisions. Validate their data structure handling this week.

Topics:Incident

You Might Also Like