Pierwsza autorska odpowiedź Apple na prompt injection

Apple wymienia teraz Simona Willisona z nazwiska. W sesji 347 na 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 jest najbardziej narażony, gdy system agentowy ma: dostęp do prywatnych danych, ekspozycję na niezaufane treści oraz możliwość komunikacji na zewnątrz”.¹ Sesja, lab grupy Privacy and Security oraz ogłoszenie na security.apple.com z tego samego tygodnia 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 zabezpieczenia jako podstawa, probabilistyczne jako wzmocnienie, a pod tym wszystkim atestacja infrastruktury.

Lethal trifecta, przywołana w 5:55 w sesji 347.

TL;DR

• Sesja 347 to autorska doktryna Apple dotycząca prompt injection: najpierw zidentyfikować niezaufany kontekst poprzez modelowanie zagrożeń, a następnie „skupić się na deterministycznych środkach zaradczych jako podstawie, ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i analizować”, z probabilistycznymi środkami zaradczymi, takimi jak spotlighting, nałożonymi na wierzch.¹
• Te zabezpieczenia 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 zastosowania ograniczników spotlighting i redakcji PII.¹
• App Intents egzekwuje ryzyko automatycznie: intencje dziedziczą metadane ryzyka ze schematów, które przyjmują, system oceny ryzyka wyzwala kontekstowe potwierdzenia, a authenticationPolicy można nadpisać wyłącznie w kierunku bardziej restrykcyjnym.¹
• W tym samym tygodniu Apple rozszerzyło Private Cloud Compute poza własne centra danych na Google Cloud na sprzęcie NVIDIA, zachowując te same pięć podstawowych wymagań i zakorzeniając atestację oprogramowania „w co najmniej dwóch oddzielnych korzeniach zaufania pochodzących od niezależnych dostawców”.²
• Lab grupy Privacy and Security uzupełnił obraz fakturą: Apple opisuje wykorzystanie tego deterministyczno-probabilistycznego stosu w Siri AI, Safari i 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 wyda się znajomy każdemu, kto uruchamia agentów na produkcji. Pośrednie prompt injection jest definiowane jako „instrukcje osadzone w dodatkowym kontekście dostarczonym modelowi z zamiarem przekierowania przepływu sterowania”, a sesja dzieli jego konsekwencje na dwa efekty warte rozróżnienia: zatruwanie danych, „wpływ atakującego na parametry wykonywanej akcji”, oraz zatruwanie akcji, „gdy atakujący wpływa na to, jaką akcję wykonać”.¹ Sesja jest uczciwa co do stanu wiedzy w sposób, w jaki materiały dostawców rzadko bywają: „rozwiązanie pośredniego prompt injection to aktywny obszar badań, co oznacza, że naszym najlepszym obecnie podejściem jest zrozumienie, jak bardzo aplikacja jest zagrożona, i dążenie do ograniczenia tego ryzyka”.¹

Zasada porządkowania to część warta przytaczania na przeglądach projektowych. Deterministyczne środki zaradcze są pierwsze, „ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i analizować”; probabilistyczne środki zaradcze warto dodać, ponieważ „różne modele mogłyby skuteczniej egzekwować te ograniczenia”, ale sesja od razu przyznaje ograniczenie: spotlighting „jest probabilistycznym środkiem zaradczym, ponieważ prompt injection mógłby zostać skonstruowany w sposób, który neguje spotlighting”.¹ Potwierdzenia użytkownika i wymogi odblokowania urządzenia lądują po deterministycznej stronie rachunku. Redakcja sprawia, że PII nigdy nie dociera do modelu, „a zatem nie może zostać wyeksfiltrowane”.¹ Apple deklaruje, że zastosowało te środki zaradcze przy projektowaniu Siri AI.¹

