Prompt Injection Is Now a Real-World Attack Vector: What Security Teams Need to Understand

A researcher bought a domain for five dollars and used it to walk sensitive CRM records out of Salesforce. No malware. No stolen password. Just some text hidden in a web form.

That was ForcedLeak, and it’s where I want to start, because it kills the idea that prompt injection is a research toy. Prompt injection is unsolved at the model layer, and you can’t patch your way out of it. You have to design around it. And the model doesn’t know the difference between your instructions and instructions that arrive inside the data it reads, and that’s exactly the vulnerability.

Here you’ll get the documented incidents with CVE numbers, a control table with what each defense misses, and a detection section for the day it somehow slips through.

Key Takeaways

• Prompt injection holds the LLM01 spot on the OWASP LLM Top 10, the number 1 risk for LLM apps.
• EchoLeak (CVE-2025-32711, CVSS 9.3) was the first zero-click injection to pull real data out of a production system, Microsoft 365 Copilot.
• ForcedLeak (CVSS 9.4) did the same to Salesforce Agentforce using a hidden form field and an expired $5 domain.
• No single control can stop injection. Google’s own layered defense on Gemini still leaves a measurable attack success rate at 6.2%, not 0.
• The real danger is agents, not chatbots. An agent that reads untrusted data and can also send data out is an exfiltration engine waiting for a trigger.

Prompt Injection Explained: Why It Is Not the Same as Jailbreaking

People use these two words like they mean the same thing. But they don’t, and the difference decides how you defend against each.

Jailbreaking targets the model’s rules. You’re the attacker, and the target is the safety policy. You coax the model into saying something it was told not to say. Prompt injection targets the application’s trust boundary. The attacker is usually not the user at all. It is a third party who plants instructions in content the model will later read, so the model treats attacker text as if it came from you.

Simon Willison coined the term back in September 2022. The model concatenates your trusted prompt with untrusted text and cannot tell them apart afterward.

• Jailbreaking: The user tricks the model into breaking its own rules.
• Prompt injection: A third party hides instructions in data, and the model runs them on the user’s behalf.

That second one is the security problem, because the victim never sees it happen.

How Prompt Injection Attacks Work: Direct, Indirect, and Multi-Turn Vectors

The mechanics come in three ways.

Direct injection is the obvious one. Someone types malicious instructions and gets straight into the chat. Indirect injection is where it gets nasty. The payload lives inside a document, an email, or a web page, and it only activates when the model accesses that content. Multi-turn attacks stretch this across time. It plants a payload that sits dormant until a specific action wakes it up.

Vector	Injection Surface	Payload Location	Detection Difficulty	Real Example
Direct	Chat input	The user’s own message	Low to medium	Classic “ignore previous instructions”
Indirect	Retrieved content	Emails, docs, web pages, form fields	High	EchoLeak hidden email text
Multi-turn / delayed	Stored data an agent reads later	CRM records, calendar invites, memory	Very high	ForcedLeak Web-to-Lead field

The pattern that keeps showing up in real breaches is indirect. Nobody clicks anything. The content just needs to be somewhere the AI will eventually look.

Documented Prompt Injection Incidents From 2023 to 2026

I could describe hypothetical attacks all day, but the ones below are more useful. So, here’s the timeline that turned prompt injection from a blog topic into a CVE list.

Date	Target	Vector	Impact	Fix
Feb 2023	Bing Chat (“Sydney”)	Indirect via web page	Leaked its own hidden system prompt	Guardrail tuning
Aug 2024	Slack AI	Indirect via public channel	Data exfiltration from private channels	Vendor patch
Jun 2025	Microsoft 365 Copilot	Zero-click email (EchoLeak)	Internal file exfiltration, CVSS 9.3	Server-side patch
Sep 2025	Salesforce Agentforce	Web-to-Lead form (ForcedLeak)	CRM data theft, CVSS 9.4	Trusted URL enforcement
2025-2026	Google Gemini	Calendar invites, emails	Agent action hijacking	Layered ML defenses

Two of these deserve a closer look. EchoLeak was disclosed by Aim Security and is the one that changed the conversation, because it required zero user interaction. The victim never opened the malicious email. Copilot found it during normal retrieval and followed the hidden instructions.

ForcedLeak, found by Noma Security, is almost funnier and scarier at once. The exfiltration channel was an image URL pointing at a domain that had expired on Salesforce’s allowlist. Researchers bought it for about $5, and suddenly a trusted-but-abandoned domain became the leak path.

Why AI Agents Turned Prompt Injection Into a Data Exfiltration Problem

Here’s the dangerous part. A chatbot that gets injected says something dumb. An agent that gets injected does something dumb, and it might do it while you sleep.

Simon Willison calls the dangerous combination the lethal trifecta. An agent with access to private data, exposure to untrusted content, and the ability to communicate externally. And when all three overlap, injection becomes theft.

• Private data access: The agent can read your CRM, your inbox, your files.
• Untrusted content exposure: It can also read emails, web pages, and documents from strangers.
• External communication: And it can send a request, render an image, call a tool, or hit a webhook.

Do the blast-radius math. One poisoned document doesn’t stay as one document. Feed it to an agent connected to five systems, and a single hidden instruction now has a path to all five. Plus whatever those systems can reach on their own. ForcedLeak is the clean example: one form field reached the entire CRM and shipped the results to an outside domain.

Which LLM Security Controls Actually Hold Up Against Injection

