Uma técnica associada à segurança de agentes de IA apareceu em outro lugar: uma campanha de phishing usou caracteres Unicode que não aparecem na tela para quebrar palavras dentro do código da mensagem. Para a pessoa, o texto continuava legível. Para alguns mecanismos de análise, a sequência recebida já não era a mesma.
A descoberta foi publicada pela Microsoft Security Research em 3 de setembro de 2026. O ponto central não é que a campanha tenha controlado um assistente de IA. Nas amostras examinadas, os caracteres invisíveis foram usados como separadores dentro de palavras ligadas a ofertas financeiras, numa tentativa de atrapalhar filtros de e-mail e modelos de classificação. A mesma propriedade técnica que pode esconder instruções de um modelo foi reaproveitada para um golpe conhecido.
Isso exige duas cautelas. A primeira é não chamar todo caractere invisível de ataque bem-sucedido. A segunda é não transformar um endereço IP, uma plataforma legítima de marketing ou uma única faixa Unicode em veredito automático. O relato da Microsoft mostra por que normalização, contexto e camadas independentes de proteção importam mais do que uma regra isolada.
O que a Microsoft publicou
O relatório da Microsoft Security Research descreve uma busca criada para localizar conteúdo oculto em e-mails que poderia atingir sistemas de IA. Ao ajustar essa busca, os pesquisadores encontraram uma campanha de phishing com tema financeiro que usava caracteres do bloco Unicode Tags, entre U+E0000 e U+E007F.
Em vez de codificar uma instrução secreta completa, as mensagens observadas inseriam um caractere invisível, especialmente U+E0020, no meio de termos que filtros poderiam considerar relevantes. Visualmente, uma palavra como funding continuava parecendo inteira ao destinatário. No fluxo técnico, porém, havia um ponto de código extra entre as letras.
A distinção é importante: o mecanismo veio do repertório discutido em prompt injection, mas o objetivo observado era evasão de filtros de phishing. A Microsoft chama o fenômeno de uma passagem entre domínios de segurança, não de uma invasão comandada por um modelo.
Quando isso aconteceu
A pesquisa foi publicada em 3 de setembro de 2026. A telemetria apresentada cobre uma fase anterior da atividade. Segundo a Microsoft, a assinatura ajustada teve um salto em 9 de fevereiro de 2026 e permaneceu elevada em dias úteis por cerca de três meses. O uso intenso da técnica caiu depois de 15 de maio, com atividade residual até meados de junho.
Essas datas delimitam o período em que a técnica específica apareceu na telemetria da Microsoft. Elas não provam o começo ou o fim de toda a campanha. O próprio relatório afirma que a operação mais ampla já existia antes de adotar os caracteres de tag e continuou depois que esse padrão perdeu volume.
Portanto, esta é uma notícia sobre uma análise publicada agora, baseada em uma janela observada. Não é um alerta de que todos os e-mails atuais contenham o mesmo marcador nem a confirmação de que uma única infraestrutura continua ativa hoje.
O que é ASCII smuggling neste contexto
O nome pode confundir. Os caracteres explorados não pertencem ao ASCII básico. Eles fazem parte do bloco suplementar Tags do Unicode e representam componentes relacionados a símbolos imprimíveis. O quadro oficial do Unicode 17.0 lista o intervalo E0000 a E007F, incluindo U+E0020 como Tag Space e componentes equivalentes a letras, números e sinais.
Esses pontos de código normalmente não aparecem como glifos comuns. A FAQ do Unicode sobre tags de idioma explica que se trata de caracteres de formatação invisíveis e que parte deles também participa de sequências específicas de emoji. Esse uso legítimo é um dos motivos pelos quais detectar o intervalo inteiro sem contexto produz falsos positivos.
Na pesquisa de segurança de IA, a expressão ASCII smuggling passou a descrever a conversão de texto legível para esses componentes invisíveis. Um humano vê pouco ou nada, enquanto um programa que conserva o texto bruto ainda recebe os pontos de código. Na campanha relatada, não houve uma mensagem secreta completa. Houve inserção de um separador invisível no meio de palavras.
O que a campanha fez de diferente
Quebrar palavras com caracteres invisíveis não é novidade em spam. Espaços de largura zero, hífens suaves, caracteres parecidos visualmente e outras variações já foram usados para fugir de correspondências literais. O elemento novo relatado pela Microsoft é a escolha do bloco Tags, que ganhou visibilidade recente por causa de estudos de prompt injection, combinada com uma escala elevada e uma operação disciplinada em dias úteis.
As mensagens promoviam ofertas financeiras e linhas de crédito. Os domínios visíveis ao destinatário combinavam um vocabulário recorrente de termos financeiros. O envio passava por infraestrutura de uma plataforma legítima de marketing por e-mail. Isso não torna a plataforma, seus domínios compartilhados ou toda a faixa de rede maliciosos. O relatório trata esses elementos como contexto de agrupamento, não como indicadores suficientes para bloqueio.
Também não é correto dizer que o caractere invisível por si só entregava a fraude. A investigação reuniu conteúdo, padrão de remetentes, formato do envelope, links de rastreamento, origem de envio e ritmo temporal. É a combinação que permitiu descrever aquela fase com maior confiança.
Escala observada e limites da telemetria
Os números são grandes, mas precisam permanecer atribuídos. Na telemetria do Microsoft Defender for Office 365, a assinatura registrou cerca de 21 mil mensagens em 8 de fevereiro e mais de 1,3 milhão no dia seguinte. Em 11 de fevereiro, o total passou de 2,3 milhões. A Microsoft relata volumes de 1 milhão a 2,37 milhões em dias úteis durante o período mais intenso.
Aproximadamente 96% do volume sinalizado estava associado ao agrupamento de remetentes com tema financeiro descrito no relatório. Isso não equivale a 96% de todo o phishing global, nem mede todas as caixas de e-mail. É uma proporção dentro dos eventos encontrados pela assinatura e pela telemetria específica do fornecedor.
Outro limite é temporal. A técnica caiu de forma acentuada em maio, enquanto a campanha mais ampla mudou de comportamento. Regras construídas apenas para a fotografia de fevereiro podem perder utilidade à medida que remetentes, infraestrutura e conteúdo se transformam.
Por que um texto visualmente igual pode ser processado de outro jeito
Um filtro simples pode procurar uma palavra exata antes de decidir se ela merece análise adicional. Ao inserir U+E0020 no meio da sequência, o texto bruto deixa de conter aquela palavra de forma contínua. Um tokenizador também pode dividir o termo em pedaços diferentes, produzir um token raro ou tratar o caractere como desconhecido.
O efeito não é universal. Um pipeline que normaliza ou remove caracteres não renderizados antes de classificar o conteúdo pode reconstruir a palavra esperada. Outro sistema pode usar OCR sobre uma representação visual da mensagem. Um terceiro pode ignorar o conteúdo e detectar o golpe pela reputação do remetente, pelo domínio, pelo endereço de origem, pela autenticação ou pelo destino dos links.
A consequência prática é que o que a pessoa vê, o que o parser conserva e o que o modelo recebe precisam ser tratados como representações distintas. Esse mesmo princípio vale para automações que resumem e-mails com IA. A documentação do Defender sobre prompt injection inclui texto oculto, conteúdo fora da tela, segmentos codificados e Unicode incomum entre os formatos que exigem inspeção.
O sinal ajuda o atacante e também o defensor
Um caractere invisível pode enfraquecer uma comparação literal, mas também pode ser raro o suficiente para virar um bom sinal de anomalia. A pesquisa descreve exatamente essa inversão: a tentativa de parecer normal para um classificador tornou a mensagem incomum para uma busca que conhecia o intervalo Unicode.
O desafio é preservar os casos legítimos. Algumas bandeiras de subdivisões, como Inglaterra, Escócia e País de Gales, usam sequências com caracteres de tag. Uma regra ingênua que dispara para qualquer ponto de código do intervalo confundiria essas mensagens com abuso. A equipe da Microsoft precisou excluir usos válidos e separar artefatos gerados por gateways e pesquisadores de segurança.
Isso favorece uma regra em duas etapas: registrar e normalizar o conteúdo para análise, depois combinar o sinal com remetente, autenticação, URLs, volume e comportamento. Bloquear tudo antes de entender a representação pode destruir evidência e atingir tráfego legítimo.
A maioria das mensagens não passou por causa de uma única regra
Segundo a Microsoft, mais de 99% das mensagens observadas foram sinalizadas por camadas que não dependiam de reconhecer diretamente os caracteres de tag. Entraram nessa defesa reputação de remetente, IP, URL e domínio, classificação por aprendizado de máquina, detecção de imitação de marca, verificações de autenticação e análise visual com OCR.
Esse dado impede duas conclusões apressadas. A campanha não demonstra um desvio geral do Defender. Também não demonstra que procurar U+E0020 seja inútil. A busca específica ajudou a descobrir e explicar a técnica, enquanto outras camadas carregaram a maior parte da proteção operacional.
A documentação do Defender for Office 365 organiza autenticação, políticas, investigação e resposta como partes distintas. O caso reforça a lógica de defesa em profundidade: quando uma representação engana uma análise de conteúdo, identidade, reputação e comportamento ainda podem interromper a mensagem.
O que equipes podem verificar agora
O primeiro teste é descobrir como o pipeline trata caracteres de formatação antes de aplicar regras, regex, tokenização e modelos. Faça isso em laboratório, com mensagens controladas e sem enviar conteúdo suspeito a caixas de produção. Compare a forma recebida, a forma exibida, a forma normalizada e a entrada efetiva do classificador.
O segundo é confirmar se a investigação preserva o texto bruto. Se o processo remover os caracteres antes do registro, a equipe talvez enxergue a palavra limpa, mas perca o indicador que explica a evasão. A orientação deve equilibrar normalização para detecção e retenção segura de evidência para análise.
O terceiro é revisar automações que entregam e-mails a assistentes de IA. Limite permissões, trate a mensagem como conteúdo não confiável e mantenha revisão humana antes de responder, encaminhar, abrir links ou executar ações. Nosso guia sobre triagem de e-mails com IA propõe exatamente esse desenho: classificar e rascunhar sem transformar a caixa de entrada em autorização automática.
Por fim, registre testes e exceções. Se um emoji legítimo aciona a regra, isso precisa virar caso de teste. Se um gateway reescreve a mensagem, documente em qual etapa. O objetivo não é apenas produzir um alerta, mas conseguir explicar por que ele surgiu e qual controle deve responder.
O que não deve virar bloqueio cego
O intervalo U+E0000 a U+E007F não deve ser tratado isoladamente como prova de phishing. A presença pode ser suspeita fora de sequências conhecidas, mas contexto continua necessário. Do mesmo modo, os domínios de rastreamento e a faixa de rede citados no relatório pertencem a infraestrutura compartilhada por clientes legítimos.
Listas de bloqueio copiadas sem escopo podem interromper newsletters e campanhas autorizadas. Indicadores de uma operação servem para busca e correlação, não para condenar todos os recursos do mesmo fornecedor. O registro T1566 do MITRE ATT&CK ajuda a enquadrar phishing como técnica de acesso inicial, mas não substitui validação local do evento.
Também seria errado inserir esses caracteres em mensagens reais apenas para ver se passam. Testes precisam de autorização, ambiente controlado, destinatários combinados e critérios de parada. Em produção, a prioridade é observar os controles existentes e usar amostras sintéticas que não contenham links ou ofertas convincentes.
Fato, interpretação e perguntas em aberto
Fato publicado pela Microsoft: a equipe encontrou caracteres do bloco Tags inseridos em palavras de uma campanha financeira, mediu um salto em fevereiro, acompanhou a fase por cerca de três meses e observou que a maioria das mensagens foi barrada por outras camadas.
Interpretação editorial: o caso mostra que técnicas estudadas para proteger agentes de IA podem reaparecer em sistemas tradicionais. A fronteira entre segurança de IA, e-mail e identidade é operacional, não uma separação rígida. A busca criada para um risco ajudou a iluminar outro.
Perguntas em aberto: o relatório não mede todos os provedores, não informa quantas mensagens chegaram a usuários finais e não prova que o bloco Unicode foi decisivo para a taxa de entrega. Também não estabelece se o operador escolheu a técnica por influência direta da literatura de IA ou apenas adotou uma ferramenta disponível.
Por que isso ainda importa
Empresas estão ligando caixas de entrada a classificadores, copilotos e agentes. Isso amplia o número de componentes que interpretam uma mensagem. Um conteúdo pode ser inofensivo na tela, estranho para um tokenizer, perigoso para uma automação com permissão ampla e, ao mesmo tempo, fácil de reconhecer por reputação de domínio.
A resposta mais útil não é buscar um filtro perfeito. É controlar a cadeia: normalizar antes de comparar, preservar o original para investigação, correlacionar sinais, limitar o que a IA pode fazer e exigir aprovação humana para ações externas. A abordagem também combina com a prática de minimizar e mascarar logs antes de pedir diagnóstico a uma IA, mantendo apenas a evidência necessária e evitando exposição indevida.
O episódio é um lembrete sóbrio. Caracteres invisíveis não tornam um ataque invisível para todas as defesas. Eles apenas exploram diferenças entre representações. Equipes que conhecem essas diferenças conseguem transformar o mesmo detalhe em sinal, teste e controle.
Fontes primárias
- Microsoft Security Research: ASCII smuggling crosses over from AI prompt injection to phishing evasion, publicado em 3 de setembro de 2026.
- Microsoft Learn: proteção contra prompt injection no Defender for Office 365, documentação atualizada em 6 de agosto de 2026.
- Unicode 17.0: quadro oficial do bloco Tags.
- Unicode Consortium: FAQ sobre caracteres de tag e usos legítimos.
- MITRE ATT&CK: técnica T1566, Phishing.
