La respuesta propia de Apple al prompt injection

Apple ahora cita a Simon Willison por su nombre. En la sesión 347 de la WWDC 2026, un ingeniero de seguridad de Apple plantea el riesgo agéntico exactamente como lo ha hecho durante un año el hilo de seguridad de este blog: “podemos fijarnos en la Lethal Trifecta de Simon Willison, que describe que un usuario corre el mayor peligro siempre que un sistema agéntico tiene: acceso a datos privados, exposición a contenido no confiable y la capacidad de comunicarse externamente.”¹ La sesión, el lab del grupo de Privacidad y Seguridad, y un anuncio en security.apple.com esa misma semana suman la imagen más completa hasta ahora de cómo el fabricante de plataformas con la mayor flota de dispositivos piensa sobre la seguridad de los agentes: guardarraíles deterministas como base, probabilísticos como refuerzo, y atestación de infraestructura por debajo de todo.

La lethal trifecta, citada en el minuto 5:55 de la sesión 347.

En resumen

• La sesión 347 es la doctrina propia de Apple sobre el prompt injection: identifica el contexto no confiable mediante modelado de amenazas y luego “enfócate en mitigaciones deterministas como base, porque sus garantías de seguridad son más fáciles de auditar y razonar,” con mitigaciones probabilísticas como el spotlighting superpuestas encima.¹
• Los guardarraíles son APIs que ya se envían, no consejos. Los modificadores de eventos de ciclo de vida de Foundation Models ofrecen hooks deterministas: .onToolCall intercepta cada llamada de herramienta antes de ejecutarla y la bloquea lanzando un error, y .historyTransform reescribe la transcripción antes de cada pasada de inferencia para los delimitadores de spotlighting y la redacción de PII.¹
• App Intents aplica el riesgo de forma automática: los intents heredan metadatos de riesgo de los esquemas que adoptan, un sistema de evaluación de riesgo dispara confirmaciones contextuales, y authenticationPolicy solo puede sobrescribirse hacia una política más estricta.¹
• Esa misma semana, Apple extendió Private Cloud Compute más allá de sus propios centros de datos hacia Google Cloud sobre hardware de NVIDIA, manteniendo los mismos cinco requisitos fundamentales y enraizando la atestación de software “en al menos dos raíces de confianza independientes de proveedores distintos.”²
• El lab del grupo de Privacidad y Seguridad aportó la textura: Apple describe el uso de este stack determinista-más-probabilístico en Siri AI, Safari y Xcode, cuyas funciones agénticas usan listas de permitidos de herramientas cuando Xcode actúa como servidor MCP.³

La doctrina: primero determinista, segundo probabilístico

La sesión 347 recorre una app de ejemplo a través de un modelo de amenazas que le resultará familiar a cualquiera que opere agentes en producción. El indirect prompt injection se define como “instrucciones incrustadas en contexto adicional proporcionado al modelo con la intención de redirigir el flujo de control,” y la sesión divide sus consecuencias en dos efectos que conviene distinguir: el envenenamiento de datos, “un atacante que influye en los parámetros de una acción ejecutada,” y el envenenamiento de acciones, “donde el atacante influye en qué acción ejecutar.”¹ La sesión es honesta sobre el estado del arte de una forma que el material de los fabricantes rara vez es: “resolver el indirect prompt injection es un área de investigación activa, lo que significa que nuestro mejor enfoque por el momento es entender cuánto riesgo corre tu app y apuntar a mitigar ese riesgo.”¹

El principio de ordenamiento es la parte que vale la pena citar en las revisiones de diseño. Las mitigaciones deterministas van primero “porque sus garantías de seguridad son más fáciles de auditar y razonar”; las mitigaciones probabilísticas vale la pena añadirlas porque “distintos modelos podrían imponer estas restricciones de forma más efectiva,” pero la sesión concede de inmediato el límite: el spotlighting “es una mitigación probabilística porque el prompt injection podría construirse de manera que anule el spotlighting.”¹ Las confirmaciones del usuario y los requisitos de desbloqueo del dispositivo caen del lado determinista del balance. La redacción evita que la PII llegue siquiera al modelo, “y por tanto no puede ser exfiltrada.”¹ Apple afirma que ha usado estas mitigaciones al diseñar Siri AI.¹

