Własna odpowiedź Apple na prompt injection

Apple wymienia teraz Simona Willisona z nazwiska. W sesji 347 z WWDC 2026 inżynier bezpieczeństwa Apple ujmuje ryzyko agentowe dokładnie tak, jak od roku robi to wątek bezpieczeństwa na tym blogu: „możemy odwołać się do Lethal Trifecta Simona Willisona, która opisuje, że użytkownik znajduje się w największym niebezpieczeństwie zawsze wtedy, gdy system agentowy ma: dostęp do prywatnych danych, ekspozycję na niezaufaną treść oraz zdolność do komunikacji zewnętrznej”.¹ Sesja, lab grupy Privacy and Security oraz ogłoszenie na security.apple.com w tym samym tygodniu składają się na najpełniejszy jak dotąd obraz tego, jak dostawca platformy z największą flotą urządzeń myśli o zabezpieczaniu agentów: deterministyczne bariery ochronne jako fundament, probabilistyczne jako wzmocnienie, a pod tym wszystkim atestacja infrastruktury.

Lethal trifecta, przytoczona w 5:55 w sesji 347.

TL;DR

• Sesja 347 to pierwsza własna doktryna Apple dotycząca prompt injection: najpierw zidentyfikuj niezaufany kontekst poprzez modelowanie zagrożeń, a następnie „skup się na deterministycznych środkach zaradczych jako fundamencie, ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i o nich wnioskować”, z probabilistycznymi środkami zaradczymi, takimi jak spotlighting, nałożonymi na wierzch.¹
• Bariery ochronne to dostarczane API, a nie porady. Modyfikatory zdarzeń cyklu życia w Foundation Models dają deterministyczne punkty zaczepienia: .onToolCall przechwytuje każde wywołanie narzędzia przed jego wykonaniem i blokuje je przez rzucenie wyjątku, a .historyTransform przepisuje transkrypt przed każdym przebiegiem inferencji w celu dodania ograniczników spotlightingu i redakcji PII.¹
• App Intents wymusza ryzyko automatycznie: intencje dziedziczą metadane ryzyka po schematach, które przyjmują, system oceny ryzyka wyzwala kontekstowe potwierdzenia, a authenticationPolicy można nadpisać wyłącznie w stronę bardziej restrykcyjną.¹
• W tym samym tygodniu Apple rozszerzyło Private Cloud Compute poza własne centra danych do Google Cloud na sprzęcie NVIDIA, zachowując te same pięć podstawowych wymagań i zakorzeniając atestację oprogramowania „w co najmniej dwóch odrębnych korzeniach zaufania od niezależnych dostawców”.²
• Lab grupy Privacy and Security dopełnił obraz fakturą szczegółów: Apple opisuje stosowanie tego deterministyczno-probabilistycznego stosu w Siri AI, Safari oraz Xcode, którego funkcje agentowe korzystają z list dozwolonych narzędzi, gdy Xcode działa jako serwer MCP.³

Doktryna: najpierw deterministyczne, potem probabilistyczne

Sesja 347 prowadzi przykładową aplikację przez model zagrożeń, który będzie znajomy każdemu, kto uruchamia agentów na produkcji. Pośrednie prompt injection jest zdefiniowane jako „instrukcje osadzone w dodatkowym kontekście dostarczonym modelowi z zamiarem przekierowania przepływu sterowania”, a sesja dzieli jego konsekwencje na dwa efekty, które warto rozróżniać: zatruwanie danych, „wpływanie przez atakującego na parametry wykonywanej akcji”, oraz zatruwanie akcji, „gdzie atakujący wpływa na to, jaką akcję wykonać”.¹ Sesja jest uczciwa co do stanu wiedzy w sposób rzadko spotykany w materiałach dostawców: „rozwiązanie pośredniego prompt injection jest aktywnym obszarem badań, co oznacza, że naszym najlepszym podejściem w tej chwili jest zrozumienie, jak bardzo Twoja aplikacja jest narażona, i dążenie do ograniczenia tego ryzyka”.¹

Zasada kolejności to ta część, którą warto przytaczać podczas przeglądów projektowych. Deterministyczne środki zaradcze są pierwsze, „ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i o nich wnioskować”; probabilistyczne środki zaradcze warto dodać, ponieważ „różne modele mogłyby skuteczniej egzekwować te ograniczenia”, ale sesja natychmiast przyznaje, gdzie leży granica: spotlighting „jest probabilistycznym środkiem zaradczym, ponieważ prompt injection można skonstruować w sposób, który neguje spotlighting”.¹ Potwierdzenia użytkownika i wymagania odblokowania urządzenia lądują po deterministycznej stronie bilansu. Redakcja sprawia, że PII nigdy nie dociera do modelu, „a zatem nie może zostać wyeksfiltrowane”.¹ Apple deklaruje, że stosowało te środki zaradcze przy projektowaniu Siri AI.¹

