A resposta própria da Apple à injeção de prompt

A Apple agora cita Simon Willison pelo nome. Na sessão 347 da WWDC 2026, um engenheiro de segurança da Apple enquadra o risco agêntico exatamente da forma como a linha de segurança deste blog faz há um ano: “podemos recorrer à Lethal Trifecta de Simon Willison, que descreve que um usuário está em maior perigo sempre que um sistema agêntico tem: acesso a dados privados, exposição a conteúdo não confiável e a capacidade de se comunicar externamente.”¹ A sessão, o lab do grupo de Privacidade e Segurança e um anúncio no security.apple.com na mesma semana somam o quadro mais completo até agora de como o fornecedor de plataforma com a maior frota de dispositivos pensa em proteger agentes: guardrails determinísticos como base, probabilísticos como reforço e atestação de infraestrutura sustentando tudo.

A lethal trifecta, citada em 5:55 na sessão 347.

Resumo

• A sessão 347 é a doutrina própria da Apple contra injeção de prompt: identifique o contexto não confiável por meio de modelagem de ameaças e então “concentre-se em mitigações determinísticas como base, porque suas garantias de segurança são mais fáceis de auditar e raciocinar”, com mitigações probabilísticas como spotlighting sobrepostas por cima.¹
• Os guardrails são APIs que estão sendo lançadas, não conselhos. Os modificadores de eventos de ciclo de vida do Foundation Models oferecem ganchos determinísticos: .onToolCall intercepta cada chamada de ferramenta antes da execução e a bloqueia lançando um erro, e .historyTransform reescreve a transcrição antes de cada passagem de inferência para delimitadores de spotlighting e redação de PII.¹
• O App Intents aplica risco automaticamente: as intents herdam metadados de risco dos schemas que adotam, um sistema de avaliação de risco dispara confirmações contextuais, e o authenticationPolicy só pode ser sobrescrito no sentido mais restritivo.¹
• Na mesma semana, a Apple estendeu o Private Cloud Compute para além de seus próprios data centers, levando-o ao Google Cloud em hardware NVIDIA, mantendo os mesmos cinco requisitos centrais e ancorando a atestação de software “em pelo menos duas raízes de confiança separadas de fornecedores independentes.”²
• O lab do grupo de Privacidade e Segurança preencheu a textura: a Apple descreve usar essa pilha determinística-mais-probabilística em Siri AI, Safari e Xcode, cujos recursos agênticos usam allowlists de ferramentas quando o Xcode atua como um servidor MCP.³

A doutrina: determinístico primeiro, probabilístico depois

A sessão 347 conduz um app de exemplo por um modelo de ameaças que parecerá familiar a qualquer um que rode agentes em produção. Injeção de prompt indireta é definida como “instruções incorporadas em contexto extra fornecido ao modelo com a intenção de redirecionar o fluxo de controle”, e a sessão divide suas consequências em dois efeitos que vale a pena manter separados: envenenamento de dados, “um atacante influenciando os parâmetros de uma ação executada”, e envenenamento de ação, “em que o atacante influencia qual ação executar.”¹ A sessão é honesta sobre o estado da arte de uma forma que o material de fornecedor raramente é: “resolver a injeção de prompt indireta é uma área de pesquisa ativa, o que significa que nossa melhor abordagem no momento é entender o quanto seu app está em risco e buscar mitigar esse risco.”¹

O princípio de ordenação é a parte que vale citar em revisões de design. As mitigações determinísticas vêm primeiro “porque suas garantias de segurança são mais fáceis de auditar e raciocinar”; as mitigações probabilísticas valem a pena por serem adicionadas porque “modelos diferentes poderiam impor essas restrições de forma mais eficaz”, mas a sessão imediatamente admite o limite: o spotlighting “é uma mitigação probabilística porque a injeção de prompt poderia ser construída de uma forma que anule o spotlighting.”¹ Confirmações do usuário e requisitos de desbloqueio do dispositivo ficam do lado determinístico do balanço. A redação impede que PII chegue ao modelo, “e, portanto, não pode ser exfiltrada.”¹ A Apple afirma ter usado essas mitigações ao projetar o Siri AI.¹

Uma sutileza do modelo de ameaças merece atenção porque captura um caso que a maioria das allowlists deixa passar. Uma ação de criar timer parece inofensiva até você notar seu parâmetro de rótulo opcional: uma injeção de prompt pode definir o rótulo com texto controlado pelo atacante, e “uma consulta subsequente para listar timers pode então puxar esses dados controlados pelo atacante para aquele contexto, envenenando assim o novo contexto também.”¹ Ferramentas sem efeitos colaterais com campos de string graváveis são mecanismos de persistência para injeções.

As APIs de guardrail do Foundation Models