Jedna subtelność z modelu zagrożeń zasługuje na uwagę, ponieważ wychwytuje przypadek pomijany przez większość 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 w ten sposób również nowy kontekst”.¹ Narzędzia wolne od efektów ubocznych, ale z zapisywalnymi polami tekstowymi, są mechanizmami trwałości dla wstrzyknięć.

API zabezpieczeń w Foundation Models

Implementacyjna połowa sesji odwzorowuje doktrynę na dwie dostarczane powierzchnie. We frameworku 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. „Jest gwarantowane, że wyzwoli się, gdy LLM wygeneruje wywołanie narzędzia, zanim egzekutor uruchomi narzędzie”, a użyteczną częścią jest kontrakt: „jeśli ten callback rzuci błąd, to narzędzie nigdy nie zostanie 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 ten sam, o który ten blog argumentował w zatwierdzenia nie są autoryzacją: kontrola znajduje się w ścieżce wykonania, a nie w instrukcjach modelu.

.historyTransform to punkt kontrolny wejścia. „Uruchamia się przed wyrenderowaniem transkryptu do modelu na potrzeby inferencji”, zarówno przy nowych żądaniach użytkownika, jak i przy każdej iteracji pętli, a sesja wykorzystuje go do dwóch zabezpieczeń promptu: opakowywania wyjść narzędzi z niezaufanych źródeł w ograniczniki spotlighting oraz zastępowania danych wrażliwych symbolem zastępczym redakcji.¹ Szczegół istotny dla wdrażających: przekształcone wpisy są ograniczone wyłącznie do bieżącego przebiegu inferencji, więc przekształcenia są stosowane ponownie przy każdej iteracji, a adnotacja @SessionProperty stanowi furtkę dla kosztownych przekształceń ze stanem.¹

App Intents: metadane ryzyka, które się dziedziczy, a nie zapisuje

Strona zwrócona ku Siri czerpie swoje zabezpieczenia z systemu schematów. Gdy intencja przyjmuje schemat intencji, metadane ryzyka „są automatycznie przypisywane” na podstawie efektów ubocznych schematu: akcje destrukcyjne, eksfiltrujące oraz aktualizujące treści współdzielone są bardziej ryzykowne, a „system z większym prawdopodobieństwem wyzwoli 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 traktowana jest tak samo. Ponieważ Siri działa na zablokowanym urządzeniu, atakujący w fizycznym posiadaniu może sięgnąć po Twoje intencje, dlatego niestandardowe intencje 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ą”, z błędem kompilacji nazywającym minimalną dozwoloną politykę, jeśli ktoś spróbuje ją osłabić.¹ Kompilator odmawiający pozwolenia na niedostateczne zabezpieczenie akcji to najbardziej apple’owski ś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 bezpieczeństwa: nowe obciążenia Apple Intelligence działają teraz na Google Cloud z procesorami GPU NVIDIA, „rozszerzając nasze wiodące w branży zobowiązania PCC dotyczące prywatności na zewnętrzne centra danych po raz pierwszy”.² Pięć podstawowych wymagań przechodzi bez zmian: „obliczenia bezstanowe, egzekwowalne gwarancje, brak uprzywilejowanego dostępu w czasie wykonania, brak możliwości celowania oraz weryfikowalna transparentność”.² Tym, co się zmienia, jest 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ń. Dla komponentów, które mogłyby wyeksfiltrować dane użytkownika w razie naruszenia, „atestacja oprogramowania jest zakorzeniona w co najmniej dwóch oddzielnych korzeniach zaufania pochodzących od niezależnych dostawców”, a Apple utrzymuje „kryptograficznie weryfikowalny rejestr wyłącznie do dopisywania, obejmujący cały sprzęt Google Cloud będący częścią floty PCC” przeciwko atakom na łańcuch dostaw.² Wzorce architektoniczne z PCC na układach Apple również przechodzą: parsowanie sieci dla każdego żądania w dedykowanym procesie z osobną przestrzenią nazw, współdzielone oprogramowanie inferencyjne odświeżane 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 binaria są publikowane do publicznej inspekcji, a działające węzły w trybie badawczym są osiągalne za pośrednictwem Apple Security Bounty Program.² Wdrożenie jest etapowe, „stopniowo zmierzając ku pełnemu zestawowi zabezpieczeń w trakcie letniego okresu zapowiedzi”.²

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 sparafrazowane z lokalnie spisanego nagrania, a nie cytowane.³ Panel połączył doktrynę z 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.³ Co do architektury Siri AI, panelista opisał dedykowany, utwardzony, izolowany demon z bramkowaniem uprawnień jako jedyną ścieżkę gromadzenia i formatowania danych użytkownika, zanim opuszczą one urządzenie w drodze do Private Cloud Compute, przy czym żądania wieloturowe ponownie proszą o pozwolenie na nowo udostępnione dane w trakcie rozmowy.³

