prompt injection に対する Apple のファーストパーティの回答
Apple はついに Simon Willison の名を直接引用しました。WWDC 2026 のセッション 347 で、Apple のセキュリティエンジニアはエージェント的リスクを、このブログのセキュリティスレッドがこの1年間語ってきたとおりに捉えています。「Simon Willison の Lethal Trifecta に目を向けることができます。これは、エージェント的システムが、プライベートデータへのアクセス、信頼できないコンテンツへの露出、そして外部と通信する能力という3つを兼ね備えたとき、ユーザーが最も危険にさらされる、というものです」1。このセッション、Privacy and Security グループのラボ、そして同じ週に出された security.apple.com の発表を合わせると、最大規模のデバイス群を抱えるプラットフォームベンダーがエージェントの安全確保をどう考えているかについて、これまでで最も完全な姿が見えてきます。すなわち、ベースラインとしての決定的なガードレール、それを補強する確率的なガードレール、そしてそのすべてを下支えするインフラの attestation です。
lethal trifecta は、セッション 347 の 5:55 で引用されています。
TL;DR
- セッション 347 は Apple のファーストパーティの prompt injection ドクトリンです。まず脅威モデリングによって信頼できないコンテキストを特定し、次に「決定的な緩和策をベースラインとして重視します。そのセキュリティ保証は監査も論証もしやすいからです」とし、その上に spotlighting のような確率的な緩和策を重ねます1。
- これらのガードレールは助言ではなく、実際に出荷される API です。Foundation Models のライフサイクルイベント修飾子が決定的なフックを提供します。
.onToolCallはすべてのツール呼び出しを実行前に傍受し、エラーをスローすることでブロックします。.historyTransformは、spotlighting の区切り文字や PII の墨消しのために、各推論パスの前にトランスクリプトを書き換えます1。 - App Intents はリスクを自動的に強制します。intent は採用するスキーマからリスクメタデータを継承し、リスク評価システムが文脈に応じた確認を発動させ、
authenticationPolicyはより厳しい方向にのみオーバーライドできます1。 - 同じ週、Apple は Private Cloud Compute を自社データセンターの外にまで拡張し、NVIDIA ハードウェア上の Google Cloud へと広げました。同じ5つの中核要件を維持しつつ、ソフトウェアの attestation を「独立したベンダーによる少なくとも2つの別個の信頼の起点(root of trust)」に根付かせています2。
- Privacy and Security グループのラボがその細部を補いました。Apple はこの「決定的+確率的」スタックを Siri AI、Safari、Xcode にわたって用いていると説明しており、Xcode が MCP サーバーとして動作する際には、そのエージェント機能がツールの allowlist を使います3。
ドクトリン: 決定的が先、確率的が後
セッション 347 は、本番環境でエージェントを運用したことのある人なら見覚えのある脅威モデルを、サンプルアプリを通して順を追って説明します。間接的な prompt injection は「制御フローを書き換える意図をもって、モデルに与えられる追加コンテキストの中に埋め込まれた命令」と定義され、セッションはその帰結を、区別して扱う価値のある2つの効果に分けます。データポイズニング、すなわち「攻撃者が、実行されるアクションのパラメータに影響を与えること」、そしてアクションポイズニング、すなわち「攻撃者が、どのアクションを実行するかに影響を与えること」です1。このセッションは、ベンダーの資料にしては珍しく、技術の現状について率直です。「間接的な prompt injection を解決することは活発な研究領域であり、現時点での最善のアプローチは、自分のアプリがどれだけリスクにさらされているかを理解し、そのリスクを緩和することを目指すことです」1。
順序付けの原則こそ、設計レビューで引用する価値のある部分です。決定的な緩和策が先に来るのは「そのセキュリティ保証が監査も論証もしやすいから」です。確率的な緩和策も追加する価値があります。なぜなら「異なるモデルがこれらの制約をより効果的に強制できるかもしれない」からです。しかしセッションはすぐにその限界を認めます。spotlighting は「prompt injection が spotlighting を無効化するように構成されうるため、確率的な緩和策である」のです1。ユーザーの確認やデバイスのロック解除要件は、台帳の決定的な側に位置します。墨消しは PII がモデルにそもそも到達しないようにし、「したがって持ち出されえない」ようにします1。Apple はこれらの緩和策を Siri AI の設計に用いてきたと述べています1。
脅威モデルから得られる微妙な点が一つ、注目に値します。なぜならそれは、ほとんどの allowlist が見逃すケースを捉えるからです。タイマー作成アクションは無害に見えますが、そのオプションのラベルパラメータに目を向けると様相が変わります。prompt injection はそのラベルを攻撃者が制御するテキストに設定でき、「その後のタイマー一覧の照会が、この攻撃者制御下のデータを当該コンテキストに引き込み、新しいコンテキストもまた汚染してしまう」のです1。書き込み可能な文字列フィールドを持つ副作用のないツールは、injection の永続化メカニズムになります。
Foundation Models のガードレール API
セッションの実装パートは、このドクトリンを2つの出荷済みサーフェスへと写像します。Foundation Models フレームワークでは、ライフサイクルイベント修飾子が「セッション実行中の特定のライフサイクルポイントで決定的に発火するコールバック」です1。
.onToolCall はアクションのチェックポイントです。これは「LLM がツール呼び出しを出力したとき、エグゼキュータがツールを実行する前に発火することが保証されて」おり、契約こそが有用な部分です。「このコールバックがエラーをスローすると、そのツールは決して実行されません」1。セッションの例では、金銭的な影響を持つツールを一箇所でユーザー確認の背後にゲートし、セッション内のすべてのツール呼び出しを網羅します。この形は、このブログが承認プロンプトは認可ではないで論じたものと同じです。チェックはモデルの命令の中ではなく、実行パスの中に存在するのです。
.historyTransform は入力のチェックポイントです。これは「トランスクリプトがモデルに推論用としてレンダリングされる前に発火」し、新しいユーザーリクエスト時にも、ループの各反復時にも作動します。セッションはこれを2つのプロンプト緩和策に用います。信頼できないソースからのツール出力を spotlighting の区切り文字で包むことと、機微なデータを墨消しのプレースホルダーに置き換えることです1。実装者にとって重要な細部があります。変換されたエントリは現在の推論パスのみにスコープされるため、変換は反復ごとに再適用されます。コストの高いステートフルな変換に対しては、@SessionProperty アノテーションが抜け道として用意されています1。
App Intents: 書くのではなく継承するリスクメタデータ
Siri に面した側は、そのガードレールをスキーマシステムから得ます。intent が intent スキーマを採用すると、リスクメタデータがそのスキーマの副作用に基づいて「自動的に割り当てられ」ます。破壊的なアクション、持ち出しを伴うアクション、共有コンテンツを更新するアクションはよりリスクが高く、「システムは高リスクのツールに対して確認を発動しやすくなる」のです1。リスク評価システムは、その静的なメタデータと動的なシステム状態を組み合わせ、intent が実行される前に確認を割り込ませるかどうかを文脈に応じて判断します。拒否すれば intent は完全にブロックされます1。
ロック画面への露出も同じ扱いを受けます。Siri はロックされたデバイス上でも動作するため、物理的に所持している攻撃者があなたの intent に到達できてしまいます。そこでカスタム intent は authenticationPolicy を設定し、スキーマは機微度に応じたデフォルトを備え、その制約はまさに的を射ています。「スキーマのポリシーはオーバーライドできますが、より厳しくする方向にのみです」。もし弱めようとすれば、許される最小限のポリシーを示すビルドエラーが出ます1。アクションの保護を弱めることをコンパイラが許さない、というのは、想像しうる限り最も Apple らしい prompt injection の緩和策です。
インフラ層: PCC が Apple のデータセンターを離れる
セッションが配信される3日前、Apple はセキュリティブログに「Expanding Private Cloud Compute」を公開しました。新たな Apple Intelligence のワークロードは、いまや NVIDIA GPU を備えた Google Cloud 上で動作し、「業界をリードする PCC のプライバシーコミットメントを、初めてサードパーティのデータセンターへと拡張」します2。5つの中核要件はそのまま引き継がれます。「ステートレスな計算、強制可能な保証、特権的なランタイムアクセスの不在、ターゲット不可能性、そして検証可能な透明性」です2。変わるのは実装です。NVIDIA Confidential Computing、TDX を備えた Intel CPU、そして Google の Titan チップです2。
confidential computing の現状に対して、2つの設計上の選択が際立ちます。侵害された場合にユーザーデータを持ち出しうるコンポーネントについては、「ソフトウェアの attestation を、独立したベンダーによる少なくとも2つの別個の信頼の起点に根付かせ」ます。そして Apple はサプライチェーン攻撃に備え、「PCC フリートの一部であるすべての Google Cloud ハードウェアについて、暗号学的に検証可能な追記専用の台帳」を維持します2。Apple シリコン上の PCC から受け継がれるアーキテクチャパターンもあります。専用の名前空間化されたプロセスでのリクエストごとのネットワーク解析、短い time-to-live で使い回される共有推論ソフトウェア、外部入力から隔離された別個の confidential VM に保持される attested キーです2。制御は中央に集権化されたままです。「Apple は PCC ソフトウェアの完全な制御を保持します。Apple のデバイスは、Apple によって暗号学的に承認された PCC ソフトウェアのみを信頼します」。すべてのバイナリは公開検査のために公開され、稼働中の research-mode ノードには Apple Security Bounty Program を通じて到達できます2。展開は段階的で、「サマープレビュー期間を通じて、保護の完全なセットへと徐々に引き上げて」いきます2。
ラボが付け加えたもの
Privacy and Security グループのラボは同じ週に行われました。Apple はラボについて字幕を公開していないため、以下は引用ではなく、ローカルで文字起こしした録音からの言い換えです3。パネルは、セッションのドクトリンを出荷済みのサーフェスに結びつけました。「決定的+確率的」スタックは Siri AI、Safari、そして Xcode のエージェント機能にわたって動作し、Xcode が MCP サーバーとして動作する際には、許可されたツールの allowlist でエージェントを制約します3。別の Apple Intelligence ラボは、開発者が混同しがちな2つの失敗モードの間に有用な線引きをしました。あるパネリストは、refusal error(モデル自身のアラインメント訓練がリクエストを拒否し、その失敗がガイド付き生成や構造化生成のもとで表面化するもの)を、guardrail error(別個のモデレーションモデルが、メインモデルとは独立に入力と出力を検査するもの)と区別しました5。同じパネリストは、感情的に強い表現ではあるものの正当な入力を、ガードレールに引っかけるのではなく通過させるオプトイン設定があることに触れました。その設定の正確な名称は録音では判読できず、未確認のままです5。Siri AI のアーキテクチャについては、あるパネリストが、ユーザーデータが Private Cloud Compute へ送られる前にそれを収集・整形する唯一の経路として、entitlement によるゲートを備えた専用の堅牢化されたサンドボックス内のデーモンを説明しました。マルチターンのリクエストでは、会話の途中で新たにアクセスされるデータについて改めて許可を求め直します3。
ラボからは、さらに2つのスレッドが追跡の価値ありとして挙げられます。パネルは、Foundation Models のプライバシー保証は、フレームワークの言語モデルプロトコルを介して到達するサードパーティのモデルには及ばないと述べました。それらのプロバイダの規約を読み、それに応じて開示する責任は開発者が負います3。そして WebAuthn の普及を悩ませてきた passkey のライフサイクルの問題について、あるパネリストは Signal API を解決済みの答えとして指し示しました。いまや web 標準は、relying party と認証器の間でクレデンシャルを同期し続けるための signalUnknownCredential、signalAllAcceptedCredentials、signalCurrentUserDetails を定義しており、この API は実在し、W3C WebAuthn Level 3 で出荷されています4。
ここから何を持ち帰るか
有用な点は、Apple が prompt injection を解決したということではありません。セッションは、誰も解決していないとはっきり述べています。有用なのは、あるプラットフォームベンダーが順序付けにコミットする様子を見られることです。まず実行パスの中の決定的な制御、次にモデルレベルのヒント、その下にインフラの attestation。Apple のプラットフォーム外でエージェントを構築する人にとって、それぞれの要素には等価物があります。.onToolCall はあなたのツール呼び出しインターセプタであり、.historyTransform はあなたのコンテキストサニタイザであり、スキーマ継承のリスクメタデータはあなたのツール分類テーブルであり、より厳しくのみオーバーライドできる authenticationPolicy はあなたのポリシーの下限です。フレームワークの名前は Apple のものですが、アーキテクチャは移植可能で、このブログが2つの信頼できない入力を持つエージェントとツール拡張エージェントのためのランタイム防御で示した多層防御に合致します。
FAQ
prompt injection に対する Apple の推奨される防御策は何ですか?
まず脅威モデリングを行い(信頼できないコンテキストの源とアクションの副作用を特定する)、次に「決定的な緩和策をベースラインとして適用します。そのセキュリティ保証は監査も論証もしやすいからです」とし、その上に spotlighting のような確率的な緩和策を加えます1。具体的には、リスクのあるアクションに対するユーザー確認とデバイスのロック解除要件、そして信頼できないコンテキストに対する PII の墨消しと spotlighting の区切り文字です。
これらのガードレールはどの API が実装していますか?
Foundation Models では、ライフサイクルイベント修飾子です。.onToolCall(すべてのツール呼び出しを実行前に決定的に傍受し、スローすればツールをブロックする)と .historyTransform(各推論パスの前にトランスクリプトの末尾を書き換える)であり、永続的な変換には @SessionProperty を用います1。App Intents では、スキーマ継承のリスクメタデータが文脈に応じた確認を駆動し、authenticationPolicy がより厳しくのみオーバーライドできる形でロック画面アクセスを制御します1。
Apple は本当に Private Cloud Compute を Google のクラウドへ移したのですか?
はい、新たな Apple Intelligence のワークロードについてはそうです。PCC はいまや、Intel TDX と Google の Titan チップを備えた NVIDIA GPU 上の Google Cloud にまで拡張され、同じ5つの PCC 要件、デュアルベンダーの attestation の起点、追記専用のハードウェア台帳、そして Apple のみによるソフトウェア承認を維持しつつ、サマープレビュー期間を通じて引き上げられていきます2。PCC の保証は、言語モデルプロトコルを介して到達する Gemini や Claude のようなサードパーティのモデルには依然として及びません3。
これらは Apple のプラットフォーム以外にも当てはまりますか?
アーキテクチャは当てはまります。実行パスのインターセプタ、コンテキストサニタイザ、ツールのリスク分類、ポリシーの下限は移植可能なパターンです。Apple 版が注目に値するのは、それらが助言としてではなく、決定的な契約を備えたフレームワーク API として出荷されるからです。
Apple の緩和策スタックは、このブログがこの1年間描いてきた領域に着地します。trifecta の枠組みは2つの信頼できない入力を持つエージェントで、実行パスの議論は承認プロンプトは認可ではないで、そしてインフラの物語はFoundation Models と Private Cloud Computeで扱いました。シリーズ全体のハブはApple Ecosystem シリーズです。
参考文献
-
Apple, WWDC 2026 session 347, Secure your app: mitigate risks to agentic features. Official transcript. Source for the Simon Willison Lethal Trifecta citation (private data, untrusted content, external communication), the indirect-prompt-injection definition (“instructions embedded in extra context provided to the model with the intent to redirect control flow”), the data-poisoning and action-poisoning distinction, the active-research-area framing, the deterministic-baseline doctrine and the spotlighting caveat, the Siri AI usage statement, the timer-label context-poisoning example, the
.onToolCallcontract (guaranteed trigger before execution, throwing blocks the tool), the.historyTransformbehavior (fires before each inference render, spotlighting delimiters, “[REDACTED]” placeholder, per-iteration scoping,@SessionPropertyfor stateful transformations), and the App Intents guardrails (schema-inherited risk metadata, the risk evaluation system combining static metadata and dynamic system state, contextual confirmations,authenticationPolicywith sensitivity-based schema defaults and stricter-only overrides enforced by a build error). ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩ -
Apple Security Engineering and Architecture et al., Expanding Private Cloud Compute, Apple Security Research blog, June 8, 2026. Source for the Google Cloud and NVIDIA expansion (“extending our industry-leading PCC privacy commitments to third-party data centers for the first time”), the unchanged core requirements (“stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency”), the implementation stack (NVIDIA Confidential Computing, Intel CPUs with TDX, Google’s Titan chip), the dual-vendor attestation (“software attestation is rooted in at least two separate roots of trust from independent vendors”), the append-only hardware ledger, the carried-over architectural patterns (namespaced per-request parsing, short-TTL software recycling, isolated attested-key VMs), Apple’s retained software control, public binary inspection with bounty-program research access, and the summer preview ramp. ↩↩↩↩↩↩↩↩↩
-
Apple, WWDC 2026 session 8009, Privacy and Security Group Lab. Paraphrased from a locally transcribed recording; Apple publishes no official captions for the labs, so the wording here is a paraphrase, not a quotation, and exact phrasing is unverified. Source for the deterministic-plus-probabilistic stack described across Siri AI, Safari, and Xcode; the Xcode MCP-server tool allowlists; the Siri AI hardened-daemon architecture with entitlement gating and mid-conversation permission re-prompts; the statement that PCC guarantees do not extend to third-party models reached through the language model protocol; and the panel’s pointer to the WebAuthn Signal API for passkey lifecycle. ↩↩↩↩↩↩
-
W3C, Web Authentication: An API for accessing Public Key Credentials Level 3. Source for the Signal API methods
signalUnknownCredential,signalAllAcceptedCredentials, andsignalCurrentUserDetails, which let relying parties signal credential changes so authenticators can remove or update stale passkeys. ↩ -
Apple, WWDC 2026 session 8011, Apple Intelligence Group Lab. Paraphrased from a locally transcribed recording of the WWDC 2026 Apple Intelligence Group Lab; Apple publishes no official captions for the labs, so the wording here is a paraphrase, not a quotation, and exact phrasing is unverified. Source for the distinction between a refusal error (the model’s own alignment training declining a request, surfaced under guided or structured generation) and a guardrail error (a separate moderation model inspecting input and output), and the opt-in setting that lets emotionally charged but legitimate input through; the name of that setting was not legible in the recording and is left unconfirmed. ↩↩
