Frena las acciones no aprobadas

El problema: acciones que nadie aprobó

Un agente de IA que actúa por un cliente puede buscar, comparar, llenar carritos, reservar viajes y, cada vez más, pagar. Es útil hasta que el agente hace algo que el cliente no pidió: otra tarifa, una cantidad mayor, un beneficiario nuevo, una mejora con un contrato más largo. La causa puede ser una instrucción mal interpretada, un precio desactualizado o una página web que, sin que nadie lo viera, le dijo al agente qué hacer.

Cuando eso ocurre, el cliente reclama el cargo y el negocio asume el coste y la carga de atención al cliente. Los bancos sufren la versión más grave del problema, porque una transferencia al beneficiario equivocado es difícil de revertir. La pregunta de fondo es la misma en todas partes: ¿aprobó de verdad el cliente exactamente esta acción?

Los reguladores también se la hacen. Christopher Waller, gobernador de la Reserva Federal, señaló la autenticación, la responsabilidad y el fraude como las barreras para escalar el comercio agéntico, y preguntó: “¿Quién responde si un agente hace la compra equivocada?” (Federal Reserve, Sep 2026). Akamai informa de que los atacantes ya secuestran asistentes de IA legítimos para abusar de credenciales de pago guardadas (Akamai vía GlobeNewswire, Jul 2026).

Por qué no basta con detectar bots

La mayoría de los negocios recurre primero a la detección de bots. Ayuda, pero no puede cargar con todo el peso, por tres motivos.

• Muchos agentes nunca ejecutan el código de tu página. Los agentes que llaman a una API o descargan páginas directamente nunca ejecutan un script del navegador, así que un script no puede verlos ni frenarlos.
• Algunos agentes parecen exactamente tu cliente. Un agente que trabaja dentro del navegador del propio cliente, con su sesión iniciada, comparte sus cookies, su dispositivo y su red. Ningún detector puede distinguirlos de forma fiable.
• La detección es una probabilidad, no un permiso. Una puntuación de bot muy segura no dice nada de lo que quería el cliente. Tratarla como autorización bloquea a buenos clientes y aun así deja pasar la automatización cuidadosa.

La detección es una señal útil para encaminar el tráfico y limitar la frecuencia de solicitudes. Es la herramienta equivocada para decidir si una compra o una transferencia debe ocurrir.

Protege las acciones, no solo las páginas

La respuesta duradera es que cada acción con consecuencias demuestre cuatro cosas distintas, en código que el agente no puede saltarse:

1. Quién es el agente. El agente firma sus solicitudes, por ejemplo con HTTP Message Signatures (RFC 9421) o con el enfoque emergente IETF Web Bot Auth, y se comprueba que la firma sea reciente y no se haya reutilizado. Ese charter deja explícitamente fuera de su alcance la autenticación del usuario final, así que la identidad es solo la primera prueba.
2. Qué delegó el cliente. Un permiso finito y revocable enumera las acciones permitidas, los límites y la caducidad. La identidad, por sí sola, no concede nada.
3. Qué permiten tus reglas ahora mismo. Deciden tu política y el estado de tu servicio actuales, no una respuesta en caché de ayer.
4. Que el cliente aprobó exactamente esto. El cliente aprueba el artículo, el precio y las condiciones exactos, en una página que el agente no puede rellenar. Si cambia algo importante, vuelve a aprobar.

Con estos controles, ni siquiera un agente que nunca detectaste puede completar una compra o una transferencia por su cuenta. Puede pedirlo; solo el cliente puede decir que sí.

Da a los agentes una ruta oficial

Bloquear a todos los agentes aleja a compradores legítimos y te deja sin ver la demanda. Un patrón mejor es dar a los agentes una única entrada oficial y gobernada, por ejemplo agent.yourstore.com, y hacerla cumplir allí donde llegan de verdad las solicitudes:

• Descubrimiento. Un script de entrada, robots.txt y documentos de descubrimiento en rutas well-known indican a los agentes que cooperan dónde está la ruta oficial.
• Control en el servidor y en el borde. Una puerta en tu CDN o en tu servidor de origen solo entrega datos protegidos con permisos firmados y de corta duración, y redirige o bloquea las solicitudes que no los tienen.
• Control en el backend. Las reservas provisionales, los pedidos, las transferencias y los cambios de cuenta exigen delegación y aprobación exacta en tus propios sistemas.

Mantén las credenciales de pago lejos de los agentes

Un agente nunca debe leer, escribir, guardar ni transmitir un número de tarjeta o un código de un solo uso. El pago corresponde a una página alojada para el cliente humano. Que un navegador vuelva a una página de éxito no demuestra el pago; solo lo demuestra el resultado verificado del proveedor de pagos.

Lista de control para comercios y bancos

• Separa la identidad del agente, la delegación del cliente, la aprobación, el pago y la confirmación final en controles distintos.
• Vincula la aprobación a las condiciones exactas y exige una nueva aprobación cuando cambien condiciones importantes.
• Haz cumplir el acceso a los datos protegidos en tu servidor o en el borde de tu CDN, no solo en el código del navegador.
• Usa las señales de bots y de automatización para encaminar y limitar la frecuencia, nunca para autorizar.
• Mantén el pago en una página solo para personas, y confía solo en resultados de pago verificados.
• Haz que cada efecto sea idempotente, para que los reintentos nunca cobren ni reserven dos veces.
• Registra cada paso para que las disputas se resuelvan con pruebas y no con suposiciones.

Cómo ayuda TrueSession

TrueSession reúne estos controles en una sola capa de confianza: un endpoint oficial para agentes, un intercambio inicial verificado, tus reglas de acceso, la aprobación exacta del cliente y un paso de pago solo para personas, con una consola para verlo y gestionarlo todo. Los flujos principales funcionan hoy en nuestro laboratorio, y estamos preparando los primeros pilotos. Mira cómo funciona o lee el modelo de seguridad.