Three safety layers, one chained bypass

Apple Intelligence includes a language model that runs locally on supported Apple devices. Applications can reach that model through an operating-system interface and use its response in features that handle local information. Apple placed safety checks around this access, but the RSA Conference (RSAC) research team found a way through the whole chain.

The reported design had an input filter checking a request before it reached the model, safety rules inside the model, and an output filter inspecting the response. Apple does not publish every detail of that pipeline. 9to5Mac reported that the researchers described this as the most likely explanation for the behavior they observed, based on testing the system from the outside.

The researchers paired two methods. A Unicode display-control character disguised the dangerous text from the filters. Neural Exec, a prompt-injection technique, supplied instructions intended to override the model's normal rules. Prompt injection is a crafted input that makes a language model treat untrusted text as a command. Combining the methods let one part of the payload evade inspection while the other changed what the model did.

Backwards text got past the filters

Unicode is the standard computers use to represent writing systems. Its right-to-left override character helps software display text whose reading direction differs from the surrounding text. That is ordinary support for languages such as Arabic, especially when right-to-left and left-to-right text appear together. Right-to-left writing and its users had nothing to do with the attack.

The researchers abused the display control in a specific way. They wrote an offensive English output string backwards in the underlying data, then added the right-to-left override so the text appeared in its intended order when rendered. A person looking at the result saw readable text. A filter inspecting the raw character sequence encountered the words in reverse.

According to both reports, that mismatch helped the payload pass the input and output filters. The display feature itself did not instruct Apple Intelligence to misbehave. It presented the checks with reversed characters while showing a readable result on screen.

Neural Exec changed the instruction

Neural Exec handled the instruction-changing part of the chain. The Register described it as a prompt-injection method that uses an optimization algorithm to generate strings capable of triggering unwanted model behavior. The automated search replaces some of the slow trial and error involved in writing a bypass by hand.

In this experiment, the Neural Exec payload was built to push the local model away from its safety instructions and toward an attacker-selected response. The backwards text was embedded inside that payload. The Unicode method helped the content cross the filters; Neural Exec induced the model to follow the hostile instruction between them.

The two methods handled different parts of the bypass. The Unicode display control concealed the target text from the filters, while Neural Exec made the model follow the hostile instruction. Together they carried the attack through the full safety pipeline.

Seventy-six of one hundred tests succeeded

The researchers evaluated the chain with 100 prompts. For each test, they randomly selected elements from three prepared pools, assembled a full prompt, added the attack payload, and invoked Apple's on-device model through the operating system. In the researchers' randomized test set, 76 of 100 assembled prompts produced a successful attack result.

The number describes that test set and that experimental method. It is not a universal 76 percent bypass rate for Apple Intelligence. The researchers did not sample 100 ordinary users, every supported device, or every possible prompt. Their randomization varied components inside a prepared attack framework.

Even with that boundary, 76 successes were enough to show repeatability rather than a single lucky response. Safety controls that work only when an adversarial prompt happens to land in the other 24 tests are not dependable controls. The result documented a reproducible weakness in the tested version of the local model pipeline.

What the test actually showed

The demonstrated result was attacker-chosen model output. The public example made Apple Intelligence direct an offensive phrase at the user. The phrase made the control visible, but it did not establish wider access by itself.

The Register reported that the researchers verified the method could create a new contact. The researcher said it could also put an attacker's phone number under another person's name, but The Register did not say that variation was demonstrated. Contact creation itself was an application-exposed action reached during the research.

Broader manipulation of information available through applications was described as a potential risk. The danger would depend on which data and actions a particular application made available to the local model. The reports do not show arbitrary code execution, full device takeover, or compromise of Apple's cloud services.

Both articles describe controlled security research and identify no real-world cases. That reporting limit does not prove the method was never attempted elsewhere. It means the documented evidence is a repeatable laboratory attack, not a confirmed campaign or a count of harmed users.

Researchers said Apple hardened the local model

The researchers disclosed the attack to Apple in October 2025. The Register gave the disclosure date as October 15. Before the April 2026 public reports, the researchers said Apple had hardened the affected systems and shipped protections in iOS 26.4 and macOS 26.4.

Apple did not answer The Register's questions about the research, the fix, or the disclosure. The remediation details therefore remain attributed to the researchers rather than confirmed in a technical statement from Apple. The reports do not explain the precise changes or claim that every future prompt-injection method has been solved.

No vendor advisory supplies a root cause or patch notes. The available reporting says the named operating-system releases fixed the disclosed chain, not prompt injection as a broader class of attack.

Operating-system integration raises the stakes

A language model producing an offensive sentence is a product failure. A local model able to pass its output into application actions creates a security boundary. The contact demonstration showed why: once model text can become an instruction to modify local data, a successful bypass can leave a durable change outside the chat response.

The public demonstrations stopped at attacker-controlled output and, according to The Register, contact creation. The researchers warned that the same technique could manipulate any data available to apps and services using the model. An application exposing more sensitive data or actions could have raised the harm well beyond the lab's deliberately visible examples.

Human review also needs to happen outside the model's own judgment. Before a consequential action runs, the interface should show the target and exact change for separate confirmation. Otherwise, hostile text can borrow the assistant's authority and turn routine approval into permission for the attacker's instruction.

This incident is distinct from the existing Gemini email-summary story. That case involved hidden instructions in cloud-hosted email content and a false message inserted into a summary. Apple's case involved a local model, a chained bypass of filters and model safeguards, and an action exposed through the operating system. It also differs from Apple's false news summaries, where the model fabricated claims without an adversarial input bypass.

Running the model locally does not make hostile instructions harmless. When a local model can act on application data, its safety boundary needs to survive malicious text before any high-consequence operation reaches the point of execution.