Quando o ChatGPT passa a enviar mensagens, SMS deixa de ser fora de banda: um playbook de segurança para CTOs

Seu produto ainda trata SMS e e‑mail como canais de controle “fora de banda”. Essa suposição acabou de morrer. O ChatGPT agora pode enviar mensagens pelo Apple Messages. Assistentes já leem notificações, varrem caixas de entrada e seguem instruções entre apps. Se um agente pode ver e enviar a mensagem, não é fora de banda — é automação em banda, com uma nova superfície de ataque.

Se você estava esperando um movimento de um grande fornecedor para descontinuar 2FA por SMS e aprovações via e‑mail, aqui está. Neste post eu trago um framework prático de decisão para inventariar onde você depende de “fora de banda”, avaliar sua exposição agora que assistentes podem enviar mensagens e entregar um modelo mais seguro de autenticação e autorização em um trimestre.

O que mudou: SMS e e‑mail agora são automatizáveis por padrão

Dois sinais relevantes chegaram recentemente:

• O ChatGPT ganhou integração com o Apple Messages. Isso é acesso em nível de SO, em escala mainstream, a um canal no qual a maioria dos apps de consumo ainda confia para OTPs e aprovações.
• Assistentes podem ser induzidos a exfiltrar dados mesmo quando filtros “deveriam” bloqueá‑los — inclusive via prompt injection ofuscada ou criptografada. Se um modelo segue instruções maliciosas, seu código supostamente fora de banda vira só mais um token para copiar e colar.

Ao combinar isso com anos de deriva de plataforma — prévias de OTP na tela de bloqueio, resumidores de notificações, “respostas inteligentes” de e‑mail, sincronização entre dispositivos — a fronteira de segurança que você achava existir em torno de SMS e e‑mail nunca se sustentou. Agora está completamente porosa.

Atualização do modelo de ameaça: do segundo fator humano para um duto roteirizável

Aqui está como seus controles atuais se degradam na presença de assistentes em nível de SO que podem ler e enviar mensagens:

• OTPs por SMS: Agentes podem ler prévias de notificação, mensagens completas e, em alguns casos, responder sem intervenção do usuário. Um assistente comprometido = OTP coletada.
• Links mágicos por e‑mail: Se um assistente gerencia sua caixa de entrada, “clicar no link” vira automação trivial. Heurísticas de bloqueio de clique não salvam você de automação de primeira parte.
• Retornos por telefone/URA: Com TTS e APIs de chamada, agentes podem fazer e navegar ligações. ID do chamador é falsificável; “verificação por voz” é teatro diante de vozes clonadas.
• Aprovações por push: Se o seu push é um simples “Aprovar/Negar”, um agente com acesso a notificações pode tocar em Aprovar mais rápido do que o usuário percebe.

Orientações de segurança já alertavam sobre isso. A NIST SP 800‑63B classifica SMS para OTP como restrito devido a SIM swap, interceptação e malware. E isso era antes de assistentes poderem retransmitir mensagens em seu nome. Hoje, SMS e e‑mail são apenas transporte de processo — e qualquer coisa que consiga dirigir esse transporte consegue dirigir seus controles.

Framework de decisão: mate as suposições de fora de banda em 4 etapas

1) Faça o inventário de onde você depende de “fora de banda”

Faça uma lista de duas colunas com dono de negócio e dono técnico. Você está procurando todo lugar onde um ator fora da sua sessão autenticada pode acionar uma mudança sensível de segurança:

• Autenticação: SMS OTP, e‑mail OTP, links mágicos por e‑mail, retornos por telefone, TOTP de app autenticador.
• Autorização: aprovações de pagamento, inclusão de beneficiário, rotação de chaves, mudanças de função, cadastro de dispositivo, confirmações de exportação de dados.
• Suporte/Recuperação: redefinições de senha via e‑mail ou SMS, desbloqueios de conta via chamado telefônico, re‑verificação de KYC via link enviado por e‑mail.

