La réponse maison d'Apple à l'injection de prompt

Apple cite désormais Simon Willison nommément. Dans la session 347 de la WWDC 2026, un ingénieur sécurité d’Apple présente le risque agentique exactement comme le fil sécurité de ce blog le fait depuis un an : « we can look to Simon Willison’s Lethal Trifecta, which describes that a user is in most danger whenever an agentic system has: access to private data, exposure to untrusted content, and the ability to externally communicate. »¹ La session, le lab du groupe Privacy and Security et une annonce sur security.apple.com la même semaine composent l’image la plus complète à ce jour de la façon dont le fournisseur de plateforme à la plus grande flotte d’appareils envisage de sécuriser les agents : des garde-fous déterministes comme base, des garde-fous probabilistes en renfort, et l’attestation d’infrastructure sous l’ensemble.

La lethal trifecta, citée à 5:55 dans la session 347.

En bref

• La session 347 est la doctrine maison d’Apple contre l’injection de prompt : identifier le contexte non fiable par modélisation des menaces, puis « focus on deterministic mitigations as a baseline because their security guarantees are easier to audit and reason about », avec des mitigations probabilistes comme le spotlighting superposées par-dessus.¹
• Les garde-fous sont des API livrées, pas des conseils. Les modificateurs d’événements de cycle de vie de Foundation Models offrent des points d’accroche déterministes : .onToolCall intercepte chaque appel d’outil avant son exécution et le bloque en levant une erreur, et .historyTransform réécrit le transcript avant chaque passe d’inférence pour les délimiteurs de spotlighting et la rédaction des PII.¹
• App Intents applique le risque automatiquement : les intents héritent des métadonnées de risque des schémas qu’ils adoptent, un système d’évaluation du risque déclenche des confirmations contextuelles, et authenticationPolicy ne peut être surchargé que vers plus strict.¹
• La même semaine, Apple a étendu Private Cloud Compute au-delà de ses propres centres de données vers Google Cloud sur du matériel NVIDIA, en conservant les mêmes cinq exigences fondamentales et en enracinant l’attestation logicielle « in at least two separate roots of trust from independent vendors ».²
• Le lab du groupe Privacy and Security a complété la texture : Apple décrit l’usage de cette pile déterministe-plus-probabiliste à travers Siri AI, Safari et Xcode, dont les fonctionnalités agentiques utilisent des listes d’autorisation d’outils lorsque Xcode agit comme serveur MCP.³

La doctrine : le déterministe d’abord, le probabiliste ensuite

La session 347 fait cheminer une application d’exemple à travers un modèle de menaces qui paraîtra familier à quiconque exploite des agents en production. L’injection de prompt indirecte y est définie comme « instructions embedded in extra context provided to the model with the intent to redirect control flow », et la session sépare ses conséquences en deux effets à distinguer : l’empoisonnement de données, « an attacker influencing the parameters of an executed action », et l’empoisonnement d’action, « where the attacker influences what action to execute ».¹ La session est honnête sur l’état de l’art d’une manière rare dans la documentation des fournisseurs : « solving indirect prompt injection is an active research area, meaning that our best approach at the moment is to understand how much your app is at risk, and aim to mitigate that risk. »¹

Le principe d’ordonnancement est la partie à citer dans les revues de conception. Les mitigations déterministes viennent en premier « because their security guarantees are easier to audit and reason about » ; les mitigations probabilistes valent la peine d’être ajoutées car « different models could more effectively enforce these restrictions », mais la session concède aussitôt la limite : le spotlighting « is a probabilistic mitigation because the prompt injection could be constructed in a way that negates the spotlighting ».¹ Les confirmations utilisateur et les exigences de déverrouillage d’appareil tombent du côté déterministe du grand livre. La rédaction empêche les PII d’atteindre le modèle, « and thus cannot be exfiltrated ».¹ Apple indique avoir utilisé ces mitigations dans la conception de Siri AI.¹

Une subtilité du modèle de menaces mérite l’attention, car elle attrape un cas que la plupart des listes d’autorisation manquent. Une action de création de minuteur paraît inoffensive jusqu’à ce que l’on remarque son paramètre d’étiquette optionnel : une injection de prompt peut fixer l’étiquette à un texte contrôlé par l’attaquant, et « a subsequent query to list timers, can then pull this attacker controlled data into that context, thus poisoning the new context too ».¹ Les outils sans effet de bord dotés de champs texte modifiables sont des mécanismes de persistance pour les injections.

Les API de garde-fous de Foundation Models

La moitié implémentation de la session projette la doctrine sur deux surfaces livrées. Dans le framework Foundation Models, les modificateurs d’événements de cycle de vie sont des « callbacks that deterministically trigger at certain lifecycle points in a session execution ».¹