A metade de implementação da sessão mapeia a doutrina sobre duas superfícies que estão sendo lançadas. No framework Foundation Models, os modificadores de eventos de ciclo de vida são “callbacks que disparam deterministicamente em certos pontos do ciclo de vida na execução de uma sessão.”¹

O .onToolCall é o ponto de verificação da ação. Ele “tem disparo garantido quando o LLM emite uma chamada de ferramenta, antes de o executor rodar a ferramenta”, e o contrato é a parte útil: “se este callback lançar um erro, então a ferramenta nunca é executada.”¹ O exemplo da sessão restringe uma ferramenta de impacto financeiro atrás de confirmação do usuário em um único lugar e obtém cobertura para cada chamada de ferramenta na sessão. O formato é o mesmo que este blog defendeu em prompts de aprovação não são autorização: a verificação fica no caminho de execução, não nas instruções do modelo.

O .historyTransform é o ponto de verificação da entrada. Ele “dispara antes de a transcrição ser renderizada para o modelo para inferência”, tanto em novas solicitações do usuário quanto em cada iteração do loop, e a sessão o usa para as duas mitigações de prompt: envolver saídas de ferramentas de fontes não confiáveis em delimitadores de spotlighting e substituir dados sensíveis por um marcador de redação.¹ Um detalhe que importa para quem implementa: entradas transformadas têm escopo apenas na passagem de inferência atual, então as transformações se reaplicam a cada iteração, com a anotação @SessionProperty como válvula de escape para transformações com estado caras.¹

App Intents: metadados de risco que você herda, não escreve

O lado voltado para o Siri obtém seus guardrails do sistema de schemas. Quando uma intent adota um schema de intent, os metadados de risco “são automaticamente atribuídos” com base nos efeitos colaterais do schema: ações destrutivas, exfiltradoras e que atualizam conteúdo compartilhado são mais arriscadas, e “o sistema tem maior probabilidade de disparar confirmações para ferramentas de alto risco.”¹ Um sistema de avaliação de risco combina esses metadados estáticos com o estado dinâmico do sistema para decidir, contextualmente, se interpõe uma confirmação antes de a intent executar; recusar bloqueia a intent por completo.¹

A exposição na tela de bloqueio recebe o mesmo tratamento. Como o Siri funciona em um dispositivo bloqueado, um atacante em posse física pode alcançar suas intents, então intents personalizadas definem um authenticationPolicy, os schemas carregam padrões baseados em sensibilidade, e a restrição é exatamente certa: “você pode sobrescrever a política do schema, mas apenas para torná-la mais restritiva”, com um erro de compilação nomeando a política mínima permitida se você tentar enfraquecê-la.¹ O compilador se recusando a deixar você subproteger uma ação é a mitigação de injeção de prompt mais com cara de Apple que se pode imaginar.

A camada de infraestrutura: o PCC deixa os data centers da Apple

Três dias antes de a sessão ir ao ar, a Apple publicou “Expanding Private Cloud Compute” em seu blog de segurança: novas cargas de trabalho do Apple Intelligence agora rodam no Google Cloud com GPUs NVIDIA, “estendendo nossos compromissos de privacidade do PCC, líderes do setor, a data centers de terceiros pela primeira vez.”² Os cinco requisitos centrais permanecem inalterados: “computação sem estado, garantias aplicáveis, nenhum acesso privilegiado em tempo de execução, não direcionabilidade e transparência verificável.”² O que muda é a implementação: NVIDIA Confidential Computing, CPUs Intel com TDX e o chip Titan do Google.²

Duas escolhas de design se destacam frente ao status quo da computação confidencial. Para componentes que poderiam exfiltrar dados do usuário se comprometidos, “a atestação de software é ancorada em pelo menos duas raízes de confiança separadas de fornecedores independentes”, e a Apple mantém “um registro criptograficamente verificável e apenas de acréscimo de todo o hardware do Google Cloud que faz parte da frota PCC” contra ataques à cadeia de suprimentos.² Os padrões arquiteturais do PCC em Apple silicon também se mantêm: análise de rede por requisição em um processo dedicado com namespace próprio, software de inferência compartilhado reciclado com um tempo de vida curto, chaves atestadas mantidas em uma VM confidencial separada e isolada de entradas externas.² O controle permanece centralizado: “a Apple mantém controle completo sobre o software do PCC; os dispositivos Apple só confiarão em software do PCC criptograficamente aprovado pela Apple”, com todos os binários publicados para inspeção pública e nós ao vivo em modo de pesquisa acessíveis por meio do Apple Security Bounty Program.² O lançamento é escalonado, “aumentando gradualmente em direção ao conjunto completo de proteções ao longo do período de prévia do verão.”²

O que o lab acrescentou

