Su API conoce la clave. No conoce al actor.
Cada solicitud de API llega con alguna prueba de quién la paga: una API key, un token de OAuth, una sesión. Esa prueba responde bien a una pregunta. Le dice qué cuenta es responsable de la llamada. No le dice qué está haciendo realmente la llamada en ese momento.
Una sola API key puede ser usada por un desarrollador que prueba en una terminal, por un trabajo de backend que se ejecuta según un horario, por una persona que trabaja con un asistente de IA y por un agente autónomo al que se le entregó la clave y se le pidió que termine una tarea. Esos son actores muy distintos. Tienen ritmos distintos, modos de fallo distintos y perfiles de riesgo distintos. Tratar a todos igual significa que o bien restringe en exceso la automatización legítima de la que dependen sus clientes, o bien protege de forma insuficiente las partes de su API que nunca deberían ser dirigidas por un agente sin supervisión.
La identificación de agentes de IA para APIs cierra esa brecha. En lugar de inferir todo a partir de la clave, obtiene una clasificación del actor detrás de cada solicitud, junto con la evidencia que la respalda. Eso es lo que Proof of Actor está diseñado para ofrecer, y el caso de uso de APIs muestra cómo los equipos de API lo aplican ruta por ruta.
Por qué los equipos de API necesitan contexto de actor ahora
El tráfico automatizado hacia las APIs no es nuevo. Los scripts, las integraciones y los crawlers siempre han formado parte del panorama. Lo que ha cambiado es el tipo de automatización. Los agentes de IA pueden leer documentación, encadenar llamadas, reintentar de forma creativa y actuar en nombre de personas que no están observando cada paso. Muchos son útiles y bienvenidos. Algunos están mal construidos. Unos pocos son hostiles.
Sin contexto de actor, los equipos de API suelen recurrir a herramientas bruscas:
- Límites de tasa por clave, que ralentizan por igual a los buenos y a los malos agentes.
- Reglas de user-agent, que se rompen en cuanto un cliente cambia un encabezado.
- Bloqueos globales, que empujan la automatización legítima a hacer scraping de su aplicación web en su lugar.
El contexto de actor le permite responder con precisión. Un agente firmado de un operador que usted reconoce puede obtener un límite más alto en rutas de lectura. Un llamador desconocido que llega a una ruta de escritura puede recibir la solicitud de una credencial más fuerte. Una persona que usa un asistente de IA puede mantener una experiencia normal. El objetivo no es detener a los agentes. El objetivo es dar a cada tipo de llamador el camino correcto. Para saber qué puede y qué no puede decirle una solicitud firmada, lea qué demuestran las solicitudes firmadas de agentes de IA.
Cómo funciona la identificación de agentes de IA en Proof of Actor
Proof of Actor sigue el mismo flujo basado en evidencia para cada solicitud. Puede leer el recorrido completo en Cómo funciona; aquí tiene la versión breve para equipos de API.
1. Señales de su integración
Su integración entrega a Proof of Actor las señales disponibles en ese contexto. Para una API, eso normalmente significa contexto de solicitud como encabezados y detalles del protocolo, cualquier firma criptográfica de solicitud que el cliente proporcione y cualquier declaración que el cliente haga sobre sí mismo. Cada señal se etiqueta con su origen.
2. Clasificación con una base
Las señales se verifican y combinan en una de cuatro clases públicas:
- Human: las señales observables indican una interacción dirigida por una persona.
- Human + AI: la asistencia de IA fue declarada o detectada por una integración que puede observarla.
- Agent: tráfico automatizado o de origen agente, respaldado por una identidad verificable o por una inferencia cuidadosamente cualificada.
- Unknown: la evidencia no respalda una determinación fiable.
Cada resultado también lleva su base: Verified, Declared, Inferred o Unknown. Esta es la parte que más valoran los equipos de API. Una solicitud cuya firma de mensaje HTTP, tal como se define en RFC 9421, valida frente a una clave pública se informa como Verified. Un cliente que simplemente se declara como agente se informa como Declared. Un patrón que parece automatizado se informa como Inferred. Nunca tiene que preguntarse si un resultado se basa en criptografía o en una heurística. La base de evidencia forma parte de la respuesta.
3. Un resultado sobre el que su código puede actuar
El resultado vuelve a su aplicación con la clase, la base y un resumen de evidencia legible. Su código decide qué hacer con él. En modo observación, simplemente lo registra. Cuando esté listo, lo enruta.
Qué obtiene su equipo: Detect, Understand, Route
Proof of Actor es un solo producto con tres capacidades.
Detect
Reúna las señales de actor que su API puede ver y separe las afirmaciones verificadas de las inferencias de comportamiento. Las solicitudes firmadas de agentes, los clientes declarados, las señales de automatización y los resultados Unknown se mantienen separados, de modo que nada se fusiona en silencio en una sola puntuación.
Understand
Vea qué actores llaman a qué rutas, cómo cambia eso con el tiempo y qué evidencia está detrás de cada clasificación. La tasa de Unknown permanece visible, lo que le indica exactamente dónde termina su cobertura y dónde ayudaría una señal más fuerte.
Route
Escriba políticas por ruta y por nivel de riesgo: allow, adapt, challenge, review o rate-limit. Mantenga un camino estructurado y generoso para los agentes verificados en endpoints de solo lectura. Pida credenciales más fuertes en operaciones de alto impacto. Defina un fallback explícito para Unknown y para los timeouts, para que su API se comporte de forma predecible pase lo que pase. Usted decide cómo falla cada política, abierto o cerrado, según el coste de un error en esa ruta.
La evidencia de identidad, las credenciales y la autorización son tres cosas distintas
El error más común en el diseño de APIs conscientes de agentes es fundir tres preguntas separadas en una sola. Proof of Actor las mantiene separadas, y su diseño también debería hacerlo.
- Evidencia de identidad: qué tipo de actor llama y qué lo demuestra. Eso es lo que proporciona la identificación de agentes de IA. Una firma verificada asocia una solicitud con una clave y su identificador de operador publicado. El grupo de trabajo Web Bot Auth de IETF tiene el mandato de estandarizar este tipo de autenticación criptográfica para clientes automatizados, y su alcance cubre la autenticación del agente y no del usuario final.
- Credenciales: qué cuenta es responsable de esta llamada. Esta es su API key, token o sesión, emitidos y gestionados por usted.
- Autorización: ¿este llamador puede hacer esta acción específica? Este es su modelo de permisos.
Un agente verificado no es automáticamente un agente autorizado. Una firma válida no demuestra que una persona haya delegado autoridad al agente, y tampoco hace que la acción solicitada sea segura. Proof of Actor le da contexto fiable para la primera pregunta y deja la segunda y la tercera exactamente donde pertenecen: en su aplicación. Lea más sobre autorización de agentes y sobre lo que la evidencia puede y no puede establecer en Detección y limitaciones.
Unknown es una función, no un fallo
La firma de solicitudes es opcional, y un cliente sin firmar puede describirse como quiera. Un sistema que fuerza cada solicitud a Human o Agent se equivocará con confianza algunas veces, y usted no sabrá cuándo.
Proof of Actor informa Unknown cuando la evidencia no respalda una determinación. Unknown nunca se convierte en Human y nunca se trata como malicioso por defecto. Su política define qué significa Unknown para cada ruta: permitirlo en lecturas públicas, mantener sus comprobaciones actuales en cambios de cuenta, ponerlo en revisión cuando el riesgo es alto. Mantener Unknown visible es lo que hace fiables sus otras clasificaciones. La guía sobre cómo manejar tráfico Unknown muestra cómo diseñar para ello.
Dónde encaja la identificación de agentes de IA en su stack
Proof of Actor se sitúa junto a su gateway, autenticación y rate limiting existentes. No sustituye a ninguno de ellos. Las ubicaciones habituales incluyen:
- Middleware del lado del servidor delante de sus controladores de ruta, para que cada solicitud se evalúe antes de que se ejecute su lógica de negocio.
- En el edge, para que las señales se evalúen antes de que las solicitudes lleguen a su origen.
- Una integración HTTP genérica, para que cualquier stack pueda enviar contexto de solicitud y recibir un resultado con su base.
Las integraciones se entregan de forma práctica con cada equipo fundador durante el onboarding, de modo que el camino se adapte a su arquitectura y no al revés. El centro para desarrolladores muestra las rutas de integración disponibles hoy. Si usted opera herramientas para agentes, el caso de uso de MCP Servers cubre los patrones específicos para llamadas a herramientas.
Empiece en modo observación
Instalar Proof of Actor no cambia cómo responde su API. Los resultados se registran para que su equipo pueda compararlos con los resultados que ya conoce, ver a dónde van realmente los agentes, medir la tasa de Unknown en cada ruta y revisar cualquier clasificación que parezca incorrecta. Solo entonces habilita una política, ruta por ruta, donde la evidencia lo respalda.
Así es como despliega la identificación de agentes de IA sin sorprender a sus clientes ni romper las integraciones de las que dependen. La guía sobre desplegar políticas conscientes del actor de forma segura recorre la secuencia paso a paso.
Únase al programa de desarrolladores fundadores
Proof of Actor está en beta privada con un pequeño grupo de equipos fundadores de desarrollo. Los equipos seleccionados pueden recibir hasta 12 meses de acceso gratuito, dentro de los límites de uso acordados durante el onboarding, junto con soporte directo de integración de nuestros ingenieros e influencia real sobre lo que construiremos después.
Si usted opera una API y quiere saber quién la está llamando realmente, solicite acceso anticipado. Cuéntenos sobre su API, las rutas que más le importan y las decisiones que tomaría de otra manera con contexto de actor. Le diremos cómo encaja Proof of Actor.
Fuentes
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Declaración del grupo de trabajo Web Bot Auth (webbotauth), IETF.