Jedna subtelność z modelu zagrożeń zasługuje na uwagę, ponieważ wychwytuje przypadek, który umyka większości list dozwolonych. Akcja utworzenia minutnika wygląda niewinnie, dopóki nie zauważy się jej opcjonalnego parametru etykiety: prompt injection może ustawić etykietę na tekst kontrolowany przez atakującego, a „kolejne zapytanie o listę minutników może następnie wciągnąć te kontrolowane przez atakującego dane do tego kontekstu, zatruwając tym samym również nowy kontekst”.¹ Narzędzia wolne od efektów ubocznych, ale z zapisywalnymi polami tekstowymi, są mechanizmami trwałości dla wstrzyknięć.

API barier ochronnych Foundation Models

Implementacyjna połowa sesji odwzorowuje doktrynę na dwie dostarczane powierzchnie. W ramach Foundation Models modyfikatory zdarzeń cyklu życia to „wywołania zwrotne, które deterministycznie wyzwalają się w określonych punktach cyklu życia wykonania sesji”.¹

.onToolCall to punkt kontrolny akcji. „Gwarantuje wyzwolenie, gdy LLM wygeneruje wywołanie narzędzia, zanim wykonawca uruchomi narzędzie”, a najużyteczniejszą częścią jest kontrakt: „jeśli to wywołanie zwrotne rzuci błąd, narzędzie nigdy nie zostaje wykonane”.¹ Przykład z sesji bramkuje narzędzie o skutkach finansowych za potwierdzeniem użytkownika w jednym miejscu i uzyskuje pokrycie dla każdego wywołania narzędzia w sesji. Kształt jest dokładnie taki, o jaki ten blog argumentował w zatwierdzenia (approval prompts) to nie autoryzacja: kontrola znajduje się w ścieżce wykonania, a nie w instrukcjach modelu.

.historyTransform to punkt kontrolny wejścia. „Uruchamia się, zanim transkrypt zostanie wyrenderowany dla modelu do inferencji”, zarówno przy nowych żądaniach użytkownika, jak i przy każdej iteracji pętli, a sesja używa go do dwóch środków zaradczych na poziomie promptu: owijania wyjść narzędzi z niezaufanych źródeł w ograniczniki spotlightingu oraz zastępowania danych wrażliwych symbolem zastępczym redakcji.¹ Szczegół, który ma znaczenie dla wdrażających: przekształcone wpisy są ograniczone wyłącznie do bieżącego przebiegu inferencji, więc przekształcenia są ponownie stosowane przy każdej iteracji, przy czym adnotacja @SessionProperty stanowi furtkę dla kosztownych przekształceń ze stanem.¹

App Intents: metadane ryzyka, które dziedziczysz, a nie piszesz

Strona zwrócona ku Siri otrzymuje swoje bariery ochronne z systemu schematów. Gdy intencja przyjmuje schemat intencji, metadane ryzyka są „przypisywane automatycznie” na podstawie efektów ubocznych schematu: akcje destrukcyjne, eksfiltrujące oraz aktualizujące udostępnioną treść są bardziej ryzykowne, a „system jest bardziej skłonny wyzwalać potwierdzenia dla narzędzi wysokiego ryzyka”.¹ System oceny ryzyka łączy te statyczne metadane z dynamicznym stanem systemu, aby kontekstowo zdecydować, czy wstawić potwierdzenie przed wykonaniem intencji; odmowa blokuje intencję w całości.¹

Ekspozycja na ekranie blokady jest traktowana tak samo. Ponieważ Siri działa na zablokowanym urządzeniu, atakujący będący w fizycznym posiadaniu może dotrzeć do Twoich intencji, dlatego intencje niestandardowe ustawiają authenticationPolicy, schematy niosą domyślne wartości oparte na wrażliwości, a ograniczenie jest dokładnie właściwe: „można nadpisać politykę schematu, ale tylko po to, by uczynić ją bardziej restrykcyjną”, przy czym błąd kompilacji wskazuje minimalną dozwoloną politykę, jeśli spróbujesz ją osłabić.¹ Kompilator odmawiający pozwolenia na niedostateczne zabezpieczenie akcji to najbardziej w stylu Apple środek zaradczy na prompt injection, jaki można sobie wyobrazić.