Una sutileza del modelo de amenazas merece atención porque atrapa un caso que la mayoría de las listas de permitidos pasan por alto. Una acción de crear un temporizador parece inofensiva hasta que reparas en su parámetro opcional de etiqueta: un prompt injection puede fijar la etiqueta a texto controlado por el atacante, y “una consulta posterior para listar temporizadores puede entonces arrastrar esos datos controlados por el atacante a ese contexto, envenenando así también el nuevo contexto.”¹ Las herramientas sin efectos secundarios pero con campos de texto escribibles son mecanismos de persistencia para las inyecciones.

Las APIs de guardarraíles de Foundation Models

La mitad de implementación de la sesión mapea la doctrina sobre dos superficies que ya se envían. En el framework Foundation Models, los modificadores de eventos de ciclo de vida son “callbacks que se disparan de forma determinista en ciertos puntos del ciclo de vida de la ejecución de una sesión.”¹

.onToolCall es el punto de control de la acción. “Tiene garantizado dispararse cuando el LLM emite una llamada de herramienta, antes de que el ejecutor corra la herramienta,” y el contrato es la parte útil: “si este callback lanza un error, entonces la herramienta nunca se ejecuta.”¹ El ejemplo de la sesión protege una herramienta de impacto financiero detrás de una confirmación del usuario en un solo lugar y obtiene cobertura para cada llamada de herramienta de la sesión. La forma es la misma que este blog defendió en los avisos de aprobación no son autorización: la verificación vive en la ruta de ejecución, no en las instrucciones del modelo.

.historyTransform es el punto de control de la entrada. “Se dispara antes de que la transcripción se renderice al modelo para la inferencia,” tanto en las nuevas solicitudes del usuario como en cada iteración del bucle, y la sesión lo usa para las dos mitigaciones de prompt: envolver las salidas de herramientas de fuentes no confiables en delimitadores de spotlighting, y reemplazar los datos sensibles con un marcador de redacción.¹ Un detalle que importa para quien lo implemente: las entradas transformadas tienen alcance solo para la pasada de inferencia actual, así que las transformaciones se reaplican en cada iteración, con la anotación @SessionProperty como vía de escape para transformaciones con estado que resultan costosas.¹

App Intents: metadatos de riesgo que heredas, no que escribes

El lado orientado a Siri obtiene sus guardarraíles del sistema de esquemas. Cuando un intent adopta un esquema de intent, los metadatos de riesgo “se asignan automáticamente” según los efectos secundarios del esquema: las acciones destructivas, exfiltradoras y que actualizan contenido compartido son más riesgosas, y “el sistema tiene más probabilidad de disparar confirmaciones para las herramientas de alto riesgo.”¹ Un sistema de evaluación de riesgo combina esos metadatos estáticos con el estado dinámico del sistema para decidir, de forma contextual, si interponer una confirmación antes de que el intent se ejecute; rechazarla bloquea el intent por completo.¹

La exposición en la pantalla de bloqueo recibe el mismo trato. Como Siri funciona en un dispositivo bloqueado, un atacante en posesión física puede alcanzar tus intents, así que los intents personalizados fijan un authenticationPolicy, los esquemas llevan valores predeterminados basados en la sensibilidad, y la restricción es exactamente la correcta: “puedes sobrescribir la política del esquema, pero solo para hacerla más estricta,” con un error de compilación que nombra la política mínima permitida si intentas debilitarla.¹ Que el compilador se niegue a dejarte sub-proteger una acción es la mitigación de prompt injection más típicamente Apple que se pueda imaginar.