Para cada um, registre canal(is), caminho(s) de fallback e artefato mostrado ao usuário (OTP, link, botão de aprovação etc.). Espere encontrar de 12 a 30 fluxos distintos em um SaaS B2C típico; menos em B2B, porém com maior raio de impacto.

2) Classifique controle do canal e exposição a assistentes

Atribua uma pontuação a cada fluxo em três dimensões (Alto/Médio/Baixo):

• Visibilidade para assistentes: um assistente de SO mainstream pode ler por padrão? (OTP na tela de bloqueio, preview de e‑mail, integração com Messages, conteúdo da notificação.)
• Atuação por assistentes: um assistente consegue enviar/aprovar/responder nesse canal?
• Força da verificação do usuário: o usuário prova posse de uma chave privada em hardware seguro ou apenas responde a um desafio que qualquer app pode ver?

Se um fluxo tiver Alta visibilidade + Média/Alta atuação + Baixa força de verificação, trate‑o como comprometido. Qualquer argumento do tipo “mas exige o usuário tocar” ficou obsoleto quando um modelo pode tocar.

3) Escolha um substituto criptográfico, não outro canal

Troque a confiança no canal pela confiança na chave. Suas opções:

• WebAuthn (FIDO2) com chaves residentes: com suporte de hardware, resistente a phishing, funciona em desktop e mobile. Use credProtect e exija user verification (UV). Prefira autenticadores de plataforma vinculados ao dispositivo em vez de chaves roaming para fluxos de consumidor; permita chaves roaming para admins.
• Atestação vinculada ao app para aprovações: no mobile, use Apple App Attest e Android Play Integrity para atestar seu app; dentro do app, realize assinatura de transação com “o que você assina” em claro (valor, beneficiário, ação) exibido e vinculado à assinatura. Fora do navegador, use os elementos seguros fornecidos pelo SO (Secure Enclave/StrongBox) via APIs da plataforma.
• Push com desafio criptográfico por transação: se você precisar usar push, nunca envie um “Aprovar” cego. Envie um desafio assinado que inclua os campos críticos e exija uma asserção com suporte de hardware em resposta. Armazene e audite as asserções.

Não substitua SMS por e‑mail ou vice‑versa. Você não está combatendo a confiabilidade do canal. Está eliminando a confiança no canal por completo.

4) Elimine gradualmente fallbacks que reintroduzem a brecha

A maioria das violações acontece pelo caminho de menor resistência: “Não funcionou? Use SMS.” Elimine ou restrinja:

• Remova SMS como fallback onde você implantar WebAuthn. Se precisar manter para uma minoria, isole esses usuários em um tier de risco restrito, com limites de transação menores.
• Retire links mágicos por e‑mail para perfis admin e contas de alto valor. Force WebAuthn ou assinatura no app.
• Substitua recuperação por telefone por kits de recuperação de dispositivo verificados: códigos de recuperação únicos pré‑gerados e armazenados offline, ou credenciais FIDO secundárias cadastradas antecipadamente.

Mudanças de design que você precisa neste trimestre

Autenticação

• Faça do WebAuthn o primeiro fator padrão para novos cadastros. Pare de tratá‑lo como configuração de “usuário avançado”. Armazene apenas credenciais com verificação do usuário (UV = required). Teste passkeys sincronizadas entre dispositivos e ofereça opt‑out para perfis de alta garantia que exijam apenas chaves vinculadas ao dispositivo.
• Coloque barreiras no OTP legado com postura de dispositivo: se aparecer OTP (usuários existentes), exija sinais adicionais do dispositivo (App Attest/Play Integrity) e vinculação de sessão antes de aceitá‑lo.
• Bloqueie OTP em notificações: para apps móveis sob seu controle, suprima o conteúdo de OTP nas notificações. Não é uma correção, mas reduz coletas oportunistas.

Autorização (aprovações e step‑up)

