A resposta própria da Apple ao prompt injection

A Apple agora cita Simon Willison nominalmente. Na sessão 347 da WWDC 2026, um engenheiro de segurança da Apple enquadra o risco agêntico exatamente da forma como a trilha de segurança deste blog faz há um ano: “podemos recorrer à Lethal Trifecta de Simon Willison, que descreve que um usuário corre 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 Privacy and Security e um anúncio em security.apple.com na mesma semana somam o quadro mais completo até hoje de como o fornecedor de plataforma com a maior frota de dispositivos pensa sobre proteger agentes: guardrails determinísticos como base, probabilísticos como reforço, e atestação de infraestrutura sob tudo isso.

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

TL;DR

• A sessão 347 é a doutrina própria da Apple sobre prompt injection: identifique o contexto não confiável por meio de threat modeling, 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 a respeito”, com mitigações probabilísticas como o spotlighting sobrepostas a isso.¹
• 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 dão hooks determinísticos: .onToolCall intercepta cada chamada de ferramenta antes da execução e a bloqueia lançando uma exceção, e .historyTransform reescreve o transcript antes de cada passo de inferência para os delimitadores de spotlighting e a redação de PII.¹
• O App Intents aplica o risco automaticamente: as intents herdam metadados de risco dos schemas que adotam, um sistema de avaliação de risco aciona confirmações contextuais, e a authenticationPolicy só pode ser sobrescrita no sentido mais restritivo.¹
• Na mesma semana, a Apple estendeu o Private Cloud Compute para além de seus próprios data centers até o Google Cloud em hardware NVIDIA, mantendo os mesmos cinco requisitos centrais e enraizando a atestação de software “em pelo menos duas raízes de confiança separadas de fornecedores independentes”.²
• O lab do grupo de Privacy and Security preencheu a textura: a Apple descreve usar essa pilha determinística-mais-probabilística no Siri AI, no Safari e no 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 percorre um app de exemplo através de um threat model que parecerá familiar para qualquer um que rode agentes em produção. O prompt injection indireto é definido 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: o data poisoning, “um atacante influenciando os parâmetros de uma ação executada”, e o action poisoning, “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 fornecedores raramente é: “resolver o prompt injection indireto é uma área de pesquisa ativa, o que significa que nossa melhor abordagem no momento é entender o quanto seu app está em risco e mirar em mitigar esse risco”.¹

O princípio de ordenação é a parte que vale citar em design reviews. As mitigações determinísticas vêm primeiro “porque suas garantias de segurança são mais fáceis de auditar e raciocinar a respeito”; as mitigações probabilísticas valem a pena adicionar 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 o prompt injection poderia ser construído de uma forma que anule o spotlighting”.¹ As confirmações do usuário e os requisitos de desbloqueio do dispositivo ficam do lado determinístico do balanço. A redação impede que a 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 threat model merece atenção porque captura um caso que a maioria das allowlists deixa passar. Uma ação de criar timer parece inofensiva até você reparar em seu parâmetro opcional de rótulo: um prompt injection pode definir o rótulo como um texto controlado pelo atacante, e “uma consulta subsequente para listar timers pode então puxar esses dados controlados pelo atacante para esse contexto, envenenando assim também o novo contexto”.¹ 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 em 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”.¹

.onToolCall é o checkpoint de ação. Ele “tem disparo garantido quando o LLM emite uma chamada de ferramenta, antes que o executor rode 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 protege uma ferramenta de impacto financeiro atrás de uma 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.

.historyTransform é o checkpoint de entrada. Ele “dispara antes que o transcript seja renderizado 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 as saídas de ferramentas de fontes não confiáveis em delimitadores de spotlighting, e substituir dados sensíveis por um placeholder de redação.¹ Um detalhe que importa para quem implementa: as entradas transformadas têm escopo apenas para o passo de inferência atual, então as transformações se reaplicam a cada iteração, com a anotação @SessionProperty como a saída de emergência para transformações stateful custosas.¹

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