La capa de infraestructura: PCC deja los centros de datos de Apple

Tres días antes de que se emitiera la sesión, Apple publicó “Expanding Private Cloud Compute” en su blog de seguridad: las nuevas cargas de trabajo de Apple Intelligence ahora corren en Google Cloud con GPUs de NVIDIA, “extendiendo por primera vez a centros de datos de terceros nuestros compromisos de privacidad de PCC, líderes en la industria.”² Los cinco requisitos fundamentales se mantienen sin cambios: “computación sin estado, garantías exigibles, sin acceso privilegiado en tiempo de ejecución, no objetivabilidad y transparencia verificable.”² Lo que cambia es la implementación: NVIDIA Confidential Computing, CPUs de Intel con TDX, y el chip Titan de Google.²

Dos decisiones de diseño destacan frente al statu quo de la computación confidencial. Para los componentes que podrían exfiltrar datos del usuario si se ven comprometidos, “la atestación de software se enraíza en al menos dos raíces de confianza independientes de proveedores distintos,” y Apple mantiene “un registro criptográficamente verificable, de solo anexado, de todo el hardware de Google Cloud que forma parte de la flota de PCC” frente a los ataques a la cadena de suministro.² Los patrones arquitectónicos de PCC sobre Apple silicon también se trasladan: el análisis de red por solicitud en un proceso dedicado con su propio namespace, el software de inferencia compartido reciclado con un tiempo de vida corto, y las claves atestadas custodiadas en una VM confidencial separada y aislada de las entradas externas.² El control permanece centralizado: “Apple conserva el control completo del software de PCC; los dispositivos Apple solo confiarán en software de PCC que Apple haya aprobado criptográficamente,” con todos los binarios publicados para inspección pública y los nodos en vivo en modo investigación accesibles a través del Apple Security Bounty Program.² El despliegue es por etapas, “incrementando gradualmente hacia el conjunto completo de protecciones a lo largo del período de vista previa del verano.”²

Lo que añadió el lab

El lab del grupo de Privacidad y Seguridad se realizó esa misma semana, y Apple no publica subtítulos para los labs, así que lo que sigue está parafraseado a partir de una grabación transcrita localmente, no citado.³ El panel conectó la doctrina de la sesión con superficies que ya se envían: el stack determinista-más-probabilístico corre en Siri AI, Safari y las funciones agénticas de Xcode, y cuando Xcode actúa como servidor MCP, restringe a los agentes con listas de permitidos de herramientas autorizadas.³ Un lab separado de Apple Intelligence trazó una línea útil entre dos modos de falla que los desarrolladores confunden. Un panelista distinguió un error de rechazo, donde el propio entrenamiento de alineación del modelo declina una solicitud y la falla aparece bajo generación guiada o estructurada, de un error de guardarraíl, donde un modelo de moderación separado inspecciona la entrada y la salida de forma independiente del modelo principal.⁵ El mismo panelista mencionó una configuración opcional que deja pasar entradas emocionalmente cargadas pero legítimas en lugar de hacer saltar el guardarraíl; el nombre exacto de esa configuración no era legible en la grabación y queda sin confirmar.⁵ Sobre la arquitectura de Siri AI, un panelista describió un daemon dedicado, endurecido y aislado en sandbox, con control mediante entitlements, como la única vía para recopilar y formatear los datos del usuario antes de que salgan hacia Private Cloud Compute, con solicitudes de varios turnos que vuelven a pedir permiso para datos recién accedidos a mitad de la conversación.³

Hay dos hilos más del lab que vale la pena señalar para darles seguimiento. El panel dijo que las garantías de privacidad de Foundation Models no se extienden a los modelos de terceros alcanzados a través del protocolo de modelo de lenguaje del framework; el desarrollador es responsable de leer los términos de esos proveedores y de divulgarlos en consecuencia.³ Y sobre la cuestión del ciclo de vida de las passkeys que ha perseguido a la adopción de WebAuthn, un panelista señaló la Signal API como la respuesta ya resuelta: los estándares web ahora definen signalUnknownCredential, signalAllAcceptedCredentials y signalCurrentUserDetails para mantener las credenciales sincronizadas entre las partes que confían y los autenticadores, y la API es real y ya se envía en WebAuthn Level 3 del W3C.⁴

