Detecção de bots

A detecção de bots da TRACIO identifica navegadores automatizados, ferramentas headless e ataques com scripts usando uma arquitetura de duas camadas: coleta no cliente, dentro do agente de navegador, e análise no servidor. Ela cobre os frameworks de automação mais comuns, os navegadores headless, os agentes de navegação de IA e os navegadores anti-detecção com quase zero falsos positivos, ao mesmo tempo que coloca automaticamente em allowlist os rastreadores legítimos de mecanismos de busca.

O que a TRACIO detecta

• Frameworks de automação — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS e ferramentas semelhantes.
• Navegadores headless — Chrome headless e runtimes relacionados.
• Agentes de navegação de IA — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern e runtimes de agente semelhantes.
• Navegadores anti-detecção — builds de navegador cujo propósito é falsificar ou rotacionar a impressão digital.
• Rastreadores verificados — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo e outros, verificados de modo que um user-agent falsificado não passe.

Como o veredito é produzido

O agente de navegador executa um amplo conjunto de verificações e reporta os resultados. No servidor, esses resultados são ponderados em uma pontuação de bot, e a pontuação é mapeada para um veredito. Um pequeno número de indicadores inequívocos é decisivo por si só e força um veredito bot, independentemente do restante.

Quais verificações são executadas, como são ponderadas e onde ficam os limiares não são publicados — em nenhum plano. Documentá-los diria aos operadores de bots exatamente o que mudar para passar pela proteção. O que você recebe, em vez disso, é o veredito, um rótulo de tipo de bot e — no Business e acima — códigos de motivo que nomeiam a classe de observação por trás da decisão.

Formato do resultado

Toda identificação carrega um veredito de bot. Ele chega até você como bot.result no payload do webhook e como result.bot no SDK de cliente.

Valores do veredito

Isso é mapeado para o campo de negócio decision.action (real, fake ou suspicious) usado em todo o painel e no payload do webhook.

bot.score acompanha o veredito. Na versão 2 do payload do webhook ele é um decimal 0..100 — o mesmo número que o painel mostra para aquela visita. (No esquema congelado da versão 1 ele é uma fração 0..1; veja Webhooks.)

Tipos de bot

bot.type está presente quando o resultado é bot. Ele é ou o nome de um bot ou runtime reconhecido, ou uma família, quando nomear a verificação específica revelaria o funcionamento interno do detector:

A lista é fechada por design: uma verificação adicionada ao detector amanhã aparece como other em vez de vazar seu nome interno. Trate bot.type como um rótulo para ramificar decisões, não como um enum exaustivo para validar — novos runtimes nomeados são acrescentados ao longo do tempo.

Códigos de motivo (Business e acima)

Nos planos Business e Enterprise, o payload do webhook carrega um array reasons — no máximo oito entradas, ordenadas por importância. Um código nomeia a classe de observação, nunca a verificação por trás dela:

severity é high, medium ou low, e representa a parcela do veredito que essa classe responde nesta visita — não uma propriedade fixa do código. O mesmo código pode chegar como high em uma visita e low em outra, então não o guarde em cache como constante.

privacy_hardening merece cuidado especial: ele dispara tanto para visitantes comuns preocupados com privacidade quanto para tentativas de evasão. Pondere-o junto com o restante, em vez de agir apenas com base nele.

virtual_environment vem da detecção de emuladores. Na web não existe um veredito separado de "rodando sob um hipervisor": as pistas que um navegador consegue ver — um renderizador de software genérico, uma contagem de núcleos incomumente baixa — aparecem com a mesma frequência em máquinas comuns sem driver de GPU e em sessões de área de trabalho remota, então não as transformamos em um veredito que você teria de questionar depois.

Disponibilidade por plano

A pontuação anti-detecção ainda está sendo calibrada. bot.antidetectScore é reportado para que você possa observá-lo e ajustar sua própria política — trate-o como uma entrada da sua decisão de risco, e não como um motivo isolado para bloquear.

Verificações exclusivas de mobile não são eficazes na web. A detecção de root, jailbreak, apps clonados/duplicados e Frida depende de sinais nativos de mobile que um navegador não consegue coletar. A TRACIO disponibiliza apenas SDKs de navegador, então apoie-se nos vereditos de automação, headless, agente de IA, anti-detecção, emulador e comportamental, que estão plenamente ativos na web.

Rastreadores verificados

Bots bons conhecidos são reconhecidos pelo user-agent e então verificados contra o IP de conexão — uma consulta de DNS reverso sobre o IP, uma verificação de que o hostname resultante pertence ao domínio do operador e uma consulta direta confirmando que ele resolve de volta para o mesmo IP. Esse é o procedimento de verificação que os próprios operadores dos rastreadores publicam.

Um rastreador verificado resolve para human. Uma requisição que afirma ser o Googlebot enquanto seu IP comprovadamente pertence a outra pessoa é classificada como bot — uma consulta apenas ausente ou que expirou não é tratada como prova de falsificação.

Análise comportamental

A dinâmica de interação — movimento do ponteiro, cadência do teclado, rolagem — alimenta o veredito como evidência de se há um humano presente, não de qual humano é. No Business e acima, o agregado é entregue no bloco behavior do webhook:

{
  "behavior": {
    "score": 87,
    "verdict": "human",
    "confidence": 0.92
  }
}

score vai de 0..100 (quanto maior, mais humano), verdict é human, uncertain ou bot, e confidence (0..1) diz sobre quanta evidência o veredito se apoia — uma visita curta com dois movimentos de ponteiro pontua baixo aqui mesmo quando o veredito parece decisivo.

O bloco está presente apenas quando a pontuação comportamental de fato foi executada naquela visita. Um bloco ausente significa "sem dados", nunca "nada suspeito" — não leia a ausência dele como um sinal limpo.

Exemplos de integração

Bloqueando bots no login (cliente)

O SDK de cliente expõe um booleano de conveniência, result.bot.detected, além de um confidence em uma escala 0..100:

const result = await tracio.getResult()

if (result.bot.detected) {
  console.warn(`Bot detected (confidence ${result.bot.confidence})`)
  showCaptcha()
  return
}

await login(credentials)

Verificação de bot no servidor

No seu servidor, atue sobre a entrega do webhook. O veredito de bot vive no objeto bot — bot.result e bot.type:

// `event` is the webhook delivery body (/docs/webhooks)
app.post("/webhook/tracio", async (req, res) => {
  const event = req.body

  if (event.bot?.result === "bot") {
    await db.blockedRequests.insert({
      visitorId: event.visitorId,
      botType: event.bot.type,
      ip: event.ip,
      timestamp: new Date(),
    })
  }

  res.status(200).send("OK")
})

Valores zero e vazios são omitidos do payload, então leia bot.type de forma defensiva em vez de exigi-lo no seu esquema.

Tratamento de falsos positivos

A detecção de bots da TRACIO é projetada para quase zero falsos positivos, mas existem casos limite:

Se você observar falsos positivos, revise bot.type (e reasons no Business e acima) para entender qual classe de observação disparou e então ajuste sua política. Veja Solução de problemas para as causas mais comuns.