Apples Antwort aus erster Hand auf Prompt Injection

Apple nennt Simon Willison nun beim Namen. In WWDC-2026-Session 347 rahmt ein Sicherheitsingenieur von Apple das agentische Risiko genau so ein, wie es der Sicherheits-Thread dieses Blogs seit einem Jahr tut: „Wir können uns an Simon Willisons Lethal Trifecta orientieren, die beschreibt, dass ein Benutzer immer dann am stärksten gefährdet ist, wenn ein agentisches System Folgendes besitzt: Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit, extern zu kommunizieren.”¹ Die Session, das Lab der Privacy-and-Security-Gruppe und eine Ankündigung auf security.apple.com in derselben Woche ergeben zusammen das bislang vollständigste Bild davon, wie der Plattformanbieter mit der größten Geräteflotte über die Absicherung von Agenten denkt: deterministische Guardrails als Grundlage, probabilistische als Verstärkung und darunter eine Infrastruktur-Attestierung.

Die lethal trifecta, zitiert bei 5:55 in Session 347.

Kurzfassung

• Session 347 ist Apples Prompt-Injection-Doktrin aus erster Hand: Identifizieren Sie nicht vertrauenswürdigen Kontext durch Threat Modeling und „konzentrieren Sie sich dann auf deterministische Gegenmaßnahmen als Grundlage, weil deren Sicherheitsgarantien einfacher zu prüfen und nachzuvollziehen sind”, wobei probabilistische Gegenmaßnahmen wie Spotlighting obenauf gelegt werden.¹
• Die Guardrails sind ausgelieferte APIs, keine Ratschläge. Lebenszyklus-Event-Modifikatoren der Foundation Models bieten deterministische Hooks: .onToolCall fängt jeden Tool-Aufruf vor der Ausführung ab und blockiert ihn durch das Werfen eines Fehlers, und .historyTransform schreibt das Transkript vor jedem Inferenzdurchlauf um, für Spotlighting-Trennzeichen und PII-Schwärzung.¹
• App Intents erzwingt das Risiko automatisch: Intents erben Risiko-Metadaten von den Schemas, die sie übernehmen, ein Risikobewertungssystem löst kontextbezogene Bestätigungen aus, und authenticationPolicy lässt sich nur in Richtung strenger überschreiben.¹
• In derselben Woche erweiterte Apple Private Cloud Compute über die eigenen Rechenzentren hinaus auf Google Cloud mit NVIDIA-Hardware, behielt dieselben fünf Kernanforderungen bei und verankerte die Software-Attestierung „in mindestens zwei separaten Vertrauensankern unabhängiger Anbieter”.²
• Das Lab der Privacy-and-Security-Gruppe lieferte die Feinheiten nach: Apple beschreibt den Einsatz dieses Stacks aus deterministischen und probabilistischen Maßnahmen über Siri AI, Safari und Xcode hinweg, dessen agentische Funktionen Tool-Allowlists nutzen, wenn Xcode als MCP-Server agiert.³

Die Doktrin: deterministisch zuerst, probabilistisch danach

Session 347 führt eine Beispiel-App durch ein Threat Model, das jedem vertraut vorkommen wird, der Agenten in Produktion betreibt. Indirekte Prompt Injection wird definiert als „Anweisungen, die in zusätzlichen, dem Modell bereitgestellten Kontext eingebettet sind, mit der Absicht, den Kontrollfluss umzuleiten”, und die Session teilt deren Folgen in zwei Effekte auf, die es auseinanderzuhalten gilt: Data Poisoning, „bei dem ein Angreifer die Parameter einer ausgeführten Aktion beeinflusst”, und Action Poisoning, „bei dem der Angreifer beeinflusst, welche Aktion ausgeführt wird”.¹ Die Session ist auf eine Weise ehrlich über den Stand der Technik, wie es Anbietermaterial selten ist: „Das Lösen indirekter Prompt Injection ist ein aktives Forschungsfeld, das heißt, unser bester Ansatz besteht derzeit darin, zu verstehen, wie stark Ihre App gefährdet ist, und darauf abzuzielen, dieses Risiko zu mindern.”¹