Warstwa infrastruktury: PCC opuszcza centra danych Apple

Trzy dni przed emisją sesji Apple opublikowało „Expanding Private Cloud Compute” na swoim blogu o bezpieczeństwie: nowe obciążenia Apple Intelligence działają teraz w Google Cloud z procesorami graficznymi NVIDIA, „rozszerzając nasze wiodące w branży zobowiązania prywatności PCC na zewnętrzne centra danych po raz pierwszy”.² Pięć podstawowych wymagań przenosi się bez zmian: „bezstanowe obliczenia, egzekwowalne gwarancje, brak uprzywilejowanego dostępu w czasie wykonywania, nieukierunkowywalność oraz weryfikowalna transparentność”.² Zmienia się implementacja: NVIDIA Confidential Computing, procesory Intel z TDX oraz układ Titan firmy Google.²

Dwie decyzje projektowe wyróżniają się na tle status quo poufnych obliczeń. W przypadku komponentów, które mogłyby wyeksfiltrować dane użytkownika w razie kompromitacji, „atestacja oprogramowania jest zakorzeniona w co najmniej dwóch odrębnych korzeniach zaufania od niezależnych dostawców”, a Apple utrzymuje „kryptograficznie weryfikowalny, tylko-dopisywalny rejestr całego sprzętu Google Cloud wchodzącego w skład floty PCC” jako zabezpieczenie przed atakami na łańcuch dostaw.² Wzorce architektoniczne z PCC na układach Apple również się przenoszą: parsowanie sieci dla każdego żądania w dedykowanym procesie z osobną przestrzenią nazw, współdzielone oprogramowanie inferencyjne poddawane recyklingowi przy krótkim czasie życia, atestowane klucze przechowywane w osobnej poufnej maszynie wirtualnej odizolowanej od wejść zewnętrznych.² Kontrola pozostaje scentralizowana: „Apple zachowuje pełną kontrolę nad oprogramowaniem PCC; urządzenia Apple będą ufać wyłącznie oprogramowaniu PCC, które jest kryptograficznie zatwierdzone przez Apple”, przy czym wszystkie pliki binarne są publikowane do publicznej inspekcji, a działające węzły w trybie badawczym są dostępne za pośrednictwem Apple Security Bounty Program.² Wdrożenie jest etapowe, „stopniowo zmierzające do pełnego zestawu zabezpieczeń przez letni okres podglądu”.²

Co dodał lab

Lab grupy Privacy and Security odbył się w tym samym tygodniu, a Apple nie publikuje napisów do labów, więc to, co następuje, jest parafrazą lokalnie transkrybowanego nagrania, a nie cytatem.³ Panel powiązał doktrynę sesji z dostarczanymi powierzchniami: deterministyczno-probabilistyczny stos działa w Siri AI, Safari oraz funkcjach agentowych Xcode, a gdy Xcode działa jako serwer MCP, ogranicza agentów listami dozwolonych narzędzi.³ Osobny lab Apple Intelligence wytyczył użyteczną granicę między dwoma trybami awarii, które deweloperzy mylą. Panelista odróżnił błąd odmowy (refusal error), gdzie własny trening alignmentu modelu odmawia żądania, a awaria ujawnia się przy generacji sterowanej lub strukturalnej, od błędu bariery ochronnej (guardrail error), gdzie osobny model moderacji bada wejście i wyjście niezależnie od głównego modelu.⁵ Ten sam panelista wspomniał o ustawieniu opt-in, które przepuszcza emocjonalnie nacechowane, ale uprawnione wejście, zamiast uruchamiać barierę ochronną; dokładna nazwa tego ustawienia nie była czytelna w nagraniu i pozostaje niepotwierdzona.⁵ Co do architektury Siri AI, panelista opisał dedykowany, utwardzony, izolowany w piaskownicy demon z bramkowaniem uprawnień (entitlement) jako jedyną ścieżkę zbierania i formatowania danych użytkownika, zanim opuszczą one urządzenie w drodze do Private Cloud Compute, przy czym żądania wieloturowe ponawiają prośbę o uprawnienie do nowo udostępnionych danych w trakcie rozmowy.³

