La respuesta propia de Apple a la inyección de prompts

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 el hilo de seguridad de este blog durante un año: “podemos recurrir a la Lethal Trifecta de Simon Willison, que describe que un usuario está en 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 en la seguridad de los agentes: protecciones deterministas como base, probabilísticas como refuerzo, y atestación de infraestructura por debajo de todo ello.

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

TL;DR

• La sesión 347 es la doctrina propia de Apple sobre la inyección de prompts: identifica el contexto no confiable mediante modelado de amenazas, y luego “concéntrate en las 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.¹
• Las protecciones son APIs que ya se lanzan, no consejos. Los modificadores de eventos del ciclo de vida de Foundation Models ofrecen hooks deterministas: .onToolCall intercepta cada llamada a herramienta antes de su ejecución 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 automáticamente: los intents heredan los metadatos de riesgo de los esquemas que adoptan, un sistema de evaluación de riesgo activa confirmaciones contextuales, y authenticationPolicy solo se puede sobrescribir hacia algo más estricto.¹
• 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 centrales 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 completó el cuadro: 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 lleva una app de ejemplo a través de un modelo de amenazas que le resultará familiar a cualquiera que ejecute agentes en producción. La inyección indirecta de prompts se define como “instrucciones embebidas en el contexto extra proporcionado al modelo con la intención de redirigir el flujo de control”, y la sesión divide sus consecuencias en dos efectos que vale la pena mantener separados: 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 la inyección indirecta de prompts 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 ordenación 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 aplicar estas restricciones con más eficacia”, pero la sesión concede de inmediato el límite: el spotlighting “es una mitigación probabilística porque la inyección de prompts 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 lo 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 captura un caso que la mayoría de las listas de permitidos pasan por alto. Una acción de crear temporizador parece inofensiva hasta que reparas en su parámetro opcional de etiqueta: una inyección de prompts puede fijar la etiqueta a un texto controlado por el atacante, y “una consulta posterior para listar los 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 protección de Foundation Models

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

.onToolCall es el punto de control de la acción. “Está garantizado que se dispara cuando el LLM emite una llamada a 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 condiciona una herramienta de impacto financiero a la confirmación del usuario en un solo lugar y obtiene cobertura para cada llamada a herramienta de la sesión. La forma es la misma que defendió este blog en los prompts de aprobación no son autorización: la comprobació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 quienes implementan: las entradas transformadas tienen alcance únicamente en la pasada de inferencia actual, de modo que las transformaciones se reaplican en cada iteración, con la anotación @SessionProperty como vía de escape para las transformaciones con estado que resultan costosas.¹

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

El lado orientado a Siri obtiene sus protecciones 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, exfiltrantes y que actualizan contenido compartido son más riesgosas, y “el sistema es más propenso a activar confirmaciones para 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 tratamiento. Como Siri funciona en un dispositivo bloqueado, un atacante con posesión física puede alcanzar tus intents, así que los intents personalizados fijan una 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 subproteger una acción es la mitigación de inyección de prompts con la forma más apple-iana que se pueda imaginar.

La capa de infraestructura: PCC abandona 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 centrales se mantienen sin cambios: “cómputo sin estado, garantías exigibles, sin acceso privilegiado en tiempo de ejecución, no segmentabilidad 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 del cómputo 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, solo de adición, 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 en Apple silicon también se trasladan: el análisis de red por solicitud en un proceso dedicado con espacio de nombres aislado, el software de inferencia compartido reciclado con un tiempo de vida corto, las claves atestadas guardadas 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 esté criptográficamente aprobado por Apple”, con todos los binarios publicados para inspección pública y los nodos en modo de investigación en vivo accesibles a través del Apple Security Bounty Program.² El despliegue es escalonado, “ascendiendo 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 lanzan: 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.³ 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 recolectar y formatear los datos del usuario antes de que salgan hacia Private Cloud Compute, donde las solicitudes de varios turnos vuelven a pedir permiso para los datos recién accedidos a mitad de la conversación.³

Vale la pena señalar otros dos hilos del lab 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 como corresponda.³ Y sobre la cuestión del ciclo de vida de las passkeys que ha perseguido la adopción de WebAuthn, un panelista señaló la Signal API como la respuesta 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 lanza en W3C WebAuthn Level 3.⁴

Qué llevarse de todo esto

La parte útil no es que Apple resolviera la inyección de prompts; la sesión dice con franqueza que nadie lo ha hecho. La parte útil es ver a un fabricante de plataformas comprometerse con una ordenación: controles deterministas en la ruta de ejecución primero, pistas a nivel de modelo segundo, atestación de infraestructura por debajo. Para quienes construyen agentes fuera de las plataformas de Apple, cada pieza tiene un equivalente: .onToolCall es tu interceptor de llamadas a herramienta, .historyTransform es tu sanitizador de contexto, los metadatos de riesgo heredados del esquema son tu tabla de clasificación de herramientas, y las sobrescrituras de authenticationPolicy que solo permiten hacerla más estricta son tu piso de políticas. Los nombres del framework son de Apple; la arquitectura es portátil, y coincide con la defensa en profundidad que este blog expuso en un agente con dos entradas no confiables y defensa en tiempo de ejecución para agentes aumentados con herramientas.

FAQ

¿Cuál es la defensa recomendada por Apple contra la inyección de prompts?

Modela las amenazas primero (identifica las fuentes de contexto no confiable y los efectos secundarios de las acciones), y 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 estas protecciones?

En Foundation Models, los modificadores de eventos del ciclo de vida: .onToolCall (intercepta de forma determinista cada llamada a herramienta antes de la ejecución; 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 que solo permiten hacerla más estricta.¹

¿Apple realmente 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 solo de adición y aprobación de software exclusiva de Apple, ascendiendo a lo largo de un período de vista previa del 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 sanitizadores de contexto, la clasificación de riesgo de las herramientas y los pisos de políticas son patrones portátiles; las versiones de Apple son notables porque se lanzan como APIs de framework con contratos deterministas en lugar de como orientaciones.

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 prompts de aprobación no son autorización, y la historia de infraestructura en Foundation Models y Private Cloud Compute. El hub completo de la serie es la Serie del Ecosistema Apple.

Referencias