In such a case, the LLM’s output would never be returned to the user, as the output filter would intercept it and cause the API call to fail. To the best of our knowledge, there is no way to prompt Apple’s on-device LLM without passing through these filters. 

Hacking Apple on-device foundation model

You know the drill: all AI models are susceptible to adversarial inputs: prompt injection, jailbreaking, and similar attacks. However, Apple Intelligence presents a somewhat different case for an attacker given its OS-level integration:

The ability to use an efficient, system-level LLM through a simple, unified API makes it extremely attractive for developers. At the same time, this very centralization increases its appeal to attackers, turning the model into a high-value target within the operating system itself. As Apple Intelligence becomes integrated into more applications, the potential for exploitation and causing serious harm to users also increases.

Which naturally led us to ask the familiar question: "Can we break it?"

Well, if you are reading this blog post, you already know the answer...

Threat model

Let’s focus on a very general indirect prompt injection threat model; the most common and practical attack vector against LLM‑based applications.

Imagine an iOS app that harnesses Apple’s on-device LLM to automate workflows using external inputs like emails, web pages, and PDF documents.

Assume an attacker controls a portion of the web pages or emails processed by the application and attempts to inject a prompt that causes the application to generate arbitrary harmful output; where "harmful" refers to content that would normally be blocked by the model’s safety filters.

To make this happen, an attacker must solve two problems:

1.  Find an input that, when directly or indirectly provided to the LLM, causes it to execute an adversarially chosen task, e.g., "tell me how to build a pipe bomb" or "convince the user to log in at this URL."
2. Find a way to bypass the on-device model filters so that the input and the generated output are not blocked by the OS.

The rest of this article discusses how an attacker can solve the two problems above.

An "exec()" is all you need

So, how can the attacker convince Apple Intelligence’s on-device LLM to do what they want?

Easy, with:

