Ir para o conteúdo principal
Voltar aos artigos

Seu SaaS precisa distinguir o usuário, o agente e quem autorizou a ação

Trusted Agent Delegation propõe identidade e responsabilização para agentes. Para APIs, isso pede autorização e limites por conta explícitos.

·3 min de leitura·4 visualizações

A Cloudflare apresentou a coalizão Trusted Agent Delegation para discutir identidade, reputação e responsabilização de agentes que atuam em nome de usuários.[14] O foco inicial são agentes hospedados fora do dispositivo da pessoa, capazes de operar continuamente e em paralelo.[14] Para quem constrói um SaaS, a questão central é preservar a relação de autorização quando uma única infraestrutura passa a representar muitos usuários.

O que muda para quem desenvolve

O artigo descreve problemas como bloqueios que atingem usuários legítimos junto com um abusador do mesmo agente, dificuldade de demonstrar autorização em transações e perda de sinais usados na prevenção de fraude.[14] Encaminhar um CAPTCHA ao humano não esclarece, sozinho, quem está por trás das demais solicitações.[14]

Web Bot Auth é o mecanismo preferido pela empresa para autenticar agentes por assinatura de requisições e identificar implicitamente seu operador.[14] O texto também discute níveis de identificação e mecanismos como OAuth, Privacy Pass e MOLE para contextos diferentes.[14] A proposta não é exigir identidade civil em toda interação, mas adequar os sinais ao risco da operação.[14]

Minha leitura é que o modelo de dados deve separar usuário final, agente, operador e ação autorizada. Colapsar tudo em uma única identidade dificulta decidir quem pode fazer o quê e contra quem aplicar uma restrição.

Como aplicar

Escolha um fluxo com efeito real, como alterar um plano ou iniciar uma compra. Descreva qual usuário é beneficiário, qual agente atua, quem opera esse agente e qual autorização sustenta a ação. Se uma dessas respostas depender apenas de um cabeçalho declarativo, registre a lacuna.

Em um protótipo, simule duas contas usando o mesmo operador de agente. Gere excesso de solicitações em apenas uma delas e verifique se a mitigação preserva o acesso da outra. O objetivo é testar justiça por conta, não apenas bloquear uma origem de rede inteira.

Para ações sensíveis, defina escopo, validade e evidência de consentimento. Minimize os atributos coletados e justifique cada dado adicional pelo risco que ele ajuda a controlar. Evite transformar uma integração automatizada em justificativa para identificar excessivamente todos os visitantes.

Cuidados e limites

A coalizão pretende transformar necessidades em trabalho de padronização, e agentes locais e open source não são o foco inicial.[14] Não trate a iniciativa como um padrão final já interoperável em qualquer ambiente.

A Cloudflare também anuncia recursos comerciais, com condições de acesso variadas; Account Abuse Protection ainda estava em acesso antecipado.[14] Separe a arquitetura desejada dos controles que você consegue usar hoje. Minha recomendação é começar por autorização explícita e limites verificáveis por conta, sem depender de um protocolo futuro e sem tentar fazer a automação parecer um humano.

Fonte

[14] Fonte: Cloudflare Blog

Continue lendo