.onToolCall est le point de contrôle d’action. Il « is guaranteed to trigger when the LLM outputs a tool call, before the executor runs the tool », et le contrat est la partie utile : « if this callback throws an error, then the tool is never executed ».¹ L’exemple de la session protège un outil à impact financier derrière une confirmation utilisateur à un seul endroit et obtient une couverture pour chaque appel d’outil de la session. La forme est exactement celle que ce blog défendait dans les invites d’approbation ne sont pas une autorisation : la vérification réside dans le chemin d’exécution, pas dans les instructions du modèle.

.historyTransform est le point de contrôle d’entrée. Il « fires before the transcript is rendered to the model for inference », tant sur les nouvelles requêtes utilisateur que sur chaque itération de boucle, et la session l’utilise pour les deux mitigations de prompt : envelopper les sorties d’outils provenant de sources non fiables dans des délimiteurs de spotlighting, et remplacer les données sensibles par un marqueur de rédaction.¹ Un détail qui compte pour les implémenteurs : les entrées transformées sont restreintes à la passe d’inférence courante seulement, de sorte que les transformations se réappliquent à chaque itération, l’annotation @SessionProperty servant d’échappatoire pour les transformations à état coûteuses.¹

App Intents : des métadonnées de risque dont on hérite, qu’on n’écrit pas

Le versant tourné vers Siri tire ses garde-fous du système de schémas. Lorsqu’un intent adopte un schéma d’intent, les métadonnées de risque « is automatically assigned » d’après les effets de bord du schéma : les actions destructrices, exfiltrantes et modifiant du contenu partagé sont plus risquées, et « the system is more likely to trigger confirmations for high-risk tools ».¹ Un système d’évaluation du risque combine ces métadonnées statiques avec l’état dynamique du système pour décider, de façon contextuelle, s’il faut interposer une confirmation avant l’exécution de l’intent ; refuser bloque entièrement l’intent.¹

L’exposition sur l’écran verrouillé reçoit le même traitement. Parce que Siri fonctionne sur un appareil verrouillé, un attaquant en possession physique peut atteindre vos intents ; aussi les intents personnalisés fixent-ils une authenticationPolicy, les schémas portent des valeurs par défaut fondées sur la sensibilité, et la contrainte est exactement juste : « you can override the schema policy, but only to make it stricter », avec une erreur de compilation nommant la politique minimale autorisée si vous tentez de l’affaiblir.¹ Le compilateur refusant de vous laisser sous-protéger une action est la mitigation d’injection de prompt la plus typiquement Apple que l’on puisse imaginer.

La couche d’infrastructure : PCC quitte les centres de données d’Apple

Trois jours avant la diffusion de la session, Apple a publié « Expanding Private Cloud Compute » sur son blog sécurité : les nouvelles charges de travail Apple Intelligence tournent désormais sur Google Cloud avec des GPU NVIDIA, « extending our industry-leading PCC privacy commitments to third-party data centers for the first time ».² Les cinq exigences fondamentales sont reconduites inchangées : « stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency ».² Ce qui change, c’est l’implémentation : NVIDIA Confidential Computing, des CPU Intel avec TDX, et la puce Titan de Google.²

Deux choix de conception se détachent par rapport au statu quo de l’informatique confidentielle. Pour les composants qui pourraient exfiltrer des données utilisateur en cas de compromission, « software attestation is rooted in at least two separate roots of trust from independent vendors », et Apple maintient « a cryptographically verifiable, append-only ledger of all Google Cloud hardware that is part of the PCC fleet » contre les attaques de chaîne d’approvisionnement.² Les patrons architecturaux de PCC sur puce Apple sont également reconduits : analyse réseau par requête dans un processus dédié à espace de noms isolé, logiciel d’inférence partagé recyclé sur une courte durée de vie, clés attestées détenues dans une VM confidentielle séparée, isolée des entrées externes.² Le contrôle reste centralisé : « Apple retains complete control over PCC software; Apple devices will only trust PCC software that is cryptographically approved by Apple », avec tous les binaires publiés pour inspection publique et des nœuds en mode recherche, actifs, accessibles via l’Apple Security Bounty Program.² Le déploiement est échelonné, « gradually ramping towards the complete set of protections throughout the summer preview period ».²

Ce que le lab a ajouté

Le lab du groupe Privacy and Security s’est tenu la même semaine, et Apple ne publie aucun sous-titre pour les labs ; ce qui suit est donc paraphrasé d’un enregistrement transcrit localement plutôt que cité.³ Le panel a relié la doctrine de la session aux surfaces livrées : la pile déterministe-plus-probabiliste tourne à travers Siri AI, Safari et les fonctionnalités agentiques de Xcode, et lorsque Xcode agit comme serveur MCP, il contraint les agents avec des listes d’autorisation des outils permis.³ Sur l’architecture de Siri AI, un panéliste a décrit un démon dédié, durci et en bac à sable, avec contrôle par habilitations comme unique voie pour collecter et formater les données utilisateur avant leur départ vers Private Cloud Compute, les requêtes multi-tours redemandant la permission pour les données nouvellement accédées en milieu de conversation.³