If I had to name one control that does the most work, it is this. It treats every tool the agent can call as an allowlist, and requires human confirmation before anything leaves your perimeter. Filtering the input is nice. Constraining the output is what saves you.

Here’s how the common controls actually stack up.

Control	What It Stops	What It Misses	Cost	Verdict
Input filtering/classifiers	Known injection phrasings	Novel encodings, rephrased payloads	Low	Useful, never sufficient
Spotlighting/delimiting	Casual instruction-blending	Determined attackers, some languages	Low	Good cheap layer
Dual-LLM / quarantine	Untrusted text reaching privileged actions	Added latency and complexity	Medium	Strong for high-risk flows
Tool-call allowlisting	Unexpected external actions	Nothing, if scoped tightly	Medium	Highest-value control
Human-in-the-loop	Silent exfiltration	Alert fatigue, slows workflows	Medium	Essential for sensitive data

Guardrails, spotlighting, and dual-LLM patterns compared

Not all of these earn the same trust, so I will rank them according to that.

Input classifiers are the weakest link on their own. They catch what they have seen and miss what they haven’t, and attackers rephrase for a living. Spotlighting is where you wrap untrusted content in markers and tell the model not to trust anything inside them. Google reported it works partly by disrupting tokenization, though it likely performs worse in Chinese and Japanese where single characters carry more meaning.

Dual-LLM and quarantine patterns are stronger. One model handles untrusted content and never gets to touch privileged tools. The second, the isolated model, does all the sensitive work.

On raw numbers, layered beats single every time. Google’s stacked defenses cut adaptive attack success on Gemini to around 6.2% in one calendar-invite scenario.

Where these AI security controls still fail

Novel encodings slip past filters that were trained on payloads from the last month. Cross-modal attacks hide instructions inside images and audio, where your text classifier never looks. And in agent chains, a downstream tool can quietly reintroduce untrusted text after your input filter already waved the request through, so your one checkpoint guarded the wrong door.

So, to be honest, if you deploy an agent with the lethal trifecta and rely on a classifier to save you, you’re just one clever encoding away from a bad week. So, design in a way so that no single failure is catastrophic.

Detecting and Responding to a Prompt Injection Incident

Assume something eventually gets through, because it will. The teams that recover fast are the ones watching the right signals before anything goes wrong.

Detection for injection doesn’t look like malware detection. There is no binary to flag. You are watching for an agent behaving out of character.

• Anomalous tool calls: The agent hits an endpoint or tool it has never used for this task.
• Egress to odd destinations: Outbound requests, especially markdown image loads pointing at unfamiliar domains, which is a classic exfiltration channel.
• Instruction-shaped data: Retrieved content containing phrases like “ignore previous” or hidden HTML comments and white-on-white text.

Log the fields that let you reconstruct what happened; the full prompt context, every retrieved document ID, every tool call with its arguments, and every outbound URL. Retain those for at least 90 days, longer if you’re in a regulated vertical, because injection incidents are often found weeks after the payload was planted.

If you catch one live, the containment sequence is short: revoke the agent’s outbound tool access first, snapshot the context and logs before anything rotates, identify and quarantine the poisoned source, then rotate any credentials the agent could reach. Kill the exfiltration path before you start the investigation.

Mapping Prompt Injection to OWASP LLM01, NIST, and the EU AI Act

If you need to justify this work to leadership, the frameworks already back you up. Prompt injection is not a fringe concern in any of the major standards.

Framework	Reference	What It Requires
OWASP LLM Top 10	LLM01: Prompt Injection	Named the #1 LLM risk; input handling and privilege control
NIST	AI 100-2 E2023	Classifies injection under adversarial ML; mitigation guidance
EU AI Act	Article 15	Accuracy, robustness, and cybersecurity for high-risk AI systems

OWASP putting injection at LLM01 is the fastest way to make a skeptical exec take it seriously. NIST’s adversarial ML taxonomy gives you the vocabulary for a formal risk register. And EU AI Act Article 15 turns robustness against attacks like this into a compliance obligation for high-risk systems, with obligations phasing in through 2026 and 2027. If you operate in the EU, this stops being optional.

A 30-60-90 Day Secure AI Rollout Plan for Security Teams

Frameworks are nice. A plan you can assign on Monday is better. Here is one you can hand to a team this week.

Phase	Actions	Owner	Success Metric
Days 1-30	Inventory every agent and its tool access; flag any with write access to production; map who has the lethal trifecta	AppSec lead	Complete agent + permission inventory
Days 31-60	Add tool-call allowlists; require human confirmation on outbound actions; enable egress logging with 90-day retention	Platform eng	Allowlists live on all high-risk agents
Days 61-90	Red-team with indirect payloads; audit allowlisted domains for expired ones; write the injection runbook	Security + eng	Runbook tested in a tabletop exercise

The first move matters most, inventory. You can’t defend agents you have not counted. That audit of allowlisted domains in the third phase is a direct nod to ForcedLeak, because a domain that lapsed two years ago is a leak waiting for someone with $5.

Final Thought

Stop waiting for a model update to fix the issue. It’s not coming, and building as if it were is the actual risk.

Make one decision this week; identify every agent that holds the lethal trifecta, and break the chain on the ones that don’t need all three. Cut the outbound path, scope the data access, or gate the untrusted input.

Through 2027, agent security is heading toward least-privilege by default and deterministic guardrails around tool use, because the industry is slowly accepting that you constrain what the model can do, not what it can be tricked into thinking.

FAQs