Qué llevarse de todo esto

La parte útil no es que Apple haya resuelto el prompt injection; la sesión dice con claridad que nadie lo ha hecho. La parte útil es ver a un fabricante de plataformas comprometerse con un ordenamiento: primero los controles deterministas en la ruta de ejecución, segundo las pistas a nivel de modelo, y la atestación de infraestructura por debajo. Para quienes construyen agentes fuera de las plataformas de Apple, cada pieza tiene su equivalente: .onToolCall es tu interceptor de llamadas de herramienta, .historyTransform es tu saneador de contexto, los metadatos de riesgo heredados del esquema son tu tabla de clasificación de herramientas, y las sobrescrituras de authenticationPolicy solo-hacia-más-estricto son tu piso de políticas. Los nombres del framework son de Apple; la arquitectura es portable, y coincide con la defensa en profundidad que este blog planteó en un agente con dos entradas no confiables y defensa en tiempo de ejecución para agentes aumentados con herramientas.

Preguntas frecuentes

¿Cuál es la defensa que Apple recomienda contra el prompt injection?

Primero el modelado de amenazas (identifica las fuentes de contexto no confiable y los efectos secundarios de las acciones), luego aplica “mitigaciones deterministas como base, porque sus garantías de seguridad son más fáciles de auditar y razonar,” con mitigaciones probabilísticas como el spotlighting añadidas encima.¹ En concreto: confirmaciones del usuario y requisitos de desbloqueo del dispositivo en las acciones riesgosas, redacción de PII y delimitadores de spotlighting en el contexto no confiable.

¿Qué APIs implementan estos guardarraíles?

En Foundation Models, los modificadores de eventos de ciclo de vida: .onToolCall (intercepta de forma determinista cada llamada de herramienta antes de ejecutarla; lanzar un error bloquea la herramienta) y .historyTransform (reescribe la cola de la transcripción antes de cada pasada de inferencia), con @SessionProperty para las transformaciones persistentes.¹ En App Intents, los metadatos de riesgo heredados del esquema impulsan las confirmaciones contextuales, y authenticationPolicy controla el acceso desde la pantalla de bloqueo con sobrescrituras solo-hacia-más-estricto.¹

¿De verdad Apple movió Private Cloud Compute a la nube de Google?

Sí, para las nuevas cargas de trabajo de Apple Intelligence. PCC ahora se extiende a Google Cloud sobre GPUs de NVIDIA con Intel TDX y el chip Titan de Google, manteniendo los mismos cinco requisitos de PCC, raíces de atestación de doble proveedor, un registro de hardware de solo anexado y aprobación de software exclusiva de Apple, incrementando a lo largo de un período de vista previa de verano.² Las garantías de PCC siguen sin extenderse a los modelos de terceros como Gemini o Claude alcanzados a través del protocolo de modelo de lenguaje.³

¿Algo de esto aplica fuera de las plataformas de Apple?

La arquitectura sí. Los interceptores en la ruta de ejecución, los saneadores de contexto, la clasificación de riesgo de herramientas y los pisos de políticas son patrones portables; las versiones de Apple destacan porque se envían como APIs de framework con contratos deterministas en lugar de como una guía.

El stack de mitigación de Apple aterriza en un territorio que este blog ha mapeado durante un año: el encuadre de la trifecta en un agente con dos entradas no confiables, el argumento de la ruta de ejecución en los avisos de aprobación no son autorización, y la historia de la infraestructura en Foundation Models y Private Cloud Compute. El hub completo de la serie es la Serie del Ecosistema Apple.

Referencias