O lado voltado ao Siri obtém seus guardrails do sistema de schemas. Quando uma intent adota um intent schema, os metadados de risco “são automaticamente atribuídos” com base nos efeitos colaterais do schema: ações destrutivas, exfiltrantes e que atualizam conteúdo compartilhado são mais arriscadas, e “o sistema tem maior probabilidade de acionar 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, de forma contextual, se interpõe uma confirmação antes que a intent execute; recusar bloqueia a intent inteiramente.¹

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 as intents personalizadas definem uma 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 build 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 prompt injection mais cara da Apple que se pode imaginar.

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

Três dias antes da 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 líderes do setor do PCC a data centers de terceiros pela primeira vez”.² Os cinco requisitos centrais se mantêm 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 é enraizada em pelo menos duas raízes de confiança separadas de fornecedores independentes”, e a Apple mantém “um ledger criptograficamente verificável e somente de adição de todo o hardware do Google Cloud que faz parte da frota do PCC” contra ataques à cadeia de suprimentos.² Os padrões arquiteturais do PCC em Apple silicon também se mantêm: o parsing de rede por requisição em um processo dedicado com namespace, o software de inferência compartilhado reciclado em um time-to-live curto, e chaves atestadas mantidas em uma VM confidencial separada, 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 que seja criptograficamente aprovado pela Apple”, com todos os binários publicados para inspeção pública e nós ativos em modo de pesquisa acessíveis por meio do Apple Security Bounty Program.² O lançamento é faseado, “ampliando 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 Privacy and Security ocorreu na mesma semana, e a Apple não publica legendas para os labs, então o que segue é parafraseado a partir de uma gravação transcrita localmente, em vez de citado.³ O painel conectou a doutrina da sessão a superfícies que estão sendo lançadas: a pilha determinística-mais-probabilística roda no Siri AI, no Safari e nos recursos agênticos do Xcode, e quando o Xcode atua como um servidor MCP, ele restringe os agentes com allowlists de ferramentas permitidas.³ Um lab separado do Apple Intelligence traçou uma linha útil entre dois modos de falha que os desenvolvedores confundem. Um painelista distinguiu um refusal error, em que o próprio treinamento de alinhamento do modelo recusa uma solicitação e a falha aparece sob geração guiada ou estruturada, de um guardrail error, em que um modelo de moderação separado inspeciona a entrada e a saída de forma independente do modelo principal.⁵ O mesmo painelista observou uma configuração opt-in que deixa passar entradas emocionalmente carregadas mas legítimas, em vez de acionar o guardrail; o nome exato dessa configuração não estava legível na gravação e permanece não confirmado.⁵ Sobre a arquitetura do Siri AI, um painelista descreveu um daemon dedicado, endurecido e em sandbox, com gating por entitlement como o único caminho para coletar e formatar dados do usuário antes que eles partam para o Private Cloud Compute, com solicitações de múltiplos turnos repedindo permissão para dados recém-acessados no meio da conversa.³

Mais duas linhas do lab valem a pena destacar para acompanhamento. O painel disse que as garantias de privacidade do Foundation Models não se estendem a modelos de terceiros alcançados através do 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 passkey 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 tirar disso

A parte útil não é que a Apple resolveu o prompt injection; 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 em nível de 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 combina com a defesa em profundidade que este blog expôs em um agente com duas entradas não confiáveis e em defesa em tempo de execução para agentes aumentados por ferramentas.

FAQ

Qual é a defesa recomendada pela Apple contra prompt injection?

Faça o threat model 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 a respeito”, com mitigações probabilísticas como o 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 uma exceção bloqueia a ferramenta) e .historyTransform (reescreve a cauda do transcript antes de cada passo de inferência), com @SessionProperty para transformações persistentes.¹ No App Intents, os metadados de risco herdados do schema dirigem as confirmações contextuais, e a 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 ledger de hardware somente de adição e aprovação de software apenas pela Apple, ampliando 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 através do 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ções.

A pilha de mitigação da Apple aterrissa em território que este blog mapeou por 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 de infraestrutura em Foundation Models e Private Cloud Compute. O hub completo da série é a Série Apple Ecosystem.

Referências