Ir para o conteúdo principal
COMO FUNCIONA

Como o Proof of Actor funciona.

Um caminho baseado primeiro em evidências, da interação recebida à decisão da aplicação.

Solicitar acesso antecipadoVer Detecção e Limites
política · example-app.test
  • /api/v1/catalogenforceAgentePermitir · API estruturada
  • /support/ticketsenforceHumano + IAPermitir · rotular como Human + AI
  • /account/*previewDesconhecidoMantenha as verificações existentes
  • /api/v1/orderspreviewAgenteExigir credencial mais forte

Da interação à decisão

  1. 01Requisição ou evento da aplicaçãoUma visualização de página, uma chamada de API, uma chamada de ferramenta MCP ou uma ação dentro da app.
  2. 02Sinais da integração suportadaSomente o que essa integração pode observar nesse contexto.
  3. 03Normalização e classificação de evidênciaOs sinais são verificados, rotulados pela base e combinados.
  4. 04Resultado do ator com base e incertezaHumano, Humano + IA, Agente ou Desconhecido, além do que isso se baseia.
  5. 05Dashboard e analyticsTendências, rotas e evidências para sua equipe revisar.
  6. 06A própria decisão da sua aplicaçãoApenas observar, ou aplicar uma política que você escolheu.
PARA DESENVOLVEDORES

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent ou Unknown.
basis
Quão forte é a evidência: Verified, Declared, Inferred ou Unknown.
evidence
Os sinais por trás do resultado, para que sua equipe possa ver o motivo.

Comece no modo de observação: registre os resultados ao lado dos seus logs e não altere nada até escolher uma policy. Leia o guia de integração do Node.js

Observation mode é o padrão

Instalar o Proof of Actor não bloqueia nem altera nenhuma request. Os resultados são registrados para que sua equipe possa compará-los com os resultados reais da aplicação, revisar falsos positivos e decidir se alguma policy é apropriada.

Tipos de evidência

A evidência disponível depende da integração e do contexto. As verificações de cada workflow são acordadas com a equipe durante o onboarding, e os detalhes internos dos sinais permanecem privados para que seja mais difícil imitá-los.

  • Assinaturas da requisição

    Assinaturas criptográficas de clientes automatizados que publicam suas chaves.

  • Declarações

    Um client que se identifica como agent, ou uma declaração de assistência de IA dentro da sua app.

  • Sinais de interação

    Sinais de um coletor de navegador aprovado, nas páginas em que ele é executado.

  • Contexto da requisição

    Headers e detalhes de protocolo disponíveis para uma integração no lado do servidor.

Identidade do agente não é autorização

Uma request assinada de um client automatizado pode mostrar que a request foi assinada com uma chave associada a um identificador publicado, como o domínio de um operador. Isso é uma evidência útil sobre qual client a enviou.

Isso não mostra quem instruiu o agent, se uma pessoa delegou permissão a ele, a identidade legal por trás dele ou se a ação é segura. Essas são perguntas separadas que sua aplicação responde com sua própria autenticação, autorização e política.

três perguntas separadas
  • Quem está chamando?Proof of Actor: assinatura, declaração ou inferência
  • Qual credencial?Sua chave de API, token OAuth ou sessão
  • O que pode fazer?Sua autorização e política

Como as decisões de roteamento se encaixam

Sua aplicação chama Proof of Actor, recebe um resultado e aplica suas próprias regras. Você escolhe, por rota e por nível de risco, se a integração falha aberta (a solicitação prossegue como aconteceria sem o Proof of Actor) ou falha fechada (sua verificação mais forte existente é aplicada).

  • Timeout de API

    Se um resultado não estiver disponível a tempo, sua integração usa a alternativa que você escolheu para essa rota. Um timeout nunca se torna um resultado Humano.

  • Telemetria ausente

    Se o coletor do navegador não foi executado ou um sinal está ausente, o resultado reflete isso. Evidência ausente reduz o que pode ser dito; isso não é tratado como suspeito.

  • Classificações Unknown

    Unknown é um resultado normal. Sua política define o que Unknown significa para cada rota, por exemplo: permitir páginas públicas, manter as verificações existentes em alterações de conta.

  • Evidência desatualizada

    A evidência tem tempo e escopo. Um resultado anterior na sessão não deve ser reutilizado para uma ação posterior, mais sensível, sem uma nova verificação.

O workflow de integração em beta

  1. 01AplicarConte-nos sobre o app e a interação que você quer entender.
  2. 02EscopoConcorde com a integração, as rotas, os limites de uso e o tratamento de dados.
  3. 03Integrar no modo de observaçãoSem mudança em como seu app responde.
  4. 04ValidarCompare os resultados com a verdade de referência que você conhece: cobertura, taxa de desconhecidos, falsos positivos, latência.
  5. 05DecidirAtive uma policy somente onde a evidência der suporte a isso.

O que medimos com as equipes fundadoras

Cobertura, taxa de desconhecidos, falsos positivos em relação a resultados conhecidos e latência adicional, em cada contexto suportado.

Comece no modo de observação.

Candidate-se para participar do programa de desenvolvedores fundadores.

Solicitar acesso antecipadoVer Detecção e Limites

Prefere falar primeiro? Fale com os fundadores