A inferência de IA no dispositivo está a entrar em sistemas operativos, navegadores e ferramentas de produtividade. Essa mudança altera o modelo de segurança. Os dados sensíveis podem ficar mais perto do utilizador, mas o modelo também fica mais perto de ficheiros, estado do navegador, conteúdo da área de transferência e ferramentas locais do sistema.
Duas histórias de maio de 2026 mostram porque isto importa agora. O investigador de segurança Alexander Hanff reportou que o Google Chrome estava a descarregar um modelo Gemini Nano com cerca de 4GB para dispositivos sem um pedido claro de consentimento. Na mesma altura, as integrações de navegador do Claude Desktop receberam escrutínio porque pontes locais do navegador podem expandir aquilo que um assistente de IA consegue alcançar.
A lição não é que a inferência no dispositivo seja má. A lição é que modelos locais poderosos precisam da mesma disciplina de segurança que qualquer processo local privilegiado: permissões explícitas, limites rigorosos de entrada, telemetria auditável e visibilidade na camada do navegador.
O que muda com a inferência omnívora
"Inferência omnívora" é uma expressão útil para este problema. Modelos locais tornam-se valiosos porque conseguem consumir mais contexto: ficheiros, dados da área de transferência, histórico do navegador, conteúdo visível das páginas, processos em execução e estado do dispositivo.
Esse contexto torna o assistente útil. Também transforma o assistente num alvo de alto valor.
Quando um modelo local corre com permissões amplas, o atacante já não precisa de roubar diretamente a fonte dos dados. Pode tentar conduzir o modelo para ler, resumir, transformar ou enviar esses dados por ele.
O navegador é o ponto de entrada óbvio
O navegador é onde muitas entradas não confiáveis encontram ferramentas locais privilegiadas. Uma página maliciosa, uma extensão comprometida ou um script de terceiro carregado por um ataque de supply chain podem tornar-se entrada do modelo.
Se um LLM local expõe um endpoint local ou uma ponte de navegador sem autorização forte, JavaScript arbitrário do lado do cliente torna-se um risco. Um script poderia tentar consultar o modelo, pedir-lhe para resumir contexto local sensível ou empurrá-lo para uma chamada de ferramenta que o utilizador nunca pretendeu.
É por isso que a segurança do lado do cliente faz parte da segurança da IA local. As equipas de segurança precisam de saber que scripts executam no navegador, o que carregam e se tentam comportamentos fora do papel esperado.
Porque a injeção de prompts tem mais impacto em local
A injeção de prompts é o risco mais alto no OWASP Top 10 for LLM Applications. Num chatbot cloud, uma injeção bem-sucedida pode manipular a saída, expor contexto acessível ou contornar controlos de política.
Num modelo local, o impacto pode ser maior. Se o modelo tem acesso ao sistema de ficheiros, ao navegador, à execução de comandos ou a ferramentas de rede, o ataque passa de "o que pode o modelo dizer?" para "o que pode o modelo fazer?".
O acesso a ferramentas transforma o modelo num operador
O acesso a ferramentas é a linha que importa. Ler um ficheiro, enviar um pedido HTTP, clicar num navegador ou executar um comando transforma o modelo de gerador de texto em operador.
Uma instrução injetada não precisa de explorar diretamente o sistema operativo. Só precisa de alcançar uma interface de modelo confiável que já tem permissão para agir.
Os materiais Mythos Preview da Anthropic mostram a promessa defensiva e o risco. O Project Glasswing foi criado para usar raciocínio de classe Mythos para encontrar e corrigir vulnerabilidades graves. Ao mesmo tempo, a Anthropic observou que melhores capacidades para corrigir vulnerabilidades também implicam melhores capacidades para as explorar. A cobertura sobre testes do Mythos descreveu encadeamento autónomo de exploits em condições controladas, incluindo trabalho de escape de navegador e sandbox.
Isto não significa que cada modelo local seja uma plataforma de exploits. Significa que os limites de permissões importam mais à medida que a capacidade do modelo aumenta.
Como a telemetria de LLMs locais ainda pode expor dados sensíveis
A inferência no dispositivo é muitas vezes apresentada como uma vantagem de privacidade. O prompt, ficheiro ou documento bruto não precisa de viajar para um endpoint de modelo cloud. Para equipas de saúde, jurídico, finanças e engenharia empresarial, isso é um benefício real.
Mas local não significa silencioso.
Telemetria, logs de diagnóstico, métricas de desempenho do modelo, verificações de atualização, relatórios de falha e metadados de integração ainda podem sair do dispositivo. Estes fluxos são muitas vezes tratados como dados operacionais, não como dados sensíveis.
A sombra da inferência local
Um modelo que lê documentos privados ou repositórios de código pode produzir vestígios sensíveis mesmo quando os prompts brutos ficam em local. Mensagens de erro podem conter fragmentos. Padrões de uso podem revelar atividade. Payloads de diagnóstico podem incluir nomes de ficheiros, estado de extensões, categorias de prompts ou dados de routing do modelo.
Ferramentas de inferência local já foram analisadas por causa de telemetria de uso e padrões de privacidade. Para equipas reguladas, a telemetria precisa de classificação, controlos de retenção e um caminho de auditoria. Não pode ser tratada como ruído inofensivo.
A vantagem de privacidade continua real
A inferência no dispositivo resolve um problema genuíno. Dados sensíveis não precisam de ser enviados para uma API de inferência de terceiros em cada tarefa. Isso reduz exposição a políticas de retenção cloud, compromisso do fornecedor, roubo de credenciais de API e interceção de tráfego do modelo.
Para produtos de segurança, isto cria uma opção de desenho poderosa. Um modelo local pode inspecionar código, scripts, atividade do navegador e comportamento endpoint sem enviar cada artefacto a um fornecedor.
O modelo de privacidade é forte quando a implementação é disciplinada. Falha quando os downloads são silenciosos, as integrações instalam sem intenção clara do utilizador, o âmbito da telemetria é vago ou endpoints locais ficam acessíveis a partir de conteúdo de navegador não confiável.
O que a segurança endpoint com LLM consegue fazer
A inferência no dispositivo também abre um caminho defensivo que ferramentas endpoint tradicionais têm dificuldade em igualar. Sistemas por assinatura detetam padrões conhecidos. Heurísticas assinalam características suspeitas. Ambos podem falhar contra ataques novos, ofuscados ou de várias etapas.
Um modelo local que compreende código pode raciocinar sobre intenção. Pode inspecionar um script e perguntar o que o script tenta fazer, não apenas se corresponde a um indicador conhecido.
| Capacidade | AV/EDR tradicional | Segurança endpoint com LLM |
|---|---|---|
| Deteção de malware novo | Dependente de assinaturas | Compreensão semântica de código |
| Análise de scripts ofuscados | Heurísticas limitadas | Raciocínio ao nível da intenção |
| Cadeias de ataque de várias etapas | Análise por evento | Análise ao nível da sequência |
| Descoberta de zero-days | Sobretudo reativa | Raciocínio proativo sobre comportamento |
| Gestão de falsos positivos | Ajuste de regras | Triagem com contexto |
Esta é a versão positiva da mesma arquitetura. Um modelo de segurança local pode inspecionar extensões antes de executarem, analisar scripts de terceiros durante o runtime e sinalizar comportamento compatível com roubo de credenciais ou exfiltração de dados.
A diferença entre um agente defensivo e uma ferramenta de extração está na fronteira de confiança em torno de entradas, ferramentas e saídas.
Controlos que as equipas de segurança devem exigir
A inferência no dispositivo precisa de um modelo de segurança antes de se tornar infraestrutura de fundo.
- Permissões explícitas. Modelos locais não devem ter acesso predefinido a ficheiros, área de transferência, conteúdo do navegador ou estado de processos. As permissões devem ser visíveis, granulares e revogáveis.
- Controlos fortes na interface do modelo. Trate cada entrada do modelo como potencialmente adversarial. Defesas contra prompt injection pertencem à interface e à camada de ferramentas, não apenas ao prompt do modelo.
- Limites de telemetria. Mantenha telemetria mínima, documentada e auditável. Não permita que payloads de diagnóstico transportem dados de utilizador, conteúdo de ficheiros ou contexto local sensível.
- Isolamento de rede. Endpoints locais do modelo não devem ser acessíveis por pedidos arbitrários do navegador. O endpoint local não é uma API pública.
- Visibilidade de scripts no navegador. Monitorize scripts de terceiros, extensões e conteúdo injetado que possam interagir com ferramentas locais de IA. Se não consegue confiar no runtime do navegador, não consegue expor modelos locais privilegiados com segurança.
Como a cside se encaixa
A cside monitoriza o runtime do navegador: os scripts que carregam, o código que executa, os domínios que contactam e o comportamento que muda depois do deployment. Isto importa porque o navegador é um dos locais mais prováveis onde ferramentas locais de IA encontram entradas não confiáveis.
Para equipas que implementam ou avaliam IA no dispositivo, cside client-side security ajuda a responder à pergunta operacional: o que está realmente a acontecer no navegador antes de chegar a um modelo local privilegiado, checkout, formulário de login ou sessão sensível de utilizador?
A inferência no dispositivo vai melhorar ferramentas de segurança. Também vai criar novas rotas de ataque. O resultado depende de as equipas criarem limites de permissões e visibilidade de runtime antes de modelos locais se tornarem mais uma dependência invisível.