Dwa kolejne wątki labu warto odnotować do dalszej obserwacji. Panel stwierdził, że gwarancje prywatności Foundation Models nie rozciągają się na modele zewnętrzne osiągane przez protokół modelu językowego frameworka; to deweloper odpowiada za zapoznanie się z warunkami tych dostawców i odpowiednie ich ujawnienie.³ A co do kwestii cyklu życia kluczy dostępu (passkey), która od dawna nęka adopcję WebAuthn, panelista wskazał Signal API jako rozwiązaną odpowiedź: standardy webowe definiują teraz signalUnknownCredential, signalAllAcceptedCredentials oraz signalCurrentUserDetails do utrzymywania poświadczeń w synchronizacji między stronami polegającymi (relying parties) a uwierzytelniaczami, a to API jest realne i dostarczane w W3C WebAuthn Level 3.⁴

Co z tego wynieść

Użyteczne nie jest to, że Apple rozwiązało prompt injection; sesja wprost mówi, że nikt tego nie dokonał. Użyteczne jest obserwowanie, jak dostawca platformy zobowiązuje się do kolejności: najpierw deterministyczne kontrole w ścieżce wykonania, potem podpowiedzi na poziomie modelu, a pod spodem atestacja infrastruktury. Dla budujących agentów poza platformami Apple każdy element ma swój odpowiednik: .onToolCall to Twój przechwytywacz wywołań narzędzi, .historyTransform to Twój sanityzator kontekstu, dziedziczone ze schematu metadane ryzyka to Twoja tabela klasyfikacji narzędzi, a nadpisania authenticationPolicy wyłącznie w stronę bardziej restrykcyjną to Twoja podłoga polityki. Nazwy frameworków są Apple; architektura jest przenośna i odpowiada obronie w głąb, którą ten blog rozłożył w agent z dwoma niezaufanymi wejściami oraz obrona w czasie wykonywania dla agentów wzbogaconych o narzędzia.

FAQ

Jaka jest zalecana przez Apple obrona przed prompt injection?

Najpierw zamodeluj zagrożenia (zidentyfikuj źródła niezaufanego kontekstu i efekty uboczne akcji), a następnie zastosuj „deterministyczne środki zaradcze jako fundament, ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i o nich wnioskować”, z probabilistycznymi środkami zaradczymi, takimi jak spotlighting, dodanymi na wierzch.¹ Konkretnie: potwierdzenia użytkownika i wymagania odblokowania urządzenia przy ryzykownych akcjach, redakcja PII i ograniczniki spotlightingu przy niezaufanym kontekście.

Jakie API implementują te bariery ochronne?

W Foundation Models modyfikatory zdarzeń cyklu życia: .onToolCall (deterministycznie przechwytuje każde wywołanie narzędzia przed wykonaniem; rzucenie wyjątku blokuje narzędzie) oraz .historyTransform (przepisuje końcówkę transkryptu przed każdym przebiegiem inferencji), z @SessionProperty dla trwałych przekształceń.¹ W App Intents dziedziczone ze schematu metadane ryzyka napędzają kontekstowe potwierdzenia, a authenticationPolicy kontroluje dostęp z ekranu blokady przy nadpisaniach wyłącznie w stronę bardziej restrykcyjną.¹

Czy Apple naprawdę przeniosło Private Cloud Compute do chmury Google?

Tak, dla nowych obciążeń Apple Intelligence. PCC rozciąga się teraz na Google Cloud na procesorach graficznych NVIDIA z Intel TDX i układem Titan firmy Google, zachowując te same pięć wymagań PCC, dwudostawcze korzenie atestacji, tylko-dopisywalny rejestr sprzętu oraz wyłącznie Apple zatwierdzające oprogramowanie, narastając przez letni okres podglądu.² Gwarancje PCC nadal nie rozciągają się na modele zewnętrzne, takie jak Gemini czy Claude, osiągane przez protokół modelu językowego.³

Czy cokolwiek z tego dotyczy spoza platform Apple?

Architektura tak. Przechwytywacze w ścieżce wykonania, sanityzatory kontekstu, klasyfikacja ryzyka narzędzi i podłogi polityki to przenośne wzorce; wersje Apple są godne uwagi, ponieważ dostarczane są jako API frameworka z deterministycznymi kontraktami, a nie jako wskazówki.

Stos środków zaradczych Apple ląduje na terytorium, które ten blog mapuje od roku: ujęcie trifecty w agent z dwoma niezaufanymi wejściami, argument o ścieżce wykonania w zatwierdzenia (approval prompts) to nie autoryzacja oraz historia infrastruktury w Foundation Models i Private Cloud Compute. Pełny hub serii to Apple Ecosystem Series.

Źródła