Pruebas, no suposiciones
Intenta forzar la entrada
La solicitud de cualquier agente de IATus datos, tu stock y tu dinero
- 1Agente verificado¿Quién pregunta de verdad?Firmada con la clave propia del agente. Reciente y nunca usada antes.
- 2Tu política¿Qué puede hacer este agente aquí?Tus reglas para este agente y esta acción, dentro del permiso del cliente.
- 3Datos en vivo¿La respuesta es correcta ahora mismo?Precios, stock y descuentos de tus sistemas, nunca del texto de una página.
- 4Aprobación del cliente¿El cliente aceptó exactamente esto?El sí exacto del cliente, el pago confirmado por tu proveedor, un pedido.
Elige un ataque (1 de 8)
El ataque
Un bot dice ser ChatGPT con la esperanza de leer los pedidos y el domicilio de un cliente.
Sin TrueSession
Cualquiera puede escribir “ChatGPT” en una solicitud. Tu web no lo distingue, así que el bot entra.
Con TrueSession: se detiene en el control 1 (Agente verificado)
Los agentes reales firman cada solicitud con una clave que solo tiene quien los creó. Esta firma no coincide, así que se rechaza antes de llegar a ningún dato.
Ningún cerrojo único. Ninguna seguridad es irrompible, así que ningún control se da por bueno por sí solo. Superar uno nunca basta.
Nada casero. Criptografía publicada y probada, y estándares abiertos para agentes en versiones fijas y probadas.
Ante la duda, no. Lo desconocido o poco claro se rechaza, nunca se adivina. Por defecto, no se guardan los prompts de los clientes.
Agentes que se saltan la puerta de entrada. Se detectan por cómo se comportan, se marcan durante toda la visita y se envían a tu dirección para agentes.
Por dentro: cinco pruebas distintas
- Prueba 1
Identidad del agente
Solicitudes firmadas en las que se comprueban la clave, la firma, que sean recientes y que no se repitan. Responde a quién pregunta, nada más.
- Prueba 2
Delegación del cliente
Un permiso finito, con acciones, límites y caducidad, que el cliente eligió y puede revocar.
- Prueba 3
Aprobación exacta
La decisión del cliente, ligada a la cotización exacta y a las condiciones esenciales. Cualquier cambio necesita una nueva aprobación.
- Prueba 4
Resultado del pago
Solo cuenta un resultado verificado del proveedor de pagos. Que un navegador vuelva a una página de pago realizado no cuenta.
- Prueba 5
Confirmación
Una confirmación idempotente en tu backend consume un token de un solo uso, así que un reintento no reserva ni cobra dos veces.
Principios que no negociamos
- Detectar nunca da autoridad
- Las señales de comportamiento pueden limitar el ritmo, pedir una comprobación o redirigir. Nunca pueden aprobar una compra ni desbloquear datos protegidos.
- Controles en código que los agentes no pueden saltarse
- Los efectos con consecuencias los aplican tu backend y la puerta de entrada de TrueSession, no unas instrucciones al agente.
- Los datos de pago quedan en manos humanas
- Ni los agentes ni TrueSession leen, escriben, guardan, registran ni transmiten números de tarjeta ni códigos de un solo uso.
- Si algo falla, se cierra
- Una versión desconocida, la falta de pruebas, un servicio en pausa o un almacenamiento no disponible rechazan el nuevo trabajo protegido en lugar de adivinar.
- Lo que no es fiable sigue sin serlo
- Las páginas web, los documentos y los mensajes de agentes se tratan como datos, nunca como instrucciones que cambien la política o los permisos.
- Datos mínimos, y por separado
- Cada negocio aislado, registros con lista de campos permitidos y, por defecto, sin prompts en bruto. El consentimiento para seguimientos es independiente de la aprobación de compra.
Defensa en profundidad
Funciona en laboratorio funciona de principio a fin en nuestro laboratorioEn laboratorio en nuestro plan: diseñado, en construcción o en pruebas en nuestro laboratorio; aún no disponibleLo que funciona hoy
Nada permitido por defecto
Una solicitud se rechaza salvo que una regla la permita. Decide código sencillo, nunca un modelo de IA.
En laboratorio
Un mínimo que ningún ajuste rebaja
Algunas reglas valen para cualquier negocio: los agentes nunca ven datos de tarjeta, nunca aprueban por un cliente y nunca pagan sin la confirmación del proveedor.
Funciona en laboratorio
Un uso, un pedido
Cada aprobación desbloquea un token de acción, que se usa una sola vez. Cien intentos a la vez siguen dando un solo pedido.
Funciona en laboratorio
Sin contraseñas ni tokens reenviados
Los clientes dan un acceso limitado y con caducidad. Los tokens de los agentes se cambian por otros de corta duración antes de que nada llegue a tus sistemas.
En laboratorio
Un texto no fiable no dirige ninguna acción
Las instrucciones ocultas se detectan antes de llegar a respuestas o herramientas, y una sesión que las leyó no puede actuar sin un nuevo sí.
En laboratorio
Registros que delatan cualquier cambio
Hoy los recibos ya se firman. Después, cada decisión entra en un registro público encadenado, así que cualquier edición posterior se nota.
En laboratorio
Cada negocio, aislado
Los datos de cada negocio están separados en la aplicación y, después, en la propia base de datos.
En laboratorio
Llamadas salientes con correa
Las llamadas a tus sistemas y las respuestas a los agentes salen por una única salida vigilada, con listas de permitidos, límites y sin direcciones internas.
En laboratorio
Probado como infraestructura
Pruebas para cada ataque conocido
Cada regla de seguridad se prueba contra repeticiones, caducidad, revocación, condiciones de carrera y caídas, no solo cuando todo va bien.
Funciona en laboratorio
Un solo efecto, probado bajo presión
En nuestras pruebas de laboratorio, cien intentos a la vez sobre una misma aprobación produjeron exactamente un pedido.
Funciona en laboratorio
Un modelo de amenazas para cada parte
Cada parte nueva se revisa en busca de amenazas de seguridad y privacidad antes de construirla, y la revisión se guarda con sus pruebas.
En laboratorio
Una batería de ataques para agentes
Inyección de prompts, herramientas envenenadas, herramientas que cambian tras la aprobación, tokens reenviados, bucles y suplantación, lanzados contra cada versión.
En laboratorio
Fuzzing en cada analizador
Todo lo que lee datos de fuera, de archivos de API a feeds y páginas web, pasa por fuzzing y tiene una vía de cuarentena.
En laboratorio
El camino del dinero, en un modelo formal
La aprobación, el pago y el pedido se especifican como un modelo formal y se comprueban en cualquier orden de los eventos.
En laboratorio
Claves que rotan
Una clave distinta para cada propósito, rotada según un calendario, con conjuntos de claves publicados para que cualquiera pueda comprobar una firma.
En laboratorio
Pruebas externas antes de los pilotos
Una prueba de penetración independiente, más simulacros de restauración y de rotación de claves, antes de usar datos reales de clientes.
En laboratorio
Agentes ocultos en un navegador
- Paso 1
Detectar
El script del sitio nota cómo se comporta una visita: sin movimiento del puntero, formularios rellenados en milisegundos, páginas abiertas más rápido de lo que nadie lee, rasgos de navegador sin interfaz. Una trampa también ayuda: un enlace que ninguna persona puede ver ni alcanzar, y que robots.txt pide a los bots que eviten.
- Paso 2
Marcar
La marca se guarda en tu servidor, ligada a la visita, así que cada solicitud posterior la lleva. Una copia en el navegador permite que la página reaccione al instante, pero la copia del servidor es la que cuenta.
- Paso 3
Dirigir
Las páginas marcadas muestran una nota breve escrita para agentes, con enlaces legibles por máquinas a tu tarjeta de agente: “¿Eres un agente de IA? Usa agent.tutienda.com.” Los agentes que leen páginas la siguen hasta tu ruta oficial.
- Paso 4
Proteger
Tu política decide qué cambia una marca: navegar más despacio, una comprobación extra al iniciar sesión o que el cliente confirme la compra en su propio dispositivo. Las páginas públicas siguen siendo legibles.
- Paso 5
Ver
Tu panel muestra las visitas marcadas, qué intentaron y cuántas pasaron a tu dirección para agentes.
¿Por qué no guardar la marca en el almacenamiento local?
El almacenamiento local vive en el navegador del visitante, así que un bot puede leerlo, falsificarlo o borrarlo. La marca que cuenta vive en tu servidor. Para perderla, un bot tiene que tirar toda la visita, con su carrito, sus reservas y su sesión iniciada, y la nueva visita vuelve a marcarse en cuanto se comporta igual.
Nunca un bloqueo solo por el comportamiento
Las personas que usan lectores de pantalla, control por voz, autocompletado o gestores de contraseñas también pueden parecer automáticas. Por eso una marca puede dirigir una visita, frenarla o pedir una comprobación, pero nunca bloquea a nadie por sí sola ni desbloquea nada. Solo tu política y la aprobación del cliente pueden hacerlo.
Basado en estándares abiertos
- RFC 9421
- HTTP Message Signatures para la integridad de las solicitudes
- RFC 9530
- Campos de resumen (digest) para la integridad del contenido
- Web Bot Auth
- Borrador del IETF para agentes y rastreadores de IA firmados
- Perfil de OAuth
- RFC 9700, 9396, 9126, 9449, 8705, 8707, 8693 y 9728
- A2A, UCP y MCP
- Protocolos abiertos de agentes, comercio y herramientas en versiones fijadas
- Archivos para rastreadores y agentes
- robots.txt (RFC 9309), Content Signals, los borradores del IETF sobre preferencias de IA, RSL, llms.txt y el borrador de AI Catalog, compilados por Discover (en laboratorio)
Lo que no vamos a afirmar
- Nadie puede identificar a cada visitante. Un agente dentro de la propia sesión del navegador de un cliente puede ser idéntico a ese cliente; por eso las acciones con consecuencias exigen la aprobación del cliente, se detecte o no.
- Las páginas que decides mantener públicas siguen siendo legibles para cualquiera, incluidos agentes y buscadores.
- Un script en el navegador no puede hacer cumplir nada por sí solo. Los datos protegidos necesitan el control en el servidor o en el borde de la red.
- El comportamiento es una pista, no una prueba. Una marca puede dirigir una visita, frenarla o pedir una comprobación, pero por sí sola nunca bloquea a nadie ni desbloquea nada.
¿Quieres los detalles? Lee cómo impedir que los agentes actúen sin aprobación.
Únete al piloto