O lab do grupo de Privacidade e Segurança ocorreu na mesma semana, e a Apple não publica legendas para os labs, então o que segue é parafraseado de uma gravação transcrita localmente, em vez de citado.³ O painel conectou a doutrina da sessão às superfícies que estão sendo lançadas: a pilha determinística-mais-probabilística roda em Siri AI, Safari e nos recursos agênticos do Xcode, e quando o Xcode atua como um servidor MCP, ele restringe agentes com allowlists de ferramentas permitidas.³ Sobre a arquitetura do Siri AI, um painelista descreveu um daemon dedicado, fortalecido e em sandbox, com restrição por entitlement como o único caminho para coletar e formatar dados do usuário antes de eles saírem para o Private Cloud Compute, com requisições multi-turno solicitando permissão novamente para dados recém-acessados no meio da conversa.³

Vale destacar mais dois fios do lab para acompanhamento. O painel disse que as garantias de privacidade do Foundation Models não se estendem a modelos de terceiros alcançados pelo protocolo de modelo de linguagem do framework; o desenvolvedor é responsável por ler os termos desses provedores e divulgar de acordo.³ E sobre a questão do ciclo de vida de passkeys que tem perseguido a adoção do WebAuthn, um painelista apontou a Signal API como a resposta resolvida: os padrões web agora definem signalUnknownCredential, signalAllAcceptedCredentials e signalCurrentUserDetails para manter as credenciais sincronizadas entre relying parties e autenticadores, e a API é real e está sendo lançada no W3C WebAuthn Level 3.⁴

O que extrair disso

A parte útil não é que a Apple resolveu a injeção de prompt; a sessão diz claramente que ninguém resolveu. A parte útil é ver um fornecedor de plataforma se comprometer com uma ordenação: controles determinísticos no caminho de execução primeiro, dicas no nível do modelo em segundo, atestação de infraestrutura por baixo. Para quem constrói agentes fora das plataformas da Apple, cada peça tem um equivalente: .onToolCall é o seu interceptador de chamadas de ferramenta, .historyTransform é o seu sanitizador de contexto, os metadados de risco herdados do schema são a sua tabela de classificação de ferramentas, e as sobrescritas de authenticationPolicy apenas-mais-restritivas são o seu piso de política. Os nomes do framework são da Apple; a arquitetura é portátil, e ela corresponde à defesa em profundidade que este blog expôs em um agente com duas entradas não confiáveis e defesa em tempo de execução para agentes com ferramentas.

Perguntas frequentes

Qual é a defesa recomendada pela Apple contra injeção de prompt?

Faça a modelagem de ameaças primeiro (identifique as fontes de contexto não confiável e os efeitos colaterais das ações), e então aplique “mitigações determinísticas como base, porque suas garantias de segurança são mais fáceis de auditar e raciocinar”, com mitigações probabilísticas como spotlighting adicionadas por cima.¹ Concretamente: confirmações do usuário e requisitos de desbloqueio do dispositivo em ações arriscadas, redação de PII e delimitadores de spotlighting em contexto não confiável.

Quais APIs implementam esses guardrails?

No Foundation Models, os modificadores de eventos de ciclo de vida: .onToolCall (intercepta deterministicamente cada chamada de ferramenta antes da execução; lançar um erro bloqueia a ferramenta) e .historyTransform (reescreve a cauda da transcrição antes de cada passagem de inferência), com @SessionProperty para transformações persistentes.¹ No App Intents, os metadados de risco herdados do schema conduzem confirmações contextuais, e o authenticationPolicy controla o acesso na tela de bloqueio com sobrescritas apenas-mais-restritivas.¹

A Apple realmente moveu o Private Cloud Compute para a nuvem do Google?

Sim, para novas cargas de trabalho do Apple Intelligence. O PCC agora se estende ao Google Cloud em GPUs NVIDIA com Intel TDX e o chip Titan do Google, mantendo os mesmos cinco requisitos do PCC, raízes de atestação de dois fornecedores, um registro de hardware apenas de acréscimo e aprovação de software exclusiva da Apple, escalonando ao longo de um período de prévia do verão.² As garantias do PCC ainda não se estendem a modelos de terceiros como Gemini ou Claude alcançados pelo protocolo de modelo de linguagem.³

Algo disso se aplica fora das plataformas da Apple?

A arquitetura sim. Interceptadores no caminho de execução, sanitizadores de contexto, classificação de risco de ferramentas e pisos de política são padrões portáteis; as versões da Apple são notáveis porque são lançadas como APIs de framework com contratos determinísticos, em vez de como orientação.

A pilha de mitigação da Apple cai em território que este blog vem mapeando há um ano: o enquadramento da trifecta em um agente com duas entradas não confiáveis, o argumento do caminho de execução em prompts de aprovação não são autorização, e a história da infraestrutura em Foundation Models e Private Cloud Compute. O hub completo da série é a Série Ecossistema Apple.

Referências