Saltar al contenido principal
CÓMO FUNCIONA

Cómo funciona Proof of Actor.

Un recorrido centrado en la evidencia desde la interacción entrante hasta la decisión de la aplicación.

policy · example-app.test
  • /api/v1/catalogenforceAgentePermitir · API estructurada
  • /support/ticketsenforceHumano + IAPermitir · etiquetar como asistido por IA
  • /account/*previewDesconocidoMantén las comprobaciones existentes
  • /api/v1/orderspreviewAgenteExigir una credencial más fuerte

De la interacción a la decisión

  1. 01Solicitud o evento de la aplicaciónUna vista de página, una llamada a API, una llamada a herramienta de MCP o una acción dentro de la app.
  2. 02Señales de la integración compatibleSolo lo que esa integración puede observar en ese contexto.
  3. 03Normalización y clasificación de evidenciaLas señales se revisan, se etiquetan según su base y se combinan.
  4. 04Resultado del actor con base e incertidumbreHumano, Humano + IA, Agente o Desconocido, además de en qué se basa.
  5. 05Dashboard y analíticaTendencias, rutas y evidencia para que tu equipo las revise.
  6. 06La propia decisión de tu aplicaciónSolo observar o aplicar una política que hayas elegido.
PARA DESARROLLADORES

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 o Unknown.
basis
Qué tan sólida es la evidencia: Verified, Declared, Inferred o Unknown.
evidence
Las señales detrás del resultado, para que tu equipo vea por qué.

Empieza en modo de observación: registra los resultados junto a tus logs y no cambies nada hasta que elijas una política. Lee la guía de integración de Node.js

El modo observation es el valor predeterminado

Instalar Proof of Actor no bloquea ni cambia ninguna solicitud. Los resultados se registran para que tu equipo pueda compararlos con los resultados reales de la aplicación, revisar los falsos positivos y decidir si alguna política es apropiada.

Tipos de evidencia

La evidencia disponible depende de la integración y del contexto. Las comprobaciones de cada flujo de trabajo se acuerdan con el equipo durante la incorporación, y los detalles internos de las señales permanecen privados para que sean más difíciles de imitar.

  • Firmas de la solicitud

    Firmas criptográficas de clientes automatizados que publican sus claves.

  • Declaraciones

    Un cliente que se nombra a sí mismo como Agent, o una divulgación de asistencia de IA dentro de tu app.

  • Señales de interacción

    Señales de un colector de navegador aprobado, en las páginas donde se ejecuta.

  • Contexto de la solicitud

    Encabezados y detalles del protocolo disponibles para una integración del lado del servidor.

La identidad del agent no es autorización

Una solicitud firmada de un cliente automatizado puede mostrar que la solicitud se firmó con una clave asociada a un identificador publicado, como el dominio de un operador. Eso es una evidencia útil sobre qué cliente la envió.

No muestra quién instruyó al agente, si una persona le delegó permiso, la identidad legal detrás de él ni si la acción es segura. Esas son preguntas separadas que tu aplicación responde con su propia autenticación, autorización y política.

tres preguntas separadas
  • ¿Quién llama?Proof of Actor: firma, declaración o inferencia
  • ¿Qué credencial?Tu API key, token de OAuth o sesión
  • ¿Qué puede hacer?Tu autorización y política

Cómo encajan las decisiones de enrutamiento

Tu aplicación llama a Proof of Actor, recibe un resultado y aplica sus propias reglas. Tú eliges, por ruta y por nivel de riesgo, si la integración falla abierta (la solicitud continúa como lo haría sin Proof of Actor) o falla cerrada (se aplica tu comprobación más estricta existente).

  • Tiempo de espera de API agotado

    Si un resultado no está disponible a tiempo, tu integración usa la alternativa que elegiste para esa ruta. Un timeout nunca se convierte en un resultado Humano.

  • Telemetría ausente

    Si el recopilador del navegador no se ejecutó o falta una señal, el resultado lo refleja. La evidencia faltante reduce lo que puede afirmarse; no se trata como algo sospechoso.

  • Clasificaciones Unknown

    Unknown es un resultado normal. Tu política define qué significa Unknown para cada ruta, por ejemplo: permitir páginas públicas, mantener los controles existentes en cambios de cuenta.

  • Evidencia obsoleta

    La evidencia tiene un momento y un alcance. Un resultado obtenido antes en una sesión no debe reutilizarse para una acción posterior más sensible sin una comprobación nueva.

El flujo de integración de beta

  1. 01AplicarCuéntanos sobre la app y la interacción que quieres entender.
  2. 02AlcanceAcordar la integración, las rutas, los límites de uso y el tratamiento de datos.
  3. 03Integrar en modo de observaciónSin cambios en cómo responde tu app.
  4. 04ValidarCompara los resultados con la verdad de referencia que conoces: cobertura, tasa de desconocidos, falsos positivos, latencia.
  5. 05DecidirActiva una política solo donde la evidencia la respalde.

Qué medimos con los equipos fundadores

Cobertura, tasa de desconocidos, falsos positivos frente a resultados conocidos y latencia añadida, en cada contexto compatible.

Empieza en modo de observación.

Solicita unirte al programa de desarrolladores fundadores.

¿Prefieres hablar primero? Habla con los fundadores