RSAC researchers combined a Neural Exec-style adversarial input with a Unicode right-to-left override (U+202E) to hijack Apple Intelligence's on-device LLM: the adversarial trigger steered the model toward an attacker-chosen task while the directionality override hid the offensive text from both input and output filters, because the pre-rendered string does not match what is displayed. The researchers report the technique succeeded on 76% of 100 random prompts before Apple's hardening. The practical exposure comes from app context: a coerced LLM-enabled app could expose or manipulate the data and functions already available to that app. Apple hardened the affected systems in iOS 26.4 and macOS 26.4, and no in-the-wild exploitation is reported.
ASSESSED SYSTEM
Apple Intelligence's OS-managed on-device LLM as exposed to third-party applications through the Foundation Models framework, in the pre-hardening state the RSAC researchers tested (iOS and macOS builds prior to 26.4). In scope: the model's input filters, internal guardrails and output filters, the app-facing context-assembly path by which app data enters inference, and the app-capability envelope that model output can influence.
OUT OF SCOPE
Apple Intelligence after the iOS 26.4 and macOS 26.4 hardening, which the evidence states fixed the affected systems; Apple's server-side Private Cloud Compute path, which the evidence does not discuss; the internals, entitlements or data handling of any particular third-party app; and any claim of in-the-wild exploitation, of which the evidence reports none.
Architecture: Tool-Calling LLM / Connected GenAI (decision tree Q3) — Q1 and Q2 are NO: the evidence describes no multi-agent topology and no autonomous planner maintaining task state across unapproved steps — apps invoke the model per request. Q3 is YES: the Foundation Models framework exposes the OS model to third-party apps that place app-held data (health data, media libraries, files) into inference context and act on the returned text, and the brief's control set is explicitly about that connected surface — AID-H-006.002 names 'app-action arguments' in model output, AID-H-018.004 asks that an app call 'receive only the data and functions needed for that user intent', and AID-H-029.002 asks for a gate before app data 'automatically enter[s] local LLM inference context'. Q5 (Standalone LLM) is rejected because its required evidence is positive confirmation that tool execution and retrieval are not used, which the evidence contradicts. LLM/GenAI intra-axis weights therefore apply. Tier 2: Tier 2 Consumer: Apple Intelligence is a shipping consumer OS feature reached directly by members of the public through third-party apps, and the harm modelled in the evidence — exposure or manipulation of an individual's app-accessible health data, media and files — falls on individuals rather than causing physical or societal harm at scale.
Documented attack or failure path
- An attacker places crafted content where an app will forward it into an Apple Intelligence Foundation Models call — for example text the user asks the app to summarize or edit.
- A Neural Exec-style adversarial trigger embedded in that content steers the on-device model away from the app's task toward an attacker-chosen objective.
- A Unicode right-to-left override (U+202E) reorders the rendered string, so the policy-violating payload does not match input filters or output filters that inspect the raw pre-rendered text.
- The model completes the attacker's task and the internal guardrails do not fire; the researchers measured success on 76 of 100 random prompts before hardening.
- The coerced response returns to the calling app, where it can influence app actions and reach whatever data and functions that app already holds.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Input and output filtering existed and constrained the attack: the researchers had to add Unicode directionality obfuscation on top of adversarial steering specifically because a naive payload would have been caught, which is why this scores at the 'basic filters, bypassed by encoding' rubric level rather than at zero.
- The OS per-app sandbox and entitlement model bounded the blast radius: the evidence frames the risk as exposure of data and functions 'already available to that app', with no demonstrated crossing into other apps, other users or OS state.
- On-device execution kept the affected content off cloud infrastructure, which the brief credits as reducing some exposure.
- Remediation existed and shipped at the platform layer: Apple hardened the affected systems in iOS 26.4 and macOS 26.4, so the fleet-wide fix needed no per-app change, and no in-the-wild exploitation is reported.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.09–0.74 (midpoint 0.41), Tier 2 MVT 0.50 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.35 | Ro-1 = 0.25 — basic filters resist naive attacks but fail under a moderate perturbation budget, with ASR remaining above 50%. It is not 0.00 because ASR is below the 80% failure threshold and because adversarial resistance controls demonstrably existed and had to be evaded rather than being absent. | The researchers report the Neural Exec plus Unicode RLO combination succeeded on 76% of 100 random prompts against the pre-hardening on-device model — an Attack Success Rate of 0.76 measured against the shipping system. Filters and internal guardrails were present but defeated by an obfuscation technique that required no privileged access.source: researcher |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 2 MVT 0.50 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.25w 0.25 | Tr-3 = 0.25 — partial records exist (the OS build identifies the deployed model configuration and app entitlements are inventoriable through MDM) but the per-call record omits the critical fields: which app invoked the model, what entered context, what was returned and which app action the output influenced, so an individual inference session cannot be reconstructed by a defender. | The brief's additional consideration asks teams to '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' — a visibility layer it recommends creating, and therefore one that did not exist for the assessed configuration.source: brief |
| Privacy (Pr) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 2 MVT 0.55 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.25w 0.25 | Pr-3 = 0.25 — some minimization controls exist (on-device processing keeps the data off cloud infrastructure and the OS gates whole data classes at the app-permission layer) but the primary inference path retains and forwards more sensitive data than the task requires, with no per-use necessity check. | AID-H-029.002 is mapped precisely because 'sensitive app data should not automatically enter local LLM inference context just because an app can read it' — in the assessed configuration there is no lifecycle-stage check of whether a specific data class is authorized for this inference use, this app and this user intent before model context is assembled. Health data, media libraries and file contents can therefore be placed into context on the strength of the app's standing read permission alone.source: brief |
| Containment (Cn) — scenario interval 0.21–0.69 (midpoint 0.45), Tier 2 MVT 0.55 indeterminate | |||
| Cn-1Scope Enforcement | 0.50w 0.16 | Cn-1 = 0.50 — core scope controls block the common violation class (cross-app and cross-user access) but edge cases remain within the delegated envelope, because the coerced model inherits everything the app can reach rather than only what the user's intent required. | Two-sided. The OS enforces per-app sandboxing, controlled IPC and entitlement checks (AID-I-007 is mapped as a hardening of an existing boundary, not as a missing one), and the reported impact stays inside the calling app. What is absent is intra-app narrowing: AID-H-018.004 states that a prompt injection which hijacks a summarization or editing task 'should not inherit broad access to health data, media libraries, file operations, or other app capabilities', which is the state the researchers describe.source: brief |
| Cn-2Escalation Prevention | 0.50w 0.16 | Cn-2 = 0.50 — privilege boundaries block the common escalation paths (the OS entitlement model holds) but the multi-step path from a hijacked text task to a consequential app action inside the same entitlement set is not separately authorized, logged or approved. | No privilege elevation beyond the calling app's existing entitlements is demonstrated or claimed: the risk is described as manipulation of 'data and functions already available to that app'. Against that, the controls that would gate high-risk use within the envelope are recommended rather than present — AID-M-009.002 asks for an authority envelope recording which actions require confirmation, denial or a narrower data view, and AID-H-029.002 asks for a lifecycle-stage authorization gate.source: brief |
| Cn-3Output Filtering Robustness | 0.25w 0.20 | Cn-3 = 0.25 — basic filters exist but are bypassed by an encoding technique; the unsafe-output escape rate tracks the measured 76% success and is far above the sub-5% level the 0.75 anchor requires. | 'The attack explicitly bypassed output filtering.' A Unicode right-to-left override made the response pass inspection as a raw string while rendering as offensive, policy-violating text — the brief's own worked illustration is that a string still containing .exe can display as .pdf. AID-H-006.002 is rated Very High precisely because responses must be normalized and inspected after rendering, before display or handoff to app logic.source: researcher |
Unknown, not N/A: 17 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.25 | The model generates content that app logic consumes, and the brief's remediation — 'sensitive data and mutating actions should require explicit user or policy approval before being exposed to model context or model-directed workflows' — establishes that such approval was not universally required in the assessed configuration. That places it at the human-on-the-loop anchor: routine model-directed work proceeds inside pre-defined app boundaries with the user able to observe and override, rather than at the per-action confirmation anchor (0.25) or at full autonomous execution (1.00), neither of which the evidence supports. |
| AsAttack Surface Exposure | 0.75w 0.35 | Scored exactly at the anchor, deliberately, and therefore not counted as elevated under the strictly-greater-than-0.75 rule for N_elevated. The assessed system exposes no inbound network interface and has no agent-to-agent or MCP surface, which rules out 1.00; but it ingests unvalidated external content at consumer scale through an open population of third-party apps, any of which can pass attacker-authored text into inference — the 0.75 anchor's external ingestion from partially trusted sources. |
| CpCascade Potential | 1.00w 0.20 | No System Dependency Graph exists for the assessed deployment, so DGC cannot be met and the Section 3.2 worst-case default applies. The observed impact does not independently reach the 1.00 anchor: the demonstrated effect is filter bypass and policy-violating generation, with no ungated path shown to a P3/P4 node and no delegated-irreversible action executed. With a verified graph for a specific app, the reconstruction would plausibly land at 0.50–0.75 — reachability bounded by the app sandbox (LRR ≤ 0.75) and privilege amplification of at most one to two tiers inside the app's own entitlement set — with the exact value depending on whether that app holds payment, messaging or file-mutation authority.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.25w 0.20 | A vendor fix shipped: Apple hardened the affected systems in iOS 26.4 and macOS 26.4, and fleet remediation is then staged endpoint-ring deployment with rollback readiness — infrastructure work measured in days per ring, not retraining. Scored at 0.25 rather than 0.00 because remediation is a platform release the operator cannot author and must wait for and deploy, and because the residual susceptibility of an LLM to instruction/data confusion is reduced by hardening rather than eliminated. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.30 | Slightly above the minimal anchor. The model, vendor and deployment surface are documented (Apple's on-device foundation model reached through the Foundation Models framework) and the OS build number gives a precise, verifiable identifier for the assessed configuration versus the hardened one — better than a bare model name. But training data, weights, guardrail internals and evaluation artifacts are undisclosed, no per-app tool or data-class inventory exists, and there is no cryptographic or independently reviewed provenance evidence, so the 0.50 partial-record anchor is well out of reach. |
| Ec — Public evaluation coverage | 0.26 | coverage 0.26 (6 of 23 applicable sub-metrics) × independence 1.00 × fidelity 1.00. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.14 | Evidence dated 2026-04-09; age 126 days on the workpaper reference date. Components: T_containment 0.14 · C_event 0.35 · T_calendar 0.38 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_containment. dt_days = 126, measured from the RSAC disclosure date 2026-04-09 to the assessment date 2026-08-13. agentic = true because the architecture class is Tool-Calling / Connected GenAI, where the app-facing data and capability envelope can be reprovisioned at runtime (app installs, entitlement grants, OS updates), so the containment staleness floor applies. baw = false: the evidence establishes no cross-session memory writable by the model, no runtime agent-to-agent messaging, no self-modifying prompts or configuration and no closed feedback loop for the assessed configuration, so the behavioural floor does not bind. C_monitor = 0.65 because the bypass produced no detection signal — the filters were the detection, and the brief has to recommend building endpoint-level visibility into local LLM activity from scratch. C_event = 0.35 because Apple's hardening in iOS 26.4 / macOS 26.4 is a model- and guardrail-level change to the assessed system: the configuration these measurements describe has been superseded in patched fleets, and no targeted post-hardening re-measurement is published. C_evidence = 0.85 because the residual instruction/data-separation weakness and the open per-intent capability-scoping gap are unresolved by the patch. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.22 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-002.002 | Inference-Time Prompt & Input ValidationParent AID-H-002 (AI-Contextualized Data Sanitization & Input Validation). Only the Ro-1 leg is exercised here: canonicalizing Unicode bidirectional controls and hidden directionality before filtering is the first-line control whose absence produced the 76% ASR. The Fa-1 and Fa-3 legs are catalogue mappings this incident does not touch. | Very High | Fa-1 Fa-3 Ro-1 |
| AID-H-006.002 | Text, Markup & Structured Output Sanitization and Release GateParent AID-H-006 (AI Output Hardening & Sanitization). The Cn-3 leg is the direct evidence: the attack bypassed output filtering because inspection ran on the pre-rendered string. | Very High | Cn-3 Ro-3 |
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingParent AID-H-018 (Tool Authorization & Capability Scoping). The Cn-1 leg is what holds Cn-1 at 0.50 rather than higher: the app sandbox bounds the envelope, but nothing narrows it to the user's actual intent. Cn-6 was not scored because the evidence does not establish that model output executes actions autonomously. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-003.010 | Deployed AI Software Vulnerability Remediation LifecycleParent AID-H-003 (Secure ML Supply Chain Management). Neither mapped sub-metric is scored in this case; the technique is recorded because it governs the fleet-patch completion that underpins the Rf = 0.25 judgement. | High | Ro-4 Tr-4 |
| AID-I-007 | Client-Side AI Execution IsolationParent AID-I-007 maps directly to Cn-1 and Cn-4 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. Operationally this technique describes the per-app sandboxing and entitlement checks credited under controls_that_held and reflected in Cn-1 = 0.50; that relationship supplies direct Cn-1/Cn-4 evidence in this workpaper. | High | Cn-1 Cn-4 |
| AID-D-001.001 | Per-Prompt Content, Intent & Obfuscation AnalysisParent AID-D-001. Decoding and scoring raw, normalized, rendered and directionality-stripped views of the same input is the specific detection the RLO payload defeated. | High | Ro-1 |
| AID-M-009.002 | Authority Envelope & Action Risk ClassificationParent AID-M-009 (Agent Autonomy & Authority Governance). Evidences Cn-1 and Cn-2 here; the Cn-6 leg is why reversibility classification is discussed but not scored — the classification is recommended, while the evidence never establishes an automated action path to classify. | High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-029.002 | Lifecycle-Stage Authorization GateParent AID-H-029 (AI Data-Use Authorization & Lifecycle-Stage Boundary Enforcement). The Pr-3 leg is the direct evidence for the data-minimization score: app-readable sensitive data enters inference context without a per-use authorization check. | Medium | Pr-1 Pr-3 Pr-4 |
WHAT THIS CASE TEACHES
Controls that held move the numbers as much as the ones that failed: a measured 76% attack success rate coexists with Cn-1 and Cn-2 at 0.50 (the OS app sandbox bounded the blast radius) and Rf at 0.25 (a platform patch shipped), so only Cascade Potential is elevated, N_elevated stays at one and no Compound Risk Alert is raised — a profile a failure-only assessment would have got badly wrong.
Sources: AIDEFEND in Action brief: Apple Intelligence Hijack: Prompt Injection Against an OS-Level Local LLM (2026-04-25) · RSA Conference (Petros Efstathopoulos, Laura Koetzle, Dario Pasquini), Is That a Bad Apple in Your Pocket? We Used Prompt Injection to Hijack Apple Intelligence (2026-04-09)