Una sola política para todos ya no basta
La mayoría de las aplicaciones se diseñaron alrededor de un solo tipo de usuario: una persona haciendo clic en una interfaz, autenticada en una cuenta. El control de acceso siguió esa suposición. Si la sesión es válida, la solicitud pasa. Si parece automatizada, aparece un CAPTCHA o un bloqueo.
Ese modelo se está rompiendo. Hoy la misma aplicación atiende a personas, a personas que trabajan con asistentes de IA y a agentes autónomos que actúan en nombre de alguien. Algunos agentes son integraciones propias de los clientes. Algunos son asistentes de IA que consultan documentación. Algunos son rastreadores. Unos pocos intentan abusar de su producto. Una sola regla de sí o no no puede atenderlos bien a todos.
El enrutamiento y las políticas de acceso para agentes de IA sustituyen esa única regla por un conjunto de decisiones deliberadas: qué actores obtienen qué experiencia, en qué rutas y bajo qué condiciones. Proof of Actor aporta a su aplicación la evidencia para tomar esas decisiones y deja las decisiones en sus manos. Para los principios de diseño detrás de este enfoque, lea diseñar políticas de aplicación para humanos y agentes de IA, y vea el caso de uso para aplicaciones SaaS sobre cómo las políticas se asignan a flujos de producto reales.
Cómo es una buena política para agentes
Una política útil es específica. Nombra una ruta o un flujo de trabajo, una clase de actor, la fuerza de evidencia requerida y la respuesta. Por ejemplo:
- Rutas de catálogo de solo lectura: permita agentes verificados y sirva una respuesta estructurada; permita agentes declarados con el límite de tasa estándar.
- Acciones que cambian la cuenta: mantenga su reautenticación existente para todos; añada revisión cuando el actor sea Unknown y la acción sea de alto impacto.
- Envíos a soporte: acepte contenido con asistencia de IA declarado y etiquételo para su enrutamiento.
- Registro: mantenga las comprobaciones existentes; nunca decida solo a partir de un resultado de actor inferido.
Cada una de estas respuestas actúa sobre el actor sin tratar a cada agente como abuso y sin confiar ciegamente en cada agente. Ese equilibrio es el sentido completo del acceso sensible a agentes, y el artículo sobre diseñar políticas de aplicación para humanos y agentes de IA desarrolla más ejemplos ruta por ruta.
Las cinco respuestas
La capacidad Route de Proof of Actor se basa en cinco respuestas entre las que sus políticas pueden elegir.
Permitir
Haga que la solicitud continúe con normalidad. La mayor parte del tráfico, incluido la mayor parte del tráfico de agentes en rutas públicas o de bajo riesgo, simplemente debe permitirse.
Adaptar
Cambie la experiencia para ajustarla al actor. Sirva una respuesta API estructurada o una versión en Markdown de una página a un agente verificado en lugar de una interfaz con forma humana. La guía sobre servir contenido estructurado a agentes de IA cubre este patrón.
Desafiar
Pida algo más fuerte: un inicio de sesión reciente, una credencial adicional, una confirmación del titular de la cuenta. Use desafíos en rutas donde el coste de una decisión equivocada sea alto.
Revisar
Deje que la acción avance a una cola en lugar de completarse de inmediato, o márquela para que una persona la revise. Revisar es útil cuando bloquear dañaría a usuarios legítimos, pero completar sin supervisión sería demasiado arriesgado.
Limitar
Aplique un límite de tasa o de volumen ajustado al actor y a la ruta, para que los llamadores automatizados no puedan saturar un flujo de trabajo diseñado para personas.
Por qué robots.txt no es una política de acceso
Muchos equipos empiezan con robots.txt, y es una primera señal sensata para rastreadores. No es una política de acceso para agentes. Los operadores de rastreadores documentan comportamientos distintos para distintos user agents: Anthropic indica que sus bots respetan las directivas de robots.txt (documentación del rastreador de Anthropic), mientras que OpenAI señala que para ChatGPT-User, que actúa cuando un usuario hace una pregunta a ChatGPT, las reglas de robots.txt pueden no aplicar porque la acción la inicia un usuario (documentación del rastreador de OpenAI). Robots.txt tampoco dice nada sobre APIs, herramientas MCP o flujos de trabajo con sesión iniciada.
Una política de acceso tiene que ejecutarse donde se procesa la solicitud, leer evidencia como una firma verificada bajo RFC 9421 y elegir una respuesta por ruta. Para MCP servers, la especificación de autorización de MCP define cómo los clientes obtienen access tokens sobre HTTP; las políticas de actor añaden contexto encima de eso, no lo reemplazan.
Cómo Proof of Actor alimenta sus políticas
Cada solicitud que evalúa su integración produce un resultado de actor con cuatro partes que su política puede leer:
- Clase: Human, Human + AI, Agent o Unknown.
- Base: verified, declared, inferred o unknown, para que su política pueda tratar de forma distinta una firma validada y un nombre de cliente autodeclarado.
- Resumen de evidencia: una descripción legible de en qué se basa el resultado, útil para registros y revisión.
- Contexto: qué integración y qué ruta lo produjeron.
Como la base es explícita, sus políticas pueden ser precisas. "Permitir agentes" pasa a ser "permitir agentes verificados en rutas de lectura, limitar la tasa de agentes declarados, aplicar la alternativa de Unknown a todo lo demás". El flujo completo desde la solicitud hasta la decisión se describe en Cómo funciona.
Las alternativas forman parte de la política
Una política solo es tan buena como su comportamiento cuando falta evidencia. Proof of Actor hace explícitos esos casos en lugar de ocultarlos.
- Unknown: la evidencia no permitió una determinación. Su política indica qué significa Unknown en cada ruta. Nunca se convierte en Human ni se trata como malicioso por defecto.
- Timeout: el resultado no llegó a tiempo. Su integración aplica la alternativa que eligió para esa ruta.
- Señales ausentes: un recolector no se ejecutó o faltaba un encabezado. El resultado lo refleja y su política lo trata en consecuencia.
Para cada ruta usted elige si fallar abierto o fallar cerrado. Fallar abierto significa que la solicitud continúa como lo haría sin Proof of Actor; fallar cerrado significa que se aplica su comprobación más fuerte existente. Las rutas de bajo riesgo suelen fallar abierto. Las acciones sensibles suelen fallar cerrado. Usted lo define por nivel de riesgo, no globalmente.
Mantenga separadas identidad, credenciales y autorización
Las políticas de acceso para agentes se sitúan por encima de tres capas distintas, y mantenerlas separadas evita los errores más dañinos.
- La evidencia de identidad responde qué tipo de actor llama y qué lo demuestra. Proof of Actor proporciona esto.
- Las credenciales responden qué cuenta es responsable. Su sesión, token o API key proporciona esto.
- La autorización responde si este llamador puede realizar esta acción. Su modelo de permisos proporciona esto.
Una identidad de agente verificada no significa que el agente esté autorizado, que una persona le haya delegado autoridad o que su acción sea segura. Use los resultados de actor para enrutar y añadir contexto. Use su modelo de autorización para conceder permisos. La página Detección y limitaciones explica con precisión qué puede establecer cada tipo de evidencia.
Despliegue sin romper nada
La forma más segura de introducir políticas de acceso para agentes es por etapas.
- Observe. Instale Proof of Actor en modo de observación. Nada cambia para sus usuarios; los resultados se registran.
- Comprenda. Revise qué actores usan qué rutas, la tasa de Unknown en cada una y cualquier resultado que discrepe de lo que ya sabe.
- Previsualice. Ejecute una política en previsualización y registre lo que habría hecho sin aplicarla.
- Aplique de forma restringida. Habilite la política en una ruta donde la evidencia la respalde claramente. Observe los resultados.
- Amplíe. Extienda a más rutas a medida que crece la confianza.
La guía sobre desplegar políticas sensibles a actores de forma segura recorre cada etapa, y proteger acciones sensibles sin bloquear agentes cubre las rutas de mayor riesgo.
Lo que obtiene su equipo
Con Proof of Actor, su equipo obtiene una integración con tres capacidades. Detect recopila señales de actor y separa afirmaciones verificadas de inferencias. Understand muestra analítica de actores, tendencias y la evidencia detrás de cada resultado, manteniendo visible Unknown. Route le permite escribir las políticas descritas en esta página y aplicarlas donde usted elija. Durante la beta privada, las políticas de enrutamiento se diseñan con cada equipo fundador y se ejecutan en el código de su propia aplicación, para que usted conserve el control total.
Errores habituales de política que debe evitar
Los equipos que diseñan acceso para agentes por primera vez tienden a repetir unos pocos errores. Evitarlos ahorra semanas de trabajo repetido.
- Bloquear todos los agentes por defecto. Entonces los agentes legítimos lo rodean, a menudo raspando la interfaz que usted construyó para personas, que es más difícil de proteger que un camino estructurado.
- Confiar en un nombre declarado. Un cliente que solo se nombra a sí mismo ha hecho una afirmación, no ha aportado prueba. Trátelo como trataría a un llamador no verificado.
- Usar la misma alternativa en todas partes. Unknown en una página pública de precios y Unknown en un cambio de contraseña son situaciones distintas. Cada ruta necesita su propia respuesta.
- Decidir sobre personas a partir de una inferencia. Los resultados de actor son contexto para el enrutamiento, no un veredicto sobre una persona. Mantenga las decisiones con consecuencias en sus propios controles y revisiones.
- Saltar la observación. Aplicar desde el primer día significa descubrir falsos positivos a través de quejas de clientes. Observe primero y después aplique donde la evidencia sea clara.
Una breve revisión de políticas con sus responsables de seguridad, producto y soporte antes de cada paso de aplicación detecta la mayoría de estos casos a tiempo.
Empiece con el programa para desarrolladores fundadores
Proof of Actor está en beta privada. Los equipos de desarrollo fundadores seleccionados pueden recibir hasta 12 months de acceso gratuito, dentro de los límites de uso acordados, con apoyo directo de nuestros ingenieros mientras diseña sus primeras políticas.
Si está decidiendo cómo debe tratar su aplicación a los agentes de IA, solicite acceso anticipado. Díganos qué rutas son más importantes y qué decisiones quiere tomar, y le ayudaremos a construir políticas que encajen. También puede ver cómo se aplica esto a APIs y MCP servers.
Fuentes
- ¿Anthropic rastrea datos de la web y cómo pueden los propietarios del sitio bloquear el rastreador?, Anthropic.
- Resumen de los rastreadores de OpenAI, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Autorización de MCP, modelcontextprotocol.io.