Uma única política para todos já não basta
A maioria das aplicações foi projetada em torno de um único tipo de usuário: uma pessoa navegando por uma interface, autenticada em uma conta. O controle de acesso seguia essa suposição. Se a sessão é válida, a solicitação passa. Se parece automatizada, aparece um CAPTCHA ou um bloqueio.
Esse modelo está se rompendo. Hoje a mesma aplicação atende pessoas, pessoas trabalhando com assistentes de IA e agentes autônomos agindo em nome de alguém. Alguns agentes são integrações do próprio cliente. Alguns são assistentes de IA buscando documentação. Alguns são crawlers. Alguns poucos estão tentando abusar do seu produto. Uma única regra de sim ou não não atende bem a todos.
Políticas de roteamento e acesso para agentes de IA substituem essa regra única por um conjunto de decisões deliberadas: quais atores recebem qual experiência, em quais rotas, sob quais condições. O Proof of Actor fornece à sua aplicação a evidência para tomar essas decisões e deixa as decisões em suas mãos. Para os princípios de design por trás dessa abordagem, leia designing app policies for humans and AI agents, e veja o caso de uso para SaaS apps para entender como as políticas se mapeiam em fluxos de produto reais.
Como é uma boa política para agentes
Uma política útil é específica. Ela nomeia uma rota ou um fluxo de trabalho, uma classe de ator, a força da evidência exigida e a resposta. Por exemplo:
- Rotas de catálogo somente leitura: permitir agentes verificados e servir uma resposta estruturada; permitir agentes declarados com o limite de taxa padrão.
- Ações que alteram a conta: manter sua reautenticação existente para todos; adicionar revisão quando o ator for Unknown e a ação tiver alto impacto.
- Envios para suporte: aceitar conteúdo com uso de IA declarado e marcá-lo para roteamento.
- Cadastro: manter as verificações existentes; nunca decidir apenas a partir de um resultado de ator inferido.
Cada uma dessas respostas trata o ator sem tratar todo agente como abuso e sem confiar cegamente em todo agente. Esse equilíbrio é o objetivo do acesso consciente de agentes, e o artigo sobre designing app policies for humans and AI agents desenvolve mais exemplos rota por rota.
As cinco respostas
A capacidade de Route do Proof of Actor é estruturada em cinco respostas entre as quais suas políticas podem escolher.
Permitir
Deixar a solicitação prosseguir normalmente. A maior parte do tráfego, inclusive a maior parte do tráfego de agentes em rotas públicas ou de baixo risco, deve simplesmente ser permitida.
Adaptar
Mudar a experiência para se adequar ao ator. Servir uma resposta estruturada de API ou uma versão em Markdown de uma página para um agente verificado, em vez de uma interface pensada para humanos. O guia sobre serving AI agents structured content cobre esse padrão.
Desafiar
Pedir algo mais forte: um novo login, uma credencial adicional, uma confirmação do titular da conta. Use desafios em rotas nas quais o custo de uma decisão errada é alto.
Revisar
Fazer a ação entrar em uma fila em vez de ir diretamente para a conclusão, ou sinalizá-la para que uma pessoa verifique. Revisão é útil quando bloquear prejudicaria usuários legítimos, mas concluir sem supervisão é arriscado demais.
Limitar a taxa
Aplicar um limite de taxa ou de volume ajustado ao ator e à rota, para que chamadores automatizados não sobrecarreguem um fluxo de trabalho pensado para pessoas.
Por que robots.txt não é uma política de acesso
Muitas equipes começam com robots.txt, e isso é um primeiro sinal sensato para crawlers. Não é uma política de acesso para agentes. Operadores de crawlers documentam comportamentos diferentes para diferentes user agents: a Anthropic informa que seus bots seguem as diretivas de robots.txt (Anthropic crawler documentation), enquanto a OpenAI observa que, para ChatGPT-User, que age quando um usuário faz uma pergunta ao ChatGPT, as regras de robots.txt podem não se aplicar porque a ação é iniciada por um usuário (OpenAI crawler documentation). O robots.txt também não diz nada sobre APIs, ferramentas MCP ou fluxos com login.
Uma política de acesso precisa funcionar onde a solicitação é tratada, ler evidências como uma assinatura verificada sob RFC 9421 e escolher uma resposta por rota. Para MCP servers, a MCP authorization specification define como clientes obtêm access tokens por HTTP; políticas de ator adicionam contexto acima disso, não substituem isso.
Como o Proof of Actor alimenta suas políticas
Toda solicitação que sua integração avalia produz um resultado de ator com quatro partes que sua política pode ler:
- Classe: Human, Human + AI, Agent ou Unknown.
- Base: verified, declared, inferred ou unknown, para que sua política possa tratar uma assinatura validada de forma diferente de um nome de cliente auto-declarado.
- Resumo da evidência: uma descrição legível do que sustenta o resultado, útil para logs e revisão.
- Contexto: qual integração e qual rota o produziram.
Como a base é explícita, suas políticas podem ser precisas. "Permitir agentes" vira "permitir agentes verificados em rotas de leitura, limitar a taxa de agentes declarados, aplicar o fallback Unknown para todo o restante". O fluxo completo da solicitação até a decisão é descrito em How It Works.
Os fallbacks fazem parte da política
Uma política só é tão boa quanto seu comportamento quando faltam evidências. O Proof of Actor torna esses casos explícitos em vez de escondê-los.
- Unknown: a evidência não sustentou uma determinação. Sua política define o que Unknown significa em cada rota. Nunca é convertido em Human e nunca é tratado como malicioso por padrão.
- Timeout: o resultado não chegou a tempo. Sua integração aplica o fallback que você escolheu para aquela rota.
- Sinais ausentes: um coletor não foi executado ou um header estava ausente. O resultado reflete isso, e sua política trata o caso de acordo.
Para cada rota, você escolhe se deve fail open or fail closed. Fail open significa que a solicitação segue como seguiria sem o Proof of Actor; fail closed significa que sua verificação forte existente é aplicada. Rotas de baixo risco geralmente usam fail open. Ações sensíveis geralmente usam fail closed. Você define isso por nível de risco, não globalmente.
Separe identidade, credenciais e autorização
Políticas de acesso para agentes ficam sobre três camadas distintas, e mantê-las separadas evita os erros mais graves.
- Evidência de identidade responde que tipo de ator está chamando e o que o comprova. O Proof of Actor fornece isso.
- Credenciais respondem qual conta é responsável. Sua sessão, token ou API key fornece isso.
- Autorização responde se esse chamador pode executar esta ação. Seu modelo de permissão fornece isso.
Uma identidade de agente verificada não significa que o agente esteja autorizado, que uma pessoa tenha delegado autoridade a ele ou que sua ação seja segura. Use os resultados de ator para roteamento e contexto. Use seu modelo de autorização para conceder permissão. A página sobre Detection & Limitations explica exatamente o que cada tipo de evidência pode estabelecer.
Lance sem quebrar nada
A forma mais segura de introduzir políticas de acesso para agentes é em etapas.
- Observar. Instale o Proof of Actor em observation mode. Nada muda para seus usuários; os resultados são registrados.
- Entender. Revise quais atores usam quais rotas, a taxa de Unknown em cada uma e quaisquer resultados que entrem em conflito com o que você já sabe.
- Pré-visualizar. Execute uma política em preview, registrando o que ela teria feito sem aplicá-la.
- Aplicar de forma restrita. Ative a política em uma rota onde a evidência a sustente claramente. Observe os resultados.
- Expandir. Amplie para mais rotas conforme a confiança cresce.
O guia sobre rolling out actor-aware policies safely percorre cada etapa, e protecting sensitive actions without blocking agents cobre as rotas de maior risco.
O que sua equipe recebe
Com o Proof of Actor, sua equipe recebe uma integração com três capacidades. Detect coleta sinais de ator e separa afirmações verificadas de inferências. Understand mostra analytics de atores, tendências e a evidência por trás de cada resultado, mantendo Unknown visível. Route permite que você escreva as políticas descritas nesta página e as aplique onde escolher. Durante a beta privada, as políticas de roteamento são desenhadas junto com cada equipe fundadora e executadas no código da sua própria aplicação, para que você mantenha controle total.
Erros comuns de política que você deve evitar
Equipes que estão desenhando acesso para agentes pela primeira vez tendem a repetir alguns erros. Evitá-los economiza semanas de retrabalho.
- Bloquear todo agente por padrão. Agentes legítimos então contornam isso, muitas vezes raspando a interface que você construiu para pessoas, que é mais difícil de proteger do que um caminho estruturado.
- Confiar em um nome declarado. Um cliente que apenas se nomeia fez uma alegação, não apresentou prova. Dê a ele o mesmo tratamento que daria a um chamador não verificado.
- Usar um único fallback em todo lugar. Unknown em uma página pública de preços e Unknown em uma mudança de senha são situações diferentes. Cada rota precisa da sua própria resposta.
- Decidir sobre pessoas a partir de uma inferência. Resultados de ator são contexto para roteamento, não um veredito sobre um indivíduo. Mantenha decisões com consequências sob seus próprios controles e revisão.
- Pular a observação. Aplicar desde o primeiro dia significa descobrir falsos positivos por meio de reclamações de clientes. Observe primeiro, depois aplique onde a evidência for clara.
Uma revisão breve de política com seus responsáveis de segurança, produto e suporte antes de cada etapa de aplicação detecta a maioria desses problemas cedo.
Comece com o programa de desenvolvedores fundadores
O Proof of Actor está em beta privada. Equipes fundadoras selecionadas de desenvolvimento podem receber até 12 months of free access, dentro de limites de uso acordados, com suporte direto dos nossos engenheiros enquanto vocês desenham suas primeiras políticas.
Se você está decidindo como sua aplicação deve tratar agentes de IA, candidate-se ao acesso antecipado. Conte quais rotas importam mais e quais decisões você quer tomar, e ajudaremos você a construir políticas que se encaixem. Você também pode ver como isso se aplica a APIs e MCP servers.
Fontes
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.