• Assinatura de transação, não sim/não: exiba a ação exata (ex.: “Pagar US$ 4.200 para ACME LLC, US‑123456789, hoje”) e exija uma assinatura com suporte de hardware sobre esse payload. Armazene‑a. Deixe visível na trilha de auditoria.
• Alterações de papéis e permissões exigem WebAuthn ou assinatura no app. Nunca aprove via link enviado por e‑mail.
• Exportação de dados exige step‑up criptográfico e um token de curta duração, de uso único, vinculado à sessão e ao dispositivo.

Suporte e recuperação

• Kits de recuperação seguros para agentes: forneça 8–12 códigos de recuperação de uso único impressos no cadastro. Permita o cadastro de 2–3 credenciais FIDO secundárias. Desative totalmente a redefinição por SMS após configurar passkeys com sucesso.
• Sem aprovações por e‑mail/telefone: o suporte só pode iniciar um fluxo de recuperação no app, atestado. Se o usuário só tiver e‑mail, exija um período de resfriamento (24–72 horas) antes de reabilitar o acesso.
• Mudanças de alto risco exigem duas chaves diferentes (ex.: dois admins, ou admin + compliance), não dois canais.

“Mas os reguladores exigem fora de banda” — leia as letras miúdas

Muitos padrões citam “fora de banda” como mitigação. Poucos insistem que precise ser SMS ou e‑mail em 2026. O que auditores querem é verificação independente e evidência de violação:

• PCI DSS, FFIEC e SOX se importam que o aprovador seja, de fato, o aprovador — e que você possa provar isso depois. Hardware‑backed WebAuthn com UV, mais assinaturas específicas por transação e logs imutáveis, atende ao princípio melhor do que SMS jamais atendeu.
• NIST SP 800‑63B desestimula explicitamente SMS OTP como fator de alta garantia. Use isso para justificar seu plano de migração.

Se um regulador específico ainda equiparar “fora de banda” a “enviar um SMS”, documente por que esse canal agora é automatizável e proponha fora de banda criptográfico: um segundo dispositivo atestado de forma independente, com chave distinta, ou um segundo administrador com credencial separada.

Detecção e resposta: assuma que assistentes estão no circuito

Mesmo com controles criptográficos, você precisa detectar padrões de abuso compatíveis com mediação por assistente:

• Impressões consistentes com fluxos dirigidos por assistente: aprovações quase instantâneas repetidas após entrega de notificação; perfis idênticos de velocidade do cursor/gestos; cadência atípica 24/7.
• Assinaturas de egresso de agentes: pools de IP conhecidos de assistentes, impressões digitais de TLS ou padrões de referer. Não bloqueie em massa, mas pontue o risco e exija step‑up.
• Isca de payload criptografado: se o assistente do usuário for instruído a descriptografar ou encaminhar dados, você verá picos de comportamento de copiar e colar. Aplique rate limit a tentativas de OTP e reduza prévias na tela de bloqueio.

Construa gatilhos de alarme nos seus serviços de autenticação e aprovação: quando sinais suspeitos dispararem, rebaixe sessões e force uma verificação WebAuthn com UV antes de processar ações sensíveis.

Governança: sua trilha de auditoria deve registrar “o que” você assinou

Auditorias que dizem “Usuário aprovou às 10:03” não valem nada em disputas. Armazene:

• O payload canônico exato que o usuário viu (valor normalizado, moeda, ID da contraparte),
• O app/dispositivo atestado que o exibiu,
• A assinatura criptográfica sobre esse payload e o identificador da chave/ID da credencial,
• Quaisquer delegações ou contexto de dupla aprovação.

Coloque isso por trás de um log somente de gravação (WORM ou armazenamento somente de anexos) e torne a recuperação um recurso de produto de primeira classe para sua equipe de risco. Isso transforma pós‑mortems de sessões de culpa em triagem baseada em evidências.

Plano 30‑60‑90 dias

Dias 0–30: estancar a sangria

• Desative prévias de OTP na tela de bloqueio nos seus apps móveis; remova conteúdo de OTP das notificações.
• Entregue WebAuthn para todos os usuários como opção visível e recomendada; torne‑o obrigatório para funcionários e admins.
• Remova aprovações por link de e‑mail para ações de admin. Exija confirmação no app com WebAuthn.
• Instrumente comportamento “com cara de assistente” nos logs de autenticação; adicione gatilhos simples e revisão manual para eventos de alto valor.

