Validated Research Published: Apr 25, 2026

Apple Intelligence Hijack: Prompt Injection Against an OS-Level Local LLM

RSAC researchers combined a Neural Exec adversarial input with Unicode right-to-left override to bypass Apple Intelligence's local LLM filters and internal guardrails. Apple Intelligence is Apple's OS-level AI feature set, so the broader lesson is that a local LLM needs input canonicalization, output validation, per-app capability scoping, and client-side isolation before app data and functions become model-accessible. Apple has since shipped hardened iOS and macOS releases, with no reported in-the-wild exploitation.

Prompt InjectionGuardrail BypassInput ValidationOn-Device AIApple Intelligence
8 applicable AIDEFEND defenses
Source: Is That a Bad Apple in Your Pocket? We Used Prompt Injection to Hijack Apple Intelligence 
Authors: Petros Efstathopoulos, PhD, Laura Koetzle, Dario Pasquini, PhD
Original article: Apr 9, 2026

Threat Analysis

  • The attack targets an OS-managed local model. Apple Intelligence exposes an on-device LLM through Foundation Models, so third-party apps can use a system-level model without controlling weights or runtime.
  • The bypass combined model steering and filter evasion. RSAC researchers used Neural Exec-style adversarial input to push the model toward an attacker-chosen task, then used Unicode RLO to hide offensive text from input and output filters.
  • The measured success rate was material. The researchers say it succeeded on 76% of 100 random prompts before Apple's hardening.
  • The practical risk comes from app context. A compromised LLM-enabled app could expose or manipulate data and functions already available to that app.
  • The fix landed at the platform layer. Apple hardened the affected systems in iOS 26.4 and macOS 26.4; users should upgrade, and app teams should still reduce what local model calls can see and do.
RLO rendering example showing the underlying string invoice_2026_[U+202E]fdp.exe and the visually misleading result that appears more like invoice_2026_exe.pdf
Example: hidden U+202E changes display order. The string still contains .exe, but can appear as .pdf.

Applicable AIDEFEND Defenses (8)

AID-H-002.002
Inference-Time Prompt & Input Validation
Very High
This is the closest first-line control. Inputs to the local LLM should be canonicalized before filtering, including Unicode bidirectional controls, hidden directionality, unusual encodings, and adversarial-looking text that attempts to turn an app request into a new model objective.
AID-H-006.002
Text, Markup & Structured Output Sanitization and Release Gate
Very High
The attack explicitly bypassed output filtering. Local LLM responses should be normalized and inspected before display or handoff to app logic, so Unicode-rendered payloads, policy-violating text, unsafe URLs, or app-action arguments cannot slip through because the pre-rendered string looked harmless.
AID-H-018.004
Intent-Based Dynamic Capability Scoping
Very High
An app call to Apple Intelligence should receive only the data and functions needed for that user intent. A prompt injection that hijacks a summarization or editing task should not inherit broad access to health data, media libraries, file operations, or other app capabilities.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
High
Treat the affected Apple Intelligence and Neural Engine software population as a managed AI-software remediation case: deploy the fixed OS release in staged endpoint rings, retain rollback readiness, and verify that no affected device build remains. This owns fleet patch completion, not prompt or output policy.
AID-I-007
Client-Side AI Execution Isolation
High
Because the model runs on the client device, containment matters even when the model is OS-managed. Per-app sandboxing, controlled IPC, entitlement checks, and isolation from unrelated app or OS state keep a coerced local model from becoming a cross-app data or action path.
AID-D-001.001
Per-Prompt Content, Intent & Obfuscation Analysis
High
Unicode right-to-left override is exactly the kind of obfuscation that shallow filters miss. Prompt screening should decode and score multiple text views, including raw, normalized, rendered, and directionality-stripped forms, before deciding that an input is safe.
AID-M-009.002
Authority Envelope & Action Risk Classification
High
Classify manipulation of app-accessible health data, media files, and other user content as high-risk actions rather than ordinary text generation. The authority envelope records which actions require confirmation, denial, or a narrower data view; runtime capability and data-use gates consume those facts and enforce the result.
AID-H-029.002
Lifecycle-Stage Authorization Gate
Medium
Sensitive app data should not automatically enter local LLM inference context just because an app can read it. A lifecycle-stage gate checks whether a specific data class is authorized for this inference use, this app, and this user intent before model context is assembled.

What Defenders Should Do Now

  • Upgrade managed Apple devices to iOS 26.4 and macOS 26.4 or later, and flag older versions as exposed to the pre-hardening behavior described by RSAC.
  • Inventory apps that use Apple Intelligence or the Foundation Models framework, then classify what data each app can pass into local LLM calls.
  • Normalize and inspect model inputs before inference. Treat bidirectional Unicode controls, hidden directionality, nested encodings, and adversarial gibberish as high-risk signals that should fail closed or require additional review.
  • Validate outputs after rendering-normalization, not only as raw strings. Block responses that become unsafe after Unicode rendering or that attempt to drive app actions outside the user's original intent.
  • Limit local model calls to the minimum app capabilities needed for the task. Sensitive data and mutating actions should require explicit user or policy approval before being exposed to model context or model-directed workflows.

1 additional consideration

Endpoint-level permission transparency for local LLM apps

Beyond the agent and skill permission controls mapped above, teams should also make local LLM activity visible at the OS and endpoint-management layer: which apps reach the on-device model, which local services they contact, which data paths they read or write, which API keys or tokens they can touch, and which app actions model output can influence.
Recommendation: Expose an AI entitlement manifest in app review, MDM, privacy settings, and endpoint inventory; let admins block local LLM access to high-sensitivity data classes; and require apps to declare whether model output can modify files, health records, media, messages, or other user content.

Conclusion

This case is a useful warning about on-device AI becoming a platform security boundary. Local execution reduces some cloud exposure, but it also puts the model close to app data, user files, and OS-mediated functions. AIDEFEND  maps well to input canonicalization, output validation, capability scoping, client-side isolation, and data-use gates; the operational goal is to make a compromised local LLM boringly constrained, not broadly useful to the attacker.