Dwa kolejne wątki z 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 poinformowanie.³ A w kwestii cyklu życia kluczy 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 w celu utrzymywania synchronizacji poświadczeń między stronami polegającymi a uwierzytelniaczami, a 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 mówi wprost, że nikt tego nie dokonał. Użyteczne jest obserwowanie, jak dostawca platformy zobowiązuje się do określonego porządku: najpierw deterministyczne kontrole w ścieżce wykonania, na drugim miejscu podpowiedzi na poziomie modelu, a pod spodem atestacja infrastruktury. Dla twórców agentów poza platformami Apple każdy element ma swój odpowiednik: .onToolCall to Twój interceptor 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 kierunku bardziej restrykcyjnym to Twoja podłoga polityki. Nazwy frameworków należą do Apple; architektura jest przenośna i odpowiada obronie w głąb, którą ten blog wyłożył w agent z dwoma niezaufanymi wejściami oraz obrona w czasie wykonania dla agentów wzbogaconych o narzędzia.

FAQ

Jaka jest rekomendowana przez Apple obrona przed prompt injection?

Najpierw modelowanie zagrożeń (zidentyfikować niezaufane źródła kontekstu i efekty uboczne akcji), a następnie zastosować „deterministyczne środki zaradcze jako podstawę, ponieważ ich gwarancje bezpieczeństwa łatwiej audytować i analizować”, z probabilistycznymi środkami zaradczymi, takimi jak spotlighting, dodanymi na wierzch.¹ Konkretnie: potwierdzenia użytkownika i wymogi odblokowania urządzenia przy ryzykownych akcjach, redakcja PII i ograniczniki spotlighting na niezaufanym kontekście.

Jakie API implementują te zabezpieczenia?

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 koniec transkryptu przed każdym przebiegiem inferencji), z @SessionProperty dla trwałych przekształceń.¹ W App Intents dziedziczone ze schematu metadane ryzyka sterują kontekstowymi potwierdzeniami, a authenticationPolicy kontroluje dostęp z ekranu blokady z nadpisaniami wyłącznie w kierunku bardziej restrykcyjnym.¹

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 GPU NVIDIA z Intel TDX oraz układem Titan firmy Google, zachowując te same pięć wymagań PCC, dwudostawcze korzenie atestacji, rejestr sprzętu wyłącznie do dopisywania oraz zatwierdzanie oprogramowania wyłącznie przez Apple, wdrażane w trakcie letniego okresu zapowiedzi.² 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 ma zastosowanie poza platformami Apple?

Architektura ma. Interceptory w ścieżce wykonania, sanityzatory kontekstu, klasyfikacja ryzyka narzędzi oraz podłogi polityki to wzorce przenośne; wersje Apple są godne uwagi, ponieważ dostarczane są jako API frameworków 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 trifecta w agent z dwoma niezaufanymi wejściami, argument o ścieżce wykonania w zatwierdzenia nie są autoryzacją oraz historia infrastruktury w Foundation Models i Private Cloud Compute. Pełny hub serii to Seria Apple Ecosystem.

Bibliografia