Dias 31–60: substituir, não remendar

• Faça do WebAuthn o padrão no cadastro e em eventos de reautenticação. Ofereça um breve período de carência por SMS somente onde inevitável, com privilégios limitados.
• Implemente assinatura de transação no mobile e na web para pagamentos, exportação de dados, rotação de chaves e mudanças de papéis.
• Lance kits de recuperação e cadastro de credenciais secundárias. Remova redefinições por telefone para staff/admins.

Dias 61–90: cortar as amarras

• Remova OTP por SMS de mercados e perfis de alto risco. Onde for mandatado, isole em um domínio de política separado, com limites reduzidos e monitoramento reforçado.
• Ative chaves residentes com UV obrigatório e bloqueie credenciais sem UV para fluxos de consumidor.
• Finalize o armazenamento de auditoria para payloads assinados com propriedades WORM e recuperação self‑service para risco/compliance.

Trade‑offs que você deve assumir

• Atrito hoje para menos incidentes amanhã. O cadastro no WebAuthn adiciona um minuto ao onboarding. Isso é mais barato do que um único ATO habilitado pelo suporte.
• Passkeys vinculadas ao dispositivo vs. sincronizadas. Vinculadas ao dispositivo são mais fortes, mas aumentam risco de lock‑out. Para consumidores, permita passkeys sincronizadas com recuperação robusta; para admins, prefira vinculadas ao dispositivo.
• Deslocamento de custo no suporte. Você lidará mais com fluxos de kit de recuperação e chaves secundárias. Treine o suporte e exponha caminhos self‑service. O custo líquido de fraude ainda cai.
• Parceiros legados. Alguns fornecedores de fintech e identidade ainda empurram fluxos via SMS. Escale agora ou planeje uma saída. Seus usuários não devem herdar a postura de risco do seu fornecedor.

E no B2B? Seus admins são as joias da coroa

Mesmo que seu produto não seja voltado ao consumidor, seus admins podem aprovar mudanças de domínio de SSO, papéis via SCIM, escopos de tokens de API e exportar dados de clientes. Trate todas as aprovações de admin como eventos de assinatura, não cliques. Faça cumprir WebAuthn com UV‑required keys, duplo controle para mudanças irreversíveis e vinculação de sessão a dispositivos atestados.

Nota para Brazil/LatAm: não espere pelas operadoras

Se você atende a América Latina, já sabe que a entrega de SMS e a segurança do SIM variam por mercado. Antes isso era uma dor operacional; agora é um passivo de segurança. A boa notícia: WebAuthn funciona em iOS e Android em qualquer lugar, e chaves com suporte de hardware são onipresentes. Pods nearshore podem ajudar você a refatorar fluxos sem dor de fuso (6–8 horas de sobreposição com os US), mas a direção arquitetural é a mesma: criptografia acima de canais.

A nova regra

Se um assistente pode ver ou enviar, é em banda. Tudo bem — desde que o que sustenta sua segurança não seja o canal, e sim a chave. Leve seus controles para lá, prove o que foi assinado e você não se importará com quem está lendo a caixa de entrada.

Pontos‑chave

• Assistentes de SO podem ler e enviar mensagens e e‑mails. SMS/e‑mail não são mais fora de banda — trate‑os como em banda automatizável.
• Substitua confiança no canal por confiança na chave: WebAuthn com chaves residentes com UV obrigatório e assinatura explícita de transação.
• Mate fallbacks que reintroduzem risco (SMS, links por e‑mail, aprovações por telefone) ou isole‑os com limites rígidos e monitoramento.
• Armazene payloads assinados do “o que você aprovou” com propriedades WORM para auditorias com nível de evidência.
• Detecte comportamento parecido com assistente e exija step‑up criptográfico em fluxos suspeitos.
• Reguladores querem independência e garantia, não SMS especificamente. Aprovações criptográficas atendem melhor à intenção do que OOB legado.