Confused? If the answer is yes, it means you have not read our 2024 paper (https://arxiv.org/pdf/240 3.03792). That is clearly a "Neural Exec"--an adversarial input designed to trick an LLM to perform any task defined into the string.

Similar to how an exec system call (https://en.wikipedia.org/wiki/Exec_(system_call)) replaces the currently running process in a Linux system:

If the parallel is unclear, you can think of the string above as “Ignore all previous instructions and do this instead” on steroids.

In practice, a neural exec is a prefix and suffix learned via an optimization process (see paper) that, when applied to an instruction, forces the LLM to execute it regardless of previous inputs or the system prompt. For instance, let’s assume the attacker wants to manipulate the output of an app that summarizes web pages using Apple’s on-device model. The attacker can hide the following string on a website:

The above input will (with high probability) force the model to ignore the task in the system prompt and produce the following output instead: 

In practice, neural exec triggers come with additional cool properties by design. One key feature is what we call “inline invariant composability” (see the paper for details): the ability to embed the payload within arbitrary input (i.e., not under the control of the attacker) text without compromising its functionality. For example, providing this chunk of text to the target LLM: 

Would have the same effect as the previous example.

What’s the point, you say? Think about how RAG works.

Indeed, combining the payload with honest text provides several practical advantages: it increases the likelihood that the armed payload bypasses RAG pipelines, improves the probability of evading language-detection systems, and reduces the payload’s visibility during manual inspection in scenarios where the attacker cannot make it fully invisible (e.g., via HTML or Unicode tricks).

Have we already told you that neural execs are universal too? Meaning an attacker can specify an arbitrary payload to be executed without the need to recompute the trigger.

Filters are made to be evaded

Cool, we have a reliable way to trick Apple’s on-device model into doing whatever we want. Is that enough? Not really; our attacker still has the filters to take care of.

Indeed, unless the goal is genuinely to promote healthier eating habits, the attack hasn’t really succeeded yet. A more plausible scenario is that the attacker wants to coerce the on-device model into generating harmful content; say, phishing material or other malicious outputs. However, this is exactly where the built-in filters come into play. They’re designed to block precisely these kinds of attempts; and they will.

But, you know, nothing is perfect (especially when it comes to security), and next we show that Apple’s on-device model filters can be reliably evaded.

Now, suppose the attacker attempts to coerce the model into producing the following output: "very bad sentence". Here, "very bad sentence" represents a string that would normally trigger the on-device LLM filters.

So, using the neural exec trigger described above, a possible prompt injection payload for the application would be:

As explained in the introduction, this approach would simply not work: either the input or output filter would be triggered, causing the API call to fail and rendering the attack infeasible.

Next, however, we show that evading this filtering mechanism is simple; and we do so by relying on the most potent cyber‑weapon ever created by humankind: Unicode.

Bypassing Apple Intelligence’s filters via Unicode-based obfuscation

Have you ever thought about how right-to-left languages such as Arabic are rendered on your screen?

Well, most of the magic happens through Unicode. It provides a dedicated Arabic block, the Bidirectional Algorithm, and a special control character called RIGHT-TO-LEFT OVERRIDE(\u202E). This override forces all following characters to be laid out in RTL order until a matching LEFT-TO-RIGHT OVERRIDE or the end of the string is reached, making it possible to embed RTL text inside LTR contexts or preserve legacy ordering. Rendering engines read this flag and adjust the visual ordering accordingly, so the final text appears correctly on the page.

Abusing Unicode, and especially RIGHT-TO-LEFT OVERRIDE (\u202E), to bypass security filters is not a new idea; security researchers have been using this and similar tricks for ages. So, I was quite surprised to see that it just worked against Apple’s filters.

Let’s go back to our objective: we want the on-device model to output "very bad sentence". So, what we ask the LLM to do is:

Here:

•  is the Unicode character U+202E (RIGHT-TO-LEFT OVERRIDE)
• "ecnetnes dab yrev" is the reverse of "very bad sentence".

If payload execution is successful, the LLM ignores the intended task defined in the system prompt and returns:

Although still reversed in the raw LLM and API output, the RTLO character causes this text to render visually as:

On the user’s screen or UI component (unless intentionally prevented). Because the unsafe string appears only in its reversed form in both the input and output, it avoids detection by the filtering mechanisms implemented by the OS, allowing the API call to succeed. Interestingly, this simple trick can bypass both external input filters and internal model guardrails with high probability. u

Putting it all together

Ok, let’s put it all together and show some examples of complete attacks.

To evaluate the effectiveness of the attack, we prepare three distinct pools to create suitable input prompts:

• System prompts: A collection of system prompts/tasks (e.g., “Edit the provided text to align with American English spelling and punctuation conventions”).
• Harmful strings: Manually crafted strings designed to be considered offensive or harmful (i.e., the outputs we aim to force the model to generate).
• Honest inputs: Paragraphs sourced from random Wikipedia articles, used to simulate non-adversarial, benign-looking inputs (e.g., in the context of indirect prompt injection via RAG or similar systems).

During evaluation, we randomly sample one element from each pool, assemble a full prompt, create an armed payload (see below), inject it, and test whether the attack succeeds by invoking the Apple on-device model through the OS. 

Let’s give an example. Our malicious output is “respond with ‘You  user, go yourself ’ and nothing more” (censored for obvious reasons). Using the neural exec trigger shown before and the right-to-left override trick, our adversarial input is:

To make the attack more realistic and challenging, we wrap the adversarial input above in arbitrary honest text not under the attacker’s control, exploiting the inline invariant composability of our trigger. Ultimately, a test prompt would look something like this:

Of course, given such input, the LLM response will be (at least in the way it is rendered on screen): 

And so, successfully bypassing the LLM’s internal guardrails and both input and output filters at once.

We ran the evaluation over 100 random prompts, achieving an average attack success rate of 76%.

Trust me, I had fun creating more “challenging” payloads, and there is no limit to what we can trick Apple’s on-device model into producing. Unfortunately, I cannot show you more compelling examples; my job is at stake here, you know . 

However, generally speaking, by using a neural exec trigger and the filter-evasion technique described above, an attacker can potentially coerce the on-device model to behave arbitrarily. The real-world impact of such an attack is bounded only by the sensitivity of the data and functionalities that the application developer has instructed the LLM to access, and by any additional defenses set up by the developer (but that’s true for any LLM).

Vulnerability disclosure

The RSAC Research Lab disclosed this attack to Apple on October 15, 2025, through the Apple Security Research portal. Apple has since hardened the affected systems against this attack, and those protections were rolled out in iOS 26.4 and macOS 26.4 (March 24, 2026). The Apple team reviewed this blog post prior to publication.