A web não precisa de gatekeepers: a nova proposta de “Signed Agents” da Cloudflare

• A política de Signed Agents da Cloudflare usa a segurança como justificativa, mas na prática é uma tentativa fechada de transformar o acesso à web em algo sujeito a permissão
• Historicamente, a web cresceu graças à abertura e aos padrões, e tecnologias fechadas como Flash e Silverlight acabaram desaparecendo diante de padrões abertos como o HTML5
• No futuro, os principais usuários da web serão os agentes de IA, e para isso será necessário um sistema de autenticação distribuído e verificável, com autorização por unidade de tarefa
• O modelo correto é combinar delegação baseada em cadeia + prova por requisição, implementando autenticação confiável e controle de permissões granular
• Em vez de deixar uma empresa específica com a chave na mão, é preciso preservar uma web em que todos possam participar e inovar por meio de protocolos e padrões abertos

---

Crítica ao Signed Agents da Cloudflare

• A Cloudflare propôs um novo sistema de Signed Agents, mas isso é, na prática, um controle de acesso baseado em lista de permissões
• Deixar que uma empresa específica decida se um agente pode ou não ser registrado não passa de um sistema de aprovação por fornecedor, e não um protocolo de internet
• Isso entra em conflito com a natureza aberta da internet, e “preencher um formulário para obter permissão” não pode virar padrão

A web precisa continuar aberta

• A estratégia de “embrace and extend” da Microsoft nos anos 90 fracassou, e isso só foi possível porque a web manteve sua abertura
• Runtimes fechados como Flash e Silverlight acabaram sendo substituídos pelo HTML5, um padrão aberto
• A história sempre prova que padrões abertos impulsionam a inovação

A chegada da era dos agentes

• Os agentes de IA serão os principais usuários da web no futuro, realizando busca de informações, automação, pagamentos e negociação de contratos
• A fronteira entre ações humanas e ações de agentes ficará mais difusa, o que exigirá um sistema de autenticação baseado em delegação

Autenticação e autorização

• Autenticação: quem está agindo?
• Autorização: o que pode fazer?
• A Cloudflare confunde os dois conceitos e tenta resolver tudo com um “passaporte”, mas isso é fundamentalmente impossível
• A autenticação correta deve ser implementada por meio de cadeias de delegação e assinaturas por requisição, usando mecanismos distribuídos de verificação como a emissão de chaves públicas baseada em DNS

Gerenciamento de permissões

• Em softwares tradicionais, o modelo de escopos do OAuth funcionava bem graças ao escopo limitado
• Mas como os agentes são de uso geral, é necessária uma autorização com escopo por tarefa (Task-Scoped)
• Exemplo: a permissão para “pagar o jantar” e a permissão para “consultar o histórico de gastos dos últimos 3 meses” devem ter tokens diferentes, mesmo para o mesmo agente
• Para isso, podem ser usados tokens baseados em restrições como Macaroons e Biscuits, além de mecanismos de política como OPA/AWS Cedar

Protocolos em primeiro lugar, sem gatekeepers

• Autenticação, autorização e monetização devem acontecer sobre padrões abertos e interoperáveis, e não sob o controle de uma empresa específica
• Se poucas empresas passarem a decidir a validade dos agentes, a web logo se tornará um jardim murado (Walled Garden)
• Por isso, a proposta é disponibilizar em código aberto delegação baseada em cadeia, prova por requisição e autorização com escopo por tarefa, para que qualquer um possa implementar

Conclusão

• O futuro da web não depende de “quem controla o portão”, mas de protocolos que todos possam construir juntos e sobre os quais possam inovar

[GN⁺]

Comentários do Hacker News