Das Ordnungsprinzip ist der Teil, den man in Design-Reviews zitieren sollte. Deterministische Gegenmaßnahmen kommen zuerst, „weil deren Sicherheitsgarantien einfacher zu prüfen und nachzuvollziehen sind”; probabilistische Gegenmaßnahmen lohnen sich, weil „verschiedene Modelle diese Einschränkungen wirksamer durchsetzen könnten”, doch die Session räumt sogleich die Grenze ein: Spotlighting „ist eine probabilistische Gegenmaßnahme, weil die Prompt Injection so konstruiert werden könnte, dass sie das Spotlighting aushebelt”.¹ Benutzerbestätigungen und das Erfordernis, das Gerät zu entsperren, landen auf der deterministischen Seite der Bilanz. Schwärzung verhindert, dass PII das Modell überhaupt erreicht, „und kann daher nicht exfiltriert werden”.¹ Apple gibt an, diese Gegenmaßnahmen beim Design von Siri AI eingesetzt zu haben.¹

Eine Feinheit aus dem Threat Model verdient Aufmerksamkeit, weil sie einen Fall erfasst, den die meisten Allowlists übersehen. Eine Aktion zum Erstellen eines Timers wirkt harmlos, bis man ihren optionalen Label-Parameter bemerkt: Eine Prompt Injection kann das Label auf von einem Angreifer kontrollierten Text setzen, und „eine anschließende Abfrage zum Auflisten der Timer kann dann diese vom Angreifer kontrollierten Daten in diesen Kontext ziehen und so auch den neuen Kontext vergiften”.¹ Nebenwirkungsfreie Tools mit beschreibbaren String-Feldern sind Persistenzmechanismen für Injections.

Die Foundation-Models-Guardrail-APIs

Die Implementierungshälfte der Session überträgt die Doktrin auf zwei ausgelieferte Oberflächen. Im Foundation-Models-Framework sind Lebenszyklus-Event-Modifikatoren „Callbacks, die an bestimmten Lebenszykluspunkten einer Session-Ausführung deterministisch ausgelöst werden”.¹

.onToolCall ist der Aktions-Checkpoint. Er „wird garantiert ausgelöst, wenn das LLM einen Tool-Aufruf ausgibt, bevor der Executor das Tool ausführt”, und der nützliche Teil ist der Vertrag: „Wenn dieser Callback einen Fehler wirft, wird das Tool niemals ausgeführt.”¹ Das Beispiel der Session schützt ein Tool mit finanzieller Auswirkung an einer Stelle durch eine Benutzerbestätigung und erhält damit Abdeckung für jeden Tool-Aufruf in der Session. Die Form ist dieselbe, für die dieser Blog in Bestätigungsabfragen sind keine Autorisierung argumentiert hat: Die Prüfung lebt im Ausführungspfad, nicht in den Anweisungen des Modells.

.historyTransform ist der Eingabe-Checkpoint. Er „feuert, bevor das Transkript dem Modell zur Inferenz gerendert wird”, sowohl bei neuen Benutzeranfragen als auch bei jeder Schleifeniteration, und die Session nutzt ihn für die beiden Prompt-Gegenmaßnahmen: das Einhüllen von Tool-Ausgaben aus nicht vertrauenswürdigen Quellen in Spotlighting-Trennzeichen und das Ersetzen sensibler Daten durch einen Schwärzungsplatzhalter.¹ Ein Detail, das für Implementierer wichtig ist: Transformierte Einträge sind nur auf den aktuellen Inferenzdurchlauf beschränkt, sodass Transformationen bei jeder Iteration erneut angewendet werden, wobei die Annotation @SessionProperty als Notausgang für teure zustandsbehaftete Transformationen dient.¹

App Intents: Risiko-Metadaten, die Sie erben, nicht schreiben

Die Siri-zugewandte Seite bezieht ihre Guardrails aus dem Schema-System. Wenn ein Intent ein Intent-Schema übernimmt, werden Risiko-Metadaten auf Basis der Nebenwirkungen des Schemas „automatisch zugewiesen”: destruktive, exfiltrierende und Aktionen, die geteilte Inhalte aktualisieren, sind riskanter, und „das System löst mit höherer Wahrscheinlichkeit Bestätigungen für risikoreiche Tools aus”.¹ Ein Risikobewertungssystem kombiniert diese statischen Metadaten mit dem dynamischen Systemzustand, um kontextbezogen zu entscheiden, ob vor der Ausführung des Intents eine Bestätigung zwischengeschaltet wird; eine Ablehnung blockiert den Intent vollständig.¹

