NotíciasA mudança da Microsoft pode afetar agentes personalizados do Teams hospedados em ambientes que validam fingerprints TLS. No fim de outubro, o Agent Communications Service começará a aceitar TLS 1.3 em endpoints da família https://smba.*. Para a maioria das equipes, nada exige alteração. O ponto de atenção são regras de rede que esperam um fingerprint JA3 ou JA4 específico: se a negociação mudar, uma allowlist pode rejeitar conexões legítimas e interromper o agente.
O que muda e para quem
A Microsoft anunciou em 17 de setembro que adicionará suporte a TLS 1.3 ao Agent Communications Service no fim de outubro. A família de endpoints atende agentes do Teams e agentes de mecanismo personalizado do Microsoft 365. A atualização não remove TLS 1.2: a Microsoft diz que ele continuará aceito, e runtimes que já suportam TLS 1.3 passarão a negociar essa versão automaticamente quando aplicável. A especificação do TLS 1.3 publicada pela IETF descreve uma negociação que não é idêntica à de versões anteriores.
Isso não significa que todo aplicativo do Teams vá parar de funcionar. O risco está concentrado em organizações que executam um agente customizado e hospedam seu runtime atrás de controles que validam a impressão digital do cliente TLS, incluindo JA3 e JA4. Firewalls, proxies, gateways ou regras internas de detecção podem usar esses sinais para identificar conexões conhecidas e alertar ou bloquear quando elas mudam.
A documentação da Microsoft recomenda revisar esses controles e considerar uma flexibilização temporária das regras que verificam fingerprints para conexões do runtime do agente. Depois que TLS 1.3 estiver habilitado, a equipe pode observar o novo fingerprint e atualizar as regras. O guia de agentes de mecanismo personalizado do Microsoft 365 ajuda a identificar se a solução usa esse tipo de runtime próprio, em vez de um agente declarativo hospedado pela Microsoft.
Por que o fingerprint pode mudar
JA3 e JA4 resumem características apresentadas durante o início de uma conexão TLS, como versões, cifras, extensões e preferências de protocolo. São sinais úteis para reconhecer padrões de clientes e apoiar monitoramento, mas não são uma identidade permanente do software. A própria documentação da Cloudflare sobre JA3 e JA4 descreve esses valores como identificadores derivados da forma como o cliente inicia a conexão.
Quando uma biblioteca passa a oferecer TLS 1.3 ou negocia um conjunto diferente de extensões, o fingerprint observado pode mudar, mesmo que o agente, o servidor e a intenção da conexão continuem legítimos. Uma regra que trata o valor anterior como requisito fixo pode confundir uma atualização normal de protocolo com uma conexão desconhecida. O efeito prático tende a aparecer como alerta de rede, falha intermitente ou bloqueio do agente — não como sinal automático de invasão.
Um roteiro curto para revisar a implantação
Comece pelo inventário. Confirme se a empresa usa agentes customizados do Teams ou do Microsoft 365 e identifique onde o runtime é executado. Depois procure controles que inspecionam JA3/JA4 ou fingerprints TLS em conexões de saída para smba.*. Se não houver agente customizado, ou se nenhuma camada validar esse sinal para esses endpoints, a mudança provavelmente não exige ação local.
Se a regra existir, planeje uma janela de observação próxima à habilitação anunciada pela Microsoft. Registre o comportamento atual e alinhe com a equipe de rede uma exceção temporária e estreita, limitada às conexões relevantes e com prazo para revisão. Evite remover uma política inteira ou desabilitar controles de tráfego que não participem desse caminho.
Após a alteração do serviço, observe os logs de conexão e capture o fingerprint apresentado pelo runtime. Compare o novo valor com o esperado, confirme que o destino continua sendo a família de endpoints documentada e atualize apenas a regra necessária. Por fim, reative a validação e acompanhe o agente com alertas e testes funcionais. O objetivo é manter a inspeção de segurança com uma allowlist atualizada, não deixar a conexão permanentemente sem controle.
Equipes que estão planejando integrações podem também revisar nosso guia sobre o que uma API permite integrar e os critérios para escolher uma equipe de desenvolvimento: uma mudança de protocolo é um bom lembrete para documentar dependências de runtime e responsabilidades operacionais desde o desenho da solução.
O que a documentação ainda não especifica
A nota pública informa que o suporte chegará no fim de outubro de 2026, mas não fixa ali um dia ou uma hora de ativação. Também não fornece fingerprints novos, porque o valor observado dependerá do runtime, das bibliotecas e da infraestrutura de cada implantação. Portanto, não é possível recomendar uma string única para adicionar a todas as allowlists.
A atualização reforça TLS 1.3 sem retirar a compatibilidade com TLS 1.2, segundo a Microsoft. O impacto real depende das regras de rede e deve ser confirmado nos logs do ambiente. Se houver dúvida sobre um bloqueio, compare o horário da falha com a negociação TLS e valide com as equipes responsáveis pelo runtime e pela segurança antes de ampliar uma exceção.