• É frustrante que todo mundo sonhe com uma web completamente livre e aberta, mas na prática quase não exista forma de alguém com um blog pequeno ou algum conteúdo se proteger de bots de treinamento de IA; não parece realista acreditar que vão distinguir entre agents e bots de treinamento e respeitar de verdade o robots.txt; mesmo que respeitem o robots.txt, a ideia de comprar os dados indiretamente sob o nome de “licensed data” continua; a menos que você seja uma empresa como Reddit, X, Google ou Meta, com recursos jurídicos quase ilimitados, indivíduos não têm poder; também recomendo este vídeo, que é interessante

  • Parece contraditório querer ao mesmo tempo uma web livre e aberta para todos e também querer bloquear bots de treinamento de IA; se a web é aberta para todos, então os bots de treinamento de IA também deveriam poder acessar sem exceção

  • (Sobre o sonho da web aberta) o sonho de conteúdo aberto na internet é real; meu blog fica livremente acessível para qualquer um — humano ou máquina — e meu servidor também é hospedado por mim em casa, então não vejo necessidade de distinguir humanos de IA; se a preocupação é um site receber visitantes demais, na verdade o problema é o excesso de tráfego em si, seja humano ou IA; deixo apenas uma orientação mínima no robots.txt para evitar que bots entrem em loop e mantenho tudo aberto para crawling livre; o Amazonbot também visita meu site com frequência e é sempre bem-vindo

  • Acho que devemos desenvolver software livre para lutar contra software hostil; as big techs desenvolvem agents de IA hostis, e hackers competentes deveriam desenvolver anti-AI-agents para enfrentá-los; não concordo com esse derrotismo de “não temos poder”

  • Aponta a realidade de que, mesmo com tantos engenheiros de grandes empresas de tecnologia aqui no Hacker News, eles sempre fazem barulho sobre outros temas sem tratar de privacidade e governança de dados no próprio trabalho; se precisarem de um espelho para autorreflexão, eu topo comprar um

  • Não entendo por que sequer surge a pergunta sobre proteger blogs pequenos ou conteúdo de bots de treinamento de IA; se é difícil até gerar HTML básico e por isso é preciso usar frameworks pesados e complexos, a ponto de consumir CPU demais, esse é o verdadeiro problema; ou então, se a pessoa acha que seus textos online são um caminho para riqueza e fama como criador de conteúdo, aí até dá para entender a preocupação; fora isso, não vejo problema nenhum

• Na prática, acho que a “web” já deixou de ser aberta faz muito tempo; a maior parte da interação, publicação e circulação de informação acontece atrás de autenticação (login); as principais redes sociais, jornais etc. restringem ou bloqueiam acesso não autenticado; blogs representam só uma fração minúscula de toda a informação consumida pelo público em geral

  • Não concordo com a afirmação de que “a web não é mais aberta”; a web não precisa aumentar o número de gatekeepers e, se já existem muitos, o melhor seria reduzi-los

• Eu também não me importo com AI Agent em si; se há um usuário real por trás, tudo bem; mas tenho grande incômodo com Meta, Perplexity, OpenAI etc. rastreando meu site de forma agressiva; o crawling de IA consome mais recursos do que usuários reais ou até busca do Google; é realmente irritante ver núcleos de CPU presos atendendo crawling de IA

  • Comigo é a mesma coisa: tenho vários apps pessoais online e, no mês passado, um bot de IA puxou 1,6 TB de dados, então fui obrigado a ativar a proteção contra AI bots do Cloudflare; eram mais de 1,3 milhão de requisições por dia, sem parar, e não dava para aguentar

  • Em alguns dos meus sites de marketing, chegam de 200 a 300 requisições por segundo; o nível está fora de controle, inclusive gerando URLs aleatórias que nem existem

  • Fico curioso sobre quantos ciclos de CPU as empresas de IA estão consumindo por causa do web crawling; normalmente, ao falar do impacto ambiental da IA, só se conta treinamento ou inferência do serviço, mas também é preciso considerar a carga extra de crawling na web; para comparar direito, faria sentido medir contra o que aconteceria se usuários humanos realizassem a mesma ação diretamente; se o bot for projetado para gerar tráfego de forma mais eficiente — por exemplo, buscando só o necessário para a consulta e minimizando trackers, imagens e outros elementos acessórios — então a carga de CPU pode até ser menor do que a humanidade inteira visitando tudo diretamente pelo navegador

  • Também penso assim: se existe um usuário real por trás do AI agent e o acesso não é anormalmente excessivo, não ligo muito; (não fui eu quem quis o uso do meu site por AI agent, mas não me importa quem usa nem como usa); o que eu não gosto é de crawling excessivo; e, mais importante, alguém pode simplesmente baixar um arquivo com curl ou usar um navegador de texto como o Lynx; acho que esses cenários também precisam continuar sendo suportados

  • O Cloudflare distingue entre algum “agent tentado por um usuário” e crawling indiscriminado para coleta de dados de treinamento, permitindo uns agents e bloqueando outros; a maioria das requisições enviadas por Meta, Perplexity e OpenAI vem de recursos de busca na web acionados por prompts de usuários reais, e essas requisições não são usadas no treinamento do próximo modelo de LLM; o Cloudflare embaralha deliberadamente essa diferença e, oficialmente, fala em “proteger criadores”, mas na prática está montando um sistema para cobrar um “pedágio” dos provedores de LLM e lucrar com isso; no fim, não acho que seja por justiça, e sim por motivação financeira

