SearchLeak: How Prompt Injection Turns Trusted Tools Against You
Marcus Webb
Principal Security Engineer · June 16, 2026

Researchers disclosed SearchLeak this week, a parameter-to-prompt injection attack that smuggled malicious instructions through query parameters to bypass Copilot guardrails, exfiltrating organizational data by using Bing as a trusted proxy. It is a sharp reminder that prompt injection remains an unsolved architectural problem: LLMs still cannot reliably separate your instructions from untrusted content.
Why trusted proxies make injection worse
SearchLeak works because the data leaves through a channel everyone trusts. The model follows injected instructions and routes sensitive data out via a legitimate service, so nothing looks obviously malicious.
Any mobile app that feeds untrusted content, search results, web pages, user input, into an LLM can be steered the same way.
How this pattern reaches mobile apps
On a phone, injection often chains with platform features to escalate quickly.
- Untrusted content concatenated directly into prompts without isolation
- Deep links and clipboard data carrying injected instructions
- Model responses that trigger network calls or exfiltrate data through allowed hosts
- System prompts recoverable through crafted queries
How RASMISER maps your injection surface
RASMISER traces how your app builds prompts and where untrusted data flows into them, flagging the paths most likely to be abused and the outbound channels that could become an exfiltration route, all mapped to OWASP MASVS.
With runtime protection, the endpoints your model talks to stay pinned and tamper-resistant, so an injected instruction has nowhere clean to send your users' data.
The takeaway
Prompt injection is an architectural reality, not a bug you patch once. Assume untrusted content can hijack your model and scan for the data paths it could abuse before you ship.
Scan your app free