Die Exposition auf dem Sperrbildschirm erhält dieselbe Behandlung. Weil Siri auf einem gesperrten Gerät funktioniert, kann ein Angreifer in physischem Besitz Ihre Intents erreichen, daher setzen benutzerdefinierte Intents eine authenticationPolicy, Schemas tragen auf Sensibilität basierende Standardwerte, und die Einschränkung trifft es genau: „Sie können die Schema-Richtlinie überschreiben, aber nur, um sie strenger zu machen”, wobei ein Build-Fehler die minimal zulässige Richtlinie benennt, wenn Sie versuchen, sie abzuschwächen.¹ Dass der Compiler sich weigert, Sie eine Aktion unterschützen zu lassen, ist die denkbar Apple-förmigste Prompt-Injection-Gegenmaßnahme.

Die Infrastrukturebene: PCC verlässt Apples Rechenzentren

Drei Tage vor der Ausstrahlung der Session veröffentlichte Apple „Expanding Private Cloud Compute” in seinem Sicherheitsblog: Neue Apple-Intelligence-Workloads laufen nun auf Google Cloud mit NVIDIA-GPUs und „erweitern damit erstmals unsere branchenführenden PCC-Datenschutzverpflichtungen auf Rechenzentren von Drittanbietern”.² Die fünf Kernanforderungen werden unverändert übernommen: „zustandslose Berechnung, durchsetzbare Garantien, kein privilegierter Laufzeitzugriff, Nicht-Zielbarkeit und überprüfbare Transparenz”.² Was sich ändert, ist die Implementierung: NVIDIA Confidential Computing, Intel-CPUs mit TDX und Googles Titan-Chip.²

Zwei Designentscheidungen stechen gegenüber dem Status quo des Confidential Computing hervor. Für Komponenten, die im Kompromittierungsfall Benutzerdaten exfiltrieren könnten, „ist die Software-Attestierung in mindestens zwei separaten Vertrauensankern unabhängiger Anbieter verankert”, und Apple führt gegen Supply-Chain-Angriffe „ein kryptografisch überprüfbares, nur anhängbares Ledger der gesamten Google-Cloud-Hardware, die Teil der PCC-Flotte ist”.² Auch die Architekturmuster von PCC auf Apple Silicon werden übernommen: Netzwerk-Parsing pro Anfrage in einem dedizierten, namensraumisolierten Prozess, gemeinsam genutzte Inferenz-Software, die nach einer kurzen Time-to-live recycelt wird, attestierte Schlüssel, die in einer separaten Confidential VM isoliert von externen Eingaben gehalten werden.² Die Kontrolle bleibt zentralisiert: „Apple behält die vollständige Kontrolle über die PCC-Software; Apple-Geräte vertrauen nur PCC-Software, die von Apple kryptografisch genehmigt wurde”, wobei alle Binärdateien zur öffentlichen Prüfung veröffentlicht werden und Live-Knoten im Forschungsmodus über das Apple Security Bounty Program erreichbar sind.² Die Einführung erfolgt gestaffelt und „steigert sich schrittweise zum vollständigen Satz an Schutzmaßnahmen über den Sommer-Vorschauzeitraum”.²

Was das Lab ergänzte

Das Lab der Privacy-and-Security-Gruppe fand in derselben Woche statt, und Apple veröffentlicht keine Untertitel für Labs, daher ist das Folgende aus einer lokal transkribierten Aufzeichnung paraphrasiert, nicht zitiert.³ Das Panel verband die Doktrin der Session mit ausgelieferten Oberflächen: Der Stack aus deterministischen und probabilistischen Maßnahmen läuft über Siri AI, Safari und die agentischen Funktionen von Xcode, und wenn Xcode als MCP-Server agiert, schränkt es Agenten mit Allowlists erlaubter Tools ein.³ Zur Siri-AI-Architektur beschrieb ein Panelist einen dedizierten, gehärteten Sandbox-Daemon mit Entitlement-Gating als einzigen Pfad zum Sammeln und Formatieren von Benutzerdaten, bevor diese zu Private Cloud Compute aufbrechen, wobei mehrstufige Anfragen die Berechtigung für neu zugegriffene Daten mitten im Gespräch erneut abfragen.³

Zwei weitere Lab-Stränge sind als Nachfassthemen festzuhalten. Das Panel erklärte, die Datenschutzgarantien der Foundation Models erstrecken sich nicht auf Drittanbietermodelle, die über das Sprachmodell-Protokoll des Frameworks erreicht werden; dem Entwickler obliegt es, die Bedingungen dieser Anbieter zu lesen und entsprechend offenzulegen.³ Und zur Frage des Passkey-Lebenszyklus, die die WebAuthn-Einführung geplagt hat, verwies ein Panelist auf die Signal-API als gelöste Antwort: Web-Standards definieren nun signalUnknownCredential, signalAllAcceptedCredentials und signalCurrentUserDetails, um Anmeldedaten zwischen vertrauenden Parteien und Authentifikatoren synchron zu halten, und die API ist real und wird in W3C WebAuthn Level 3 ausgeliefert.⁴

