iOS 27 Security: What WWDC 2026’s AI Features Mean for Mobile App Risk

Apple’s most AI-intensive developer conference ever just redefined the attack surface for every iOS app — and the security implications are immediate.

What happened at WWDC 2026?

Apple announced a sweeping transformation of its developer platform at WWDC 2026. On-device large language models, agentic workflows that take real-world actions, third-party model integrations from Anthropic and Google, and a new inference framework for running 70-billion-parameter models locally. All of lands in iOS 27 and macOS 27. Apple even dedicated a full security session to the risks these capabilities introduce.

For enterprises securing mobile fleets, this is not a future consideration. Every app that adopts these frameworks ships new attack surfaces. Those surfaces require mobile app security testing before they are deployed.

This post breaks down the security-critical announcements from WWDC 2026, explains what each means for mobile app risk, and identifies where automated and guided security testing can make the difference.

What is indirect prompt injection, and why does it matter on iOS 27?

For the first time at WWDC, Apple dedicated a session explicitly to the security risks of AI-powered features — “Secure your app: Mitigate risks to agentic features” (Session 347). The session addressed indirect prompt injection, data exfiltration via AI tool call and action poisoning, and provided concrete mitigations using Apple’s own frameworks.

Indirect prompt injection occurs when an app feeds untrusted external content — calendar events, social feeds, web results — into a large language model, and an attacker embeds instructions in that content to redirect the model’s behavior. This maps directly to OWASP Top 10 for LLMs (LLM01).

Apple illustrated this with a concrete scenario: a user’s calendar contains an event crafted by an attacker with hidden instructions. The app’s AI agent reads the calendar as context, the injected instructions redirect the model, and the agent executes a financial transaction, leaks private data via a public post, or deletes user content, all without the user’s intent.

Apple framed the risk using Simon Willison’s “Lethal Trifecta”: an agentic system is most dangerous when it combines access to private data, exposure to untrusted content and the ability to take actions with external side effects. iOS 27 apps adopting Foundation Models and Siri via App Intents will routinely hit all three conditions.

Apple was explicit: probabilistic mitigations could be constructed in a way that negates them. Only deterministic controls provide security guarantees that are auditable.

How do attackers exploit agentic iOS apps?

Apple classified the injection effects into two categories:

• Data poisoning — an attacker manipulates the parameters of an action. A user asks the agent to send a message to their contact; injected instructions change the recipient to the attacker. Financial, legal and healthcare apps face immediate risk here.

• Action poisoning — an attacker manipulates which action fires. A user asks to summarize an email; injected instructions steer the model to open a malicious URL constructed from attacker-controlled data.

Apple acknowledged directly that solving indirect prompt injection is an active research area, placing the burden on developers to threat-model their apps and implement mitigations  and on security testers to verify those mitigations hold.

What mitigations does Apple provide, and what still requires testing?

Apple outlined both deterministic and probabilistic mitigations:

• Deterministic mitigations (auditable, higher assurance):
  • PII redaction before data reaches the LLM, using the .historyTransform modifier in Foundation Models
  • User confirmation gates on high-risk tool calls via .onToolCall modifier
  • Authentication requirements for Siri intents executing on the lock screen
  • Risk-based contextual confirmation via App Intents schemas with inherited side-effect metadata

• Probabilistic mitigations (model-dependent, lower assurance):
  • Spotlighting — wrapping untrusted input in delimiter tags to signal distrust to the model
  • In-context instructions flagging untrusted data sources

Apple was explicit: probabilistic mitigations could be constructed in a way that negates them. Only deterministic controls provide security guarantees that are auditable.

Whether a developer correctly implemented .onToolCall guards, whether PII actually reaches the model, whether lock-screen authentication policies are correctly enforced —  none of these can be verified through developer self-attestation. They require require dynamic testing under adversarial conditions.

What are the security risks of Apple’s new Foundation Models Framework?

Session 241 announced a dramatically expanded AI model landscape for iOS 27 — and a new open protocol that makes any LLM usable within Apple apps.

Three model tiers ship with distinct security properties:

• On-Device system language model — rebuilt for iOS/macOS 27, now accepting image inputs alongside text. Runs entirely on-device with no data leaving the device. Lower risk for data exfiltration, but still vulnerable to prompt injection from locally-sourced untrusted content.

• Private Cloud Compute (PCC) — the model powering many Apple Intelligence features, now available to developers. Features a 32,000-token context window, reasoning capability and privacy guarantees verified by independent researchers. Apple states that no prompts are stored. For security teams, PCC expands the perimeter of where sensitive data may travel. Regulated data categories (healthcare, finance, legal) may require documented controls around any cloud model usage, even with Apple privacy guarantees.

• Third-party server models (Anthropic Claude, Google Gemini) — both companies  are publishing Swift packages that give iOS/macOS developers direct access to frontier models via the new LanguageModel protocol. Authentication tokens must be fetched securely. Apple explicitly warned developers to never store private keys in the app binary, to use OAuth for token acquisition and to store tokens in Keychain. API keys hardcoded in app binaries are a well-known vulnerability category in NowSecure’s assessment database. This new integration pathway creates fresh opportunities for that mistake.

• Core AI local models — the new Core AI framework lets developers ship third-party open-source models, including 70B-parameter LLMs, running locally on Apple Silicon at no server cost. Models from Hugging Face’s MLX community are directly loadable. Each shipped model is a new binary artifact that warrants supply-chain scrutiny: where did the model weights originate, and were they modified?

What is the model supply chain risk introduced by LanguageModel Protocol?

Session 339 explains how any third party can publish a Swift package implementing the LanguageModel protocol, making their model drop-in compatible with any Foundation Models app. Anthropic and Google are the announced partners, but the protocol is open.

For enterprise security teams, this introduces a model supply chain risk that mirrors dependency supply chain risks in traditional software. An app declaring a LanguageModel dependency on a third-party Swift package is embedding a trained model whose weights, training data and inference behavior may not be independently auditable. 

Session 339 also noted that cloud-based LanguageModel packages should implement App Attest for device verification. This creates a testable chain: is the model package correctly attesting the device before sending prompts to the cloud?

What security risks does Core AI introduce for enterprise apps?

Session 324 introduced Apple’s new inference framework for running large, custom AI models entirely on-device. Core AI is the engine powering on-device Apple Intelligence, now available to developers.

• Models ship with apps. A Core AI .aimodel file is an artifact bundled with the app, converted from PyTorch, and specialized for Apple Silicon on-device. The model weights, architectures, and behaviors are part of the application binary. This is a new category of testable artifact — one that existing static analysis pipelines are not configured to inspect.

• No network traffic doesn’t mean no risk. Core AI models run locally with no server dependency. This eliminates API key exposure and traffic interception risks but does nothing to eliminate prompt injection risks from locally-processed untrusted data. The context sent to the model can still contain injected instructions.

• Model specialization creates a new fingerprinting surface. Core AI models are specialized for the device’s hardware configuration and OS version. Specialization artifacts are cached locally. These caches may contain recoverable representations of the model weights, a potential IP and data exposure risk on shared or unmanaged devices.

• Custom Metal 4 kernels ship inside models. Session 325 showed that developers can embed custom GPU computation kernels written in Metal Shading Language directly inside their .aimodel files. These kernel payloads represent executable code shipped alongside model weights — a new vector requiring review in regulated environments.

• Quantized models may behave differently under adversarial input. Session 325 demonstrated aggressive 4-bit weight quantization on production models. Quantized models can exhibit different behavior at the edges of their input distribution compared to their full-precision counterparts. Adversarial prompt testing of quantized on-device models is an emerging discipline NowSecure is actively tracking.

How does Siri expand the attack surface in iOS 27?

Sessions 343, 344 and 295 document how deeply iOS 27 apps can integrate with Siri through App Schemas — and how much device and system state those integrations can access and affect.

A fully-integrated iOS 27 app can expose intents to Siri that read and write calendar events, contacts and messages; delete photos, files, and application data; execute financial transactions; post to social feeds; control physical devices; navigate to arbitrary app views; and chain actions across multiple apps via structured entity sharing.

All of this is triggerable from the Siri lock screen — by voice, with no device unlock required — unless the developer explicitly sets authenticationPolicy = .requiresAuthentication on the intent. Apple’s session noted that this lock-screen access means an attacker in physical possession of a locked device can potentially invoke an app’s intent via Siri for data exfiltration or malicious actions. For a banking app, that means an unattended locked phone is a potential transaction vector.

For custom intents not based on Apple’s schemas, authentication policy must be set manually. Whether developers correctly identify which custom intents are sensitive enough to require authentication is a testable security behavior — not an assumption.

Does Apple’s AppIntentsTesting framework cover security testing?

Session 295 introduced AppIntentsTesting, a new XCTest-based framework for automated integration testing of App Intents. It enables developers to test intent execution, entity queries, Spotlight indexing, and view annotations in a real device environment.

AppIntentsTesting is developer functionality testing, not security testing. It verifies that an intent does what it’s supposed to do when called correctly. It does not test what happens when an intent is invoked from a prompt-injected context, verify that authentication policies block lock-screen invocation of sensitive intents, probe whether entity data returned through Siri is properly access-controlled or assess what context is leaked to the model before action execution.

NowSecure Platform mobile app security testing covers the layer that AppIntentsTesting does not — testing intents under adversarial conditions, verifying authentication enforcement and mapping data flows across the app/Siri/model boundary.

Dynamic Profiles and Agentic Orchestration: New Complexity, New Risk

Sessions 241 and 242 introduced Dynamic Profiles — a Foundation Models API enabling apps to switch between models, instructions and tools within a single LanguageModelSession based on application state. This powers multi-agent architectures within a single app.

Two orchestration patterns matter for security:

• Baton-pass — one agent uses a tool call to transfer control to another agent within the same session. The full transcript history is visible to both agents. Any prompt injection that enters the transcript in one agent context is inherited by every subsequent agent in the session.
• Phone-a-friend — one agent spawns an isolated sub-session for a specific task. The sub-session has an independent transcript. This provides better isolation between agents but introduces a new surface: what data the parent agent passes to the spawned session.

Apple’s security session noted that lifecycle event modifiers (.onToolCall, .historyTransform) must be re-applied at each agentic loop iteration — they are scoped to a single inference iteration and do not persist automatically. An app that applies PII redaction only on initial context construction, but not on subsequent tool outputs, exposes PII to the model on every tool call round-trip. This is a subtle misconfiguration that requires dynamic testing to detect.

What does NowSecure test for iOS 27 AI features?

iOS 27 is a platform where apps run frontier LLMs locally with no network dependency, those models call tools with real financial and device side effects, fed context that includes untrusted external data by design — and Siri can trigger all of it from the lock screen without a device unlock. Any third-party LLM package can be dropped in as a dependency, and macOS apps now carry the same app integrity verification requirements as iOS.

Apple shipped the capability. What enterprises and developers need is verification that the implementation holds under adversarial conditions — and that the net risk posture of each app is understood before it reaches users.

NowSecure testing covers these new surfaces:

• Prompt injection verification — testing agentic features for indirect prompt injection via tool outputs, calendar data, notification content and other untrusted context sources, mapped directly to the threat model Apple described in Session 347.
• App Attest implementation review — automated verification that App Attest keys are correctly generated and stored, that server-side attestation validation logic is implemented and current with iOS 27 extensions, that assertion counters are validated and that the fraud metric is properly integrated into risk assessment pipelines.
• Authentication policy audit — dynamic testing of Siri-exposed intents to verify that authentication policies block lock-screen invocation of sensitive actions as intended, including custom intents not based on Apple schemas.
• AI model supply chain analysis — static and dynamic analysis of bundled Core AI model files, including inspection of embedded Metal kernel payloads, verification of model provenance and assessment of quantization impact on security behavior.
• Data flow tracing across the model boundary — verification that PII and sensitive data do not reach the LLM in violation of .historyTransform redaction logic, including edge cases across tool call round-trips.
• Third-party LLM package assessment — review of LanguageModel protocol implementations for credential hardcoding, insecure token storage and missing App Attest integration for cloud-based models.

What should security and development teams do now?

Security and compliance teams: Update mobile app security requirements to include AI-specific testing criteria before iOS 27 apps are approved for enterprise deployment. The attack vectors Apple described in Session 347 — indirect prompt injection, lock-screen action invocation, agentic data exfiltration — are exploitable today in apps that adopt these frameworks without proper mitigations.

Development teams: Conduct threat modeling on every agentic feature using the framework Apple outlined .Identify untrusted context sources, classify action side effects by risk level and map required mitigations (redaction, confirmation gates, authentication requirements) to each. Then verify those mitigations with adversarial testing.

Enterprise mobile programs: Update your NowSecure Platform assessment profiles to include the new iOS 27 AI-specific test cases. NowSecure’s mobile security experts are actively mapping the WWDC 2026 announcements to the Platform’s automated assessment and guided testing workflows. Contact your NowSecure account team to discuss how these new capabilities affect your mobile risk posture and assessment schedule.

There are several months before iOS 27 and the new AI capabilities are available. Use the time to prepare your security measures. First-party apps should be addressed during development before production. Third-party apps that are approved for sensitive data should be continuously monitored via the App Store because every new version is a new AI risk.

NowSecure is the leading provider of mobile app security testing software and services. With 12+ years of mobile security expertise, 11,000+ mobile penetration tests completed and 8M+ automatically identified vulnerabilities, NowSecure helps the world’s largest enterprises, government agencies and mobile-first organizations secure their iOS and Android applications.

Visit nowsecure.com or contact your account team to assess your iOS 27 security posture.