Deux autres fils du lab méritent d’être signalés pour suivi. Le panel a affirmé que les garanties de confidentialité de Foundation Models ne s’étendent pas aux modèles tiers atteints via le protocole de modèle de langage du framework ; le développeur est responsable de lire les conditions de ces fournisseurs et de les divulguer en conséquence.³ Et sur la question du cycle de vie des passkeys qui a longtemps freiné l’adoption de WebAuthn, un panéliste a pointé l’API Signal comme la réponse résolue : les standards web définissent désormais signalUnknownCredential, signalAllAcceptedCredentials et signalCurrentUserDetails pour maintenir les identifiants synchronisés entre relying parties et authentificateurs, et l’API est réelle et livrée dans W3C WebAuthn Level 3.⁴

Ce qu’il faut en retenir

La partie utile n’est pas qu’Apple a résolu l’injection de prompt ; la session dit clairement que personne ne l’a fait. La partie utile est de voir un fournisseur de plateforme s’engager sur un ordonnancement : les contrôles déterministes dans le chemin d’exécution d’abord, les indices au niveau du modèle ensuite, l’attestation d’infrastructure en dessous. Pour les constructeurs d’agents hors des plateformes d’Apple, chaque pièce a un équivalent : .onToolCall est votre intercepteur d’appels d’outils, .historyTransform est votre désinfectant de contexte, les métadonnées de risque héritées du schéma sont votre table de classification d’outils, et les surcharges d’authenticationPolicy uniquement vers plus strict sont votre plancher de politique. Les noms de framework sont ceux d’Apple ; l’architecture est portable, et elle correspond à la défense en profondeur que ce blog a exposée dans un agent avec deux entrées non fiables et la défense à l’exécution pour les agents augmentés d’outils.

FAQ

Quelle est la défense recommandée par Apple contre l’injection de prompt ?

Modélisez d’abord les menaces (identifiez les sources de contexte non fiable et les effets de bord des actions), puis appliquez « deterministic mitigations as a baseline because their security guarantees are easier to audit and reason about », avec des mitigations probabilistes telles que le spotlighting ajoutées par-dessus.¹ Concrètement : confirmations utilisateur et exigences de déverrouillage d’appareil sur les actions risquées, rédaction des PII et délimiteurs de spotlighting sur le contexte non fiable.

Quelles API implémentent ces garde-fous ?

Dans Foundation Models, les modificateurs d’événements de cycle de vie : .onToolCall (intercepte de façon déterministe chaque appel d’outil avant exécution ; lever une erreur bloque l’outil) et .historyTransform (réécrit la fin du transcript avant chaque passe d’inférence), avec @SessionProperty pour les transformations persistantes.¹ Dans App Intents, les métadonnées de risque héritées du schéma pilotent les confirmations contextuelles, et authenticationPolicy contrôle l’accès sur écran verrouillé avec des surcharges uniquement vers plus strict.¹

Apple a-t-il vraiment déplacé Private Cloud Compute vers le cloud de Google ?

Oui, pour les nouvelles charges de travail Apple Intelligence. PCC s’étend désormais à Google Cloud sur des GPU NVIDIA avec Intel TDX et la puce Titan de Google, en conservant les mêmes cinq exigences PCC, des racines d’attestation à double fournisseur, un registre matériel en ajout seul, et une approbation logicielle réservée à Apple, déployé progressivement durant une période d’aperçu estivale.² Les garanties de PCC ne s’étendent toujours pas aux modèles tiers comme Gemini ou Claude atteints via le protocole de modèle de langage.³

Tout cela s’applique-t-il en dehors des plateformes Apple ?

L’architecture, oui. Les intercepteurs de chemin d’exécution, les désinfectants de contexte, la classification du risque des outils et les planchers de politique sont des patrons portables ; les versions d’Apple sont notables parce qu’elles sont livrées comme API de framework dotées de contrats déterministes plutôt que comme des recommandations.

La pile de mitigations d’Apple atterrit sur un territoire que ce blog cartographie depuis un an : le cadrage de la trifecta dans un agent avec deux entrées non fiables, l’argument du chemin d’exécution dans les invites d’approbation ne sont pas une autorisation, et l’histoire d’infrastructure dans Foundation Models et Private Cloud Compute. Le hub complet de la série est la Série Écosystème Apple.

Références