Was man daraus mitnehmen sollte

Der nützliche Punkt ist nicht, dass Apple Prompt Injection gelöst hat; die Session sagt klar, dass das niemand getan hat. Der nützliche Punkt ist, einem Plattformanbieter dabei zuzusehen, wie er sich auf eine Reihenfolge festlegt: zuerst deterministische Kontrollen im Ausführungspfad, danach Hinweise auf Modellebene, darunter Infrastruktur-Attestierung. Für Agenten-Entwickler abseits von Apples Plattformen hat jedes Teil ein Äquivalent: .onToolCall ist Ihr Tool-Aufruf-Interzeptor, .historyTransform ist Ihr Kontext-Bereiniger, schema-vererbte Risiko-Metadaten sind Ihre Tool-Klassifikationstabelle, und nur-strenger-authenticationPolicy-Überschreibungen sind Ihre Richtlinien-Untergrenze. Die Framework-Namen gehören Apple; die Architektur ist portierbar, und sie deckt sich mit dem Defense-in-Depth, das dieser Blog in ein Agent mit zwei nicht vertrauenswürdigen Eingaben und Laufzeitverteidigung für tool-erweiterte Agenten dargelegt hat.

FAQ

Was ist Apples empfohlene Verteidigung gegen Prompt Injection?

Zuerst Threat Modeling (Identifizieren von Quellen nicht vertrauenswürdigen Kontexts und Nebenwirkungen von Aktionen), dann „deterministische Gegenmaßnahmen als Grundlage, weil deren Sicherheitsgarantien einfacher zu prüfen und nachzuvollziehen sind”, mit obenauf gelegten probabilistischen Gegenmaßnahmen wie Spotlighting.¹ Konkret: Benutzerbestätigungen und das Erfordernis, das Gerät zu entsperren, bei riskanten Aktionen, PII-Schwärzung und Spotlighting-Trennzeichen bei nicht vertrauenswürdigem Kontext.

Welche APIs setzen diese Guardrails um?

In Foundation Models die Lebenszyklus-Event-Modifikatoren: .onToolCall (fängt deterministisch jeden Tool-Aufruf vor der Ausführung ab; das Werfen eines Fehlers blockiert das Tool) und .historyTransform (schreibt das Transkript-Ende vor jedem Inferenzdurchlauf um), mit @SessionProperty für persistente Transformationen.¹ In App Intents treiben schema-vererbte Risiko-Metadaten kontextbezogene Bestätigungen, und authenticationPolicy steuert den Sperrbildschirm-Zugriff mit nur-strenger-Überschreibungen.¹

Hat Apple Private Cloud Compute wirklich in Googles Cloud verlagert?

Ja, für neue Apple-Intelligence-Workloads. PCC erstreckt sich nun auf Google Cloud mit NVIDIA-GPUs, Intel TDX und Googles Titan-Chip, behält dieselben fünf PCC-Anforderungen, Attestierungsanker zweier Anbieter, ein nur anhängbares Hardware-Ledger und eine ausschließlich von Apple erteilte Software-Genehmigung bei und steigert sich über einen Sommer-Vorschauzeitraum. Die Garantien von PCC erstrecken sich weiterhin nicht auf Drittanbietermodelle wie Gemini oder Claude, die über das Sprachmodell-Protokoll erreicht werden.³

Gilt irgendetwas davon außerhalb der Apple-Plattformen?

Die Architektur schon. Interzeptoren im Ausführungspfad, Kontext-Bereiniger, Tool-Risikoklassifikation und Richtlinien-Untergrenzen sind portierbare Muster; Apples Versionen sind bemerkenswert, weil sie als Framework-APIs mit deterministischen Verträgen ausgeliefert werden statt als Leitlinien.

Apples Gegenmaßnahmen-Stack landet in einem Gebiet, das dieser Blog seit einem Jahr kartiert hat: die Trifecta-Rahmung in ein Agent mit zwei nicht vertrauenswürdigen Eingaben, das Argument zum Ausführungspfad in Bestätigungsabfragen sind keine Autorisierung und die Infrastruktur-Geschichte in Foundation Models und Private Cloud Compute. Der vollständige Serien-Hub ist die Apple-Ecosystem-Serie.

Referenzen