• Eu uso um navegador raro que não expõe muitos dados pessoais, então do ponto de vista do Cloudflare eu também pareço um bot; acho que, num ambiente em que o host (dono do site) decide quem tem acesso, privacidade não pode existir; concordo com rate limiting para evitar sobrecarga no servidor, mas bloquear acesso automatizado em si é praticamente impossível e, no fim, esse tipo de bloqueio também dificulta o acesso de usuários reais

  • Fico curioso se você atualmente é bloqueado com frequência por causa do Cloudflare ou do turnstile; você já insinuou isso acima, mas queria confirmar claramente

  • Se alguém vive em um país autoritário e precisa usar VPN por privacidade e liberdade, a internet vira um inferno de captcha operado por 2 ou 3 empresas; quando navego na internet normal com VPN e navegador voltado à privacidade, tenho mais problemas do que quando acesso sites protegidos pelo Cloudflare com um bot feito por mim mesmo; aliás, se a Microsoft fosse responsável por esse gatekeeping da web, seria ainda pior; especialmente usando VPN, para passar por um captcha da Microsoft é preciso concentrar por mais de 5 minutos como se fosse escrever um artigo científico

  • O dono do site também tem direitos; dizer que ele não deveria escolher gatekeeping em nome da sustentabilidade financeira da operação é uma exigência excessiva

  • Eu também uso um navegador raro e acabo batendo em bloqueadores de bots com frequência, mas ainda acho que o host tem o direito de tratar minhas requisições como quiser; no caso de sites do governo, porém, acho que a responsabilidade de servir todos de forma justa é muito maior

• Se houver uma alternativa melhor e mais aberta, eu gostaria de ouvir; mas, no momento, o que o Cloudflare faz resolve bem o problema real dos AI bots; antes já tentaram bloquear por IP ou por user agent, mas isso tem limites; e, na prática, outros problemas de segurança também vêm sendo resolvidos com abordagens um tanto centralizadas; autoridades certificadoras (certificate authorities) não são um sistema aberto, e provedores de attestation também não, mas ainda assim funcionam

  • Se você quer uma solução mais aberta, a resposta pode ser regulação; bastaria proibir legalmente requisições de crawlers que não tenham sido explicitamente permitidos no robots.txt pelo operador do site, com fiscalização direta pelas autoridades; se o operador provar tráfego de bot, pode denunciar ao governo para aplicar multas pesadas; provedores de cloud poderiam ser obrigados a manter registros de quem usou qual IP; não seria uma solução 100%, mas, se bem aplicada, já seria um forte fator de dissuasão

  • Talvez não seja a melhor solução possível, mas é uma solução que funciona até certo ponto na prática; há muitas críticas ao problema da centralização, mas, se o Cloudflare conseguir trazer os principais players de IA e CDNs, isso pode acabar se consolidando como padrão de fato

  • Certificados não bloqueiam pessoas por confundi-las com bots

  • Acho que AI poisoning — inserir propositalmente informações erradas nos dados para atrapalhar a IA — seria uma proteção mais eficaz; o próprio Cloudflare poderia oferecer um serviço de entregar dados incorretos de propósito aos AI bots

  • Na verdade, antes do Let's Encrypt, CAs muitas vezes eram usadas só por sites corporativos comuns, e às vezes apenas em partes como a página de login; se não fosse a política aberta do Let's Encrypt, nossos dados pessoais talvez ainda estivessem expostos a ISPs ou intermediários; provedores de attestation também se mostram impotentes, por exemplo ao se recusarem a revogar certificações de dispositivos com vulnerabilidades amplamente conhecidas por razões de negócio; no fim, parece que a maioria das discussões não encontra uma alternativa realmente boa; o Cloudflare virar gatekeeper da internet é uma solução ruim, mas o problema em si é muito mais grave; soluções totalmente distribuídas já existem (por exemplo, remote attestation, visitas/assinaturas pagas, firewalls self-hosted etc.); essa postura de ignorar os efeitos colaterais da IA e dizer apenas para pagarem os custos foi justamente o que fez o Cloudflare crescer ainda mais; se ISPs e outros atores não tivessem ignorado problemas como spoofing, DDoS e botnets, o Cloudflare talvez tivesse ficado apenas como mais um concorrente tipo Akamai

• Já vivemos em um mundo com gatekeepers demais; qualquer tentativa adicional de gatekeeping deve ser vista como um comportamento agressivo; tanto Cloudflare quanto Google estão forçando ainda mais suas posições de gatekeeper; se essa tendência continuar, eu gostaria de ver ambos ruírem completamente

  • Várias empresas estão tentando oferecer soluções para o problema dos AI bots, e, se o Cloudflare for o escolhido, ganhará uma receita enorme; mas, mesmo que o Cloudflare recue, o problema não desaparece — só será adotada a alternativa ruim de outra empresa; gatekeeping é, na prática, uma opção escolhida pelo dono do site (por exemplo: paywall, detecção própria de bot, verificação de identidade etc.); o Cloudflare já oferece esse tipo de serviço e, se isso se padronizar, as opções aumentam e o mercado também se abre mais (com todos os efeitos colaterais); a liberdade da verdadeira web aberta vale tanto para visitantes quanto para donos de sites

  • Falar do “desejo” do Google de virar o gatekeeper do futuro é exagero; o Google já atua como gatekeeper há anos por causa da participação do Chrome no mercado; o Firefox também quase não tem mais relevância; a visão é que o Google já vem conduzindo toda a www na direção que quer (uBlock banido, imposição do formato .webp etc.)

• Antes de apontar como problema uma allowlist operada por uma única empresa, há o fato de que o próprio operador do site escolheu esse serviço; curioso é o contraste entre falar ideologicamente sobre “justiça” enquanto, na vida real, já se publica no blog quadrinhos feitos com ferramentas de IA — mostrando como a IA já está profundamente presente no cotidiano

  • O Cloudflare está implementando o padrão emergente Web Bot Auth, e nós da Stytch também estamos aplicando esse mesmo padrão no IsAgent.dev; a discussão atual está um tanto exaltada, então falo com cautela, mas no fim a allowlist é só uma opção oferecida aos clientes do Cloudflare, e o núcleo, como HTTP Message Signature, é projetado de forma aberta/distribuída para que qualquer um possa usar

  • Não há grande problema em usar por escolha própria a allowlist de uma empresa, mas isso por si só não vira protocolo; e a discussão sobre justiça não parece ter relação lógica com o uso de quadrinhos feitos por IA

  • É uma situação de trocar o ruim pelo menos ruim, e existe o risco de a solução de uma empresa específica acabar ficando como padrão informal; esta poderia ter sido uma chance de criar uma solução de verdade baseada em protocolo/padrão, mas o Cloudflare parece estar tentando criar seu próprio oceano azul; e é uma boa ironia apontar que, enquanto se fala em “justiça”, na prática a IA já está sendo usada em todos os cantos da vida cotidiana

• Vejo isso como algo parecido com a estrutura do e-mail; o e-mail é baseado em padrões da internet, mas a maior parte dos usuários está concentrada em poucos provedores, como o Gmail; o Cloudflare também promove o padrão aberto em si, mas o poder real vem do número de clientes em grande escala; (também se pergunta qual seria uma boa alternativa); e, assim como no e-mail existem problemas de baixa confiabilidade de entrega e dificuldade de implementação por causa do filtro de spam, a web também pode acabar seguindo um caminho parecido

  • Na prática, não existe alternativa real para substituir o Cloudflare como CDN gratuita; eles instalam servidores no mundo inteiro e distribuem isso de graça, lucrando com serviços serverless premium; além disso, grandes provedores de cloud cobram taxas de egress de tráfego absurdamente caras

• A web não quer attestation, nem signed agents, nem o Cloudflare decidindo quem é um agent “real”; todos deveriam reaprender o significado de “public” e, se lidar com tráfego for difícil, o ideal seria apenas aplicar rate limiting básico; a web não precisa perguntar se o solicitante é humano, bot ou cachorro — basta servir bytes a todos os requisitantes dentro de um nível razoável de recursos; se essa essência da “web aberta” desaparecer, todos vão sentir falta

  • Mesmo rate limiting básico é vulnerável a ataques; não dá para ignorar botnets e, com a transição para IPv6, um rate limiting útil se torna praticamente impossível; se os buckets forem mal definidos, alguns provedores de rede distribuem blocos /48 com facilidade demais e anulam o limite, enquanto usuários móveis podem acabar agrupados aos centenas de milhares sob um único rate limit

  • No fim, esse tipo de proposta equivale a dizer que inúmeros sites pequenos deveriam simplesmente fechar por não conseguirem lidar com o tráfego, o que contradiz o slogan de “internet aberta”

  • Os crawlers de IA modernos já se tornaram impossíveis de distinguir de botnets maliciosas; rate limiting normal não faz mais sentido, e é justamente esse o ponto em que o Cloudflare entrou para tentar resolver o problema

  • A ideia de que “public é PUBLIC” seria ótima se desse para operar só com rate limiting básico, mas, na prática, seria preciso publicar explicitamente qual velocidade de acesso é aceitável; o problema é que há muitos casos em que, só por ter um user-agent diferente, a requisição já é bloqueada de cara mesmo se ocorrer apenas uma vez; no fim, operadores tendem a bloquear qualquer requisição com base apenas na identidade, e não no comportamento do bot; o critério é grosseiro, gera muitos falsos positivos e, mesmo nesses casos, não se analisa tentativa ou contexto algum — a decisão de bloquear é tomada puramente pela identidade

  • Muitas vezes até o rate limiting básico não é fácil de implementar; a menos que exista necessidade específica de autenticação ou delegação de autoridade, acesso a arquivos públicos não deveria exigir autenticação nem delegação à parte; e mesmo quando existe essa questão de delegação, não há necessidade de um terceiro como o Cloudflare intervir além do papel do verdadeiro delegador

• Concordo com a maior parte da opinião do autor; em ambientes enterprise, a preocupação é como controlar o comportamento de agents em redes privadas complexas; recentemente, construí eu mesmo um sistema de “identity token” baseado em biscuit; por esse token, alguém se autentica e depois pode criar um token de delegação para repassar a um agent subordinado; no meu sistema, sem token de autorização não se pode fazer nada (conceito de escopo único e uso único); na internet, imagino que seria possível trocar um identity token + micropagamento (por exemplo, uma transação cripto bem pequena) por um token de autorização; assim, para usuários humanos o custo seria quase zero e não haveria problema, enquanto crawlers de IA acabariam pagando muito mais