Prevención del fraudeFraude de agentes de compra con IA en el checkout: cómo frenar el fraude de bots por IP sin bloquear ventas reales
Fraude de agentes de compra con IA en el checkout: una dirección verificada de ChatGPT-User obtuvo 0 y un servidor en la nube corriente 10 en nuestras consultas. Verifica el agente y luego puntúa la IP.
Tu tráfico de checkout con mejor conversión y tu fraude más caro llegan ahora desde el mismo tipo de redes. Adobe constató que el tráfico de IA a sitios de retail de EE. UU. "convirtió un 42% mejor" que los visitantes humanos en marzo de 2026, un año después de convertir un 38% peor (datos de Adobe vía TechCrunch). Mientras tanto, el tráfico automatizado superó el 53% de todo el tráfico web en 2025 (Imperva 2026 Bad Bot Report).
HUMAN Security informa de que "el 2,3% de la actividad agéntica se produce ya en páginas de checkout", y de que "solo medio punto porcentual separa" la tasa de automatización benigna de la de automatización maliciosa (HUMAN, marzo de 2026). El comportamiento por sí solo no basta para separarlos.
A continuación tienes cuatro consultas reales, por qué la comparación del User-Agent te corresponde a ti y un mapa de puntuación a acción que conserva las ventas reales de agentes.
Por qué bloquear IP de centros de datos y de proxy en el checkout falla en ambos sentidos
Un bloqueo general de centros de datos falla porque deja escapar fraude y, a la vez, sale caro. Deja escapar fraude porque los ataques caros no necesitan una dirección de centro de datos. HUMAN dice que "el volumen de carding se ha disparado un 250% desde 2022" y que "los intentos de compromiso de cuentas tras el inicio de sesión se multiplicaron por más de cuatro interanualmente" (HUMAN). GeoIPHub no detecta proxies residenciales, así que el fraude desde conexiones domésticas tienen que detectarlo tus datos de velocidad y de pagos. Nuestro artículo sobre el fraude con proxies residenciales explica por qué.
Sale caro porque afecta a personas a las que quieres vender:
- Los agentes reales funcionan en redes en la nube. La dirección verificada de ChatGPT-User que verás más abajo está en el AS8075 de Microsoft y se marca como
datacenter_ip. - Los usuarios de Apple iCloud Private Relay comparten direcciones de salida de relé que funcionan en redes asociadas como Cloudflare.
- El NAT de nivel de operador (CGNAT) coloca a muchos abonados detrás de una sola dirección. RFC 6598 reserva
100.64.0.0/10como espacio de direcciones compartido para ello. Cloudflare midió que "las IP de CGNAT sufren limitación de tasa tres veces más a menudo que las IP que no son de CGNAT", mientras que la tasa media de bots era menor en las direcciones de CGNAT, un 7% frente a un 13,1% (Cloudflare).
Así que el tipo de conexión es una entrada ponderada, nunca un rechazo automático. Nuestra guía central sobre detección de bots por IP muestra lo que cada indicador de IP puede y no puede demostrar, con cinco consultas reales.
Cuatro clientes en el checkout, cuatro consultas: lo que vimos el 23 de octubre de 2026
Una dirección de agente verificada obtiene 0 y allow, y lo mismo ocurre con casi cualquier servidor en la nube. Hicimos cuatro consultas sin clave entre las 05:03:52 y las 05:04:07 UTC del 23 de octubre de 2026, con 5 segundos de diferencia entre cada una:
- ChatGPT-User:
104.208.184.193, el primer host de104.208.184.192/28, el primer prefijo del chatgpt-user.json de OpenAI. Descargamos el archivo a las 05:03 UTC. Incluía 234 prefijos IPv4, ninguno IPv6, con uncreationTimedel 20 de octubre de 2026. - Fetcher de Google activado por usuarios:
107.178.192.1, dentro de107.178.192.0/27en eluser-triggered-fetchers.jsonde Google. - Servidor en la nube corriente:
45.33.32.156,scanme.nmap.org, un host público de pruebas en Linode. No es un agente. - iCloud Private Relay:
104.28.46.99, una dirección de salida de relé de Apple en Cloudflare.
| Cliente | crawler.verified / name / category | fraud_score | recommended_action | Decisión de checkout |
|---|---|---|---|---|
ChatGPT-User, 104.208.184.193 | true / ChatGPTUser / ai | 0 | allow | Respetarlo como agente del comprador |
Fetcher de Google, 107.178.192.1 | true / GoogleUserTriggeredFetcher / fetcher | 0 | allow | Respetarlo |
Servidor en la nube, si dijera ser un agente, 45.33.32.156 | false / none / none | 10 | allow | Verificación adicional |
Private Relay, 104.28.46.99 | false / none / none | 9 | allow | Respetarlo |
Esta es la consulta de ChatGPT-User, recortada, con el anidamiento conservado y los valores sin editar:
{
"ip": "104.208.184.193",
"asn": {
"asn": 8075,
"org": "MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation",
"asn_type": "hosting",
"connection_type": "datacenter"
},
"detection": {
"is_hosting": true
},
"threat": {
"is_crawler": true,
"crawler": {
"verified": true,
"name": "ChatGPTUser",
"operator": "OpenAI",
"category": "ai",
"verification_method": "ip_range_list"
}
},
"scoring": {
"fraud_score": 0,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"]
}
}
Se activaron dos señales de hosting, datacenter_ip y no_ptr_datacenter. La señal exculpatoria verified_crawler llevó el total a 0. Esta dirección no tiene DNS inverso, ni en vivo ni almacenado, así que el archivo de rangos de OpenAI es la única prueba. El fetcher de Google muestra el mismo patrón con 0, salvo que su nombre de host sí resuelve, así que se activa rdns_hosting en lugar de no_ptr_datacenter.
El servidor en la nube es la fila que importa. Su 10 procede únicamente de datacenter_ip, dentro de la banda allow (25 o menos). Si esa petición hubiera llegado con un User-Agent ChatGPT-User, la puntuación seguiría diciendo allow. Solo verified: false y name: "none" muestran que la declaración es falsa. Por eso la columna de decisión dice verificación adicional, no allow.
La dirección de relé obtuvo 9 con relay_ip como único método. Los relés tienen un tope de 60, así que un usuario de Private Relay nunca puede llegar a block. Nuestra geolocalización dice Luanda, Angola, pero el feed de salidas de Apple decía Lusaka, Zambia, cuando lo comprobamos el 12 de octubre de 2026, así que evalúa a los usuarios de relés por país.
A las 05:09 UTC también consultamos 136.121.16.1, el primer host IPv4 del user-triggered-agents.json de Google. Ese archivo cubre Google-Agent, que según Google "lo usan agentes alojados en la infraestructura de Google para navegar por la web y realizar acciones a petición del usuario" (Google). Volvió verificado como GoogleUserTriggeredAgent, puntuación 0, allow. También activó fcrdns_mismatch, aunque un dig en vivo confirma su nombre de host con la consulta directa. Es un bug nuestro; no movió la puntuación y lo hemos registrado.
Son cinco consultas en una sola mañana, no un benchmark. Los rangos cambian, así que repítelas antes de copiar un valor.
La comparación del User-Agent es trabajo de tu código, no de la API
La API demuestra qué bot es dueño de una dirección, y tu código demuestra que la petición declaró ser ese mismo bot. Una consulta de IP nunca ve el User-Agent, así que GeoIPHub no puede marcar por sí solo un agente suplantado. Tu manejador de checkout tiene la cabecera y es quien debe compararla.
Los nombres difieren entre ambos lados. El token de User-Agent de OpenAI es ChatGPT-User, y la API devuelve ChatGPTUser sin guion. El token de Google es Google-Agent, y la API devuelve GoogleUserTriggeredAgent. Una comparación literal de cadenas falla, así que mantén un pequeño mapa:
// User-Agent token mapped to threat.crawler.name as the API returns it (seen 2026-10-23)
const AGENT_NAMES = {
"ChatGPT-User": "ChatGPTUser",
"Google-Agent": "GoogleUserTriggeredAgent",
};
// Returns null when the request makes no agent claim,
// true when the claim matches a verified range, false when it doesn't.
function agentClaimHolds(userAgent, lookup) {
const token = Object.keys(AGENT_NAMES).find((t) => userAgent.includes(t));
if (!token) return null;
const c = lookup.threat.crawler;
return c.verified === true && c.name === AGENT_NAMES[token];
}
Un resultado false corresponde a la fila del servidor en la nube de arriba: pide una verificación adicional o recházalo, sea cual sea la puntuación. La aplicación completa en nginx y Express, con una prueba de GPTBot suplantado, está en nuestra guía sobre si bloquear los rastreadores de IA.
Verifica la firma del agente antes de puntuar su IP
Una credencial de protocolo o una firma válidas pesan más que cualquier señal de IP. Tres mecanismos responden a "quién envió esto" con más firmeza que un archivo de rangos.
Agentic Commerce Protocol (ACP). Stripe anunció ACP el 29 de septiembre de 2025 como un estándar abierto "desarrollado conjuntamente por Stripe y OpenAI"; el repositorio de la especificación tiene licencia Apache-2.0. Su RFC de Agentic Checkout marca como obligatorios un token bearer Authorization, API-Version y, en cada POST, Idempotency-Key, y recomienda Signature y Timestamp. Stripe dice que sus Shared Payment Tokens "están limitados a un comerciante concreto y al importe total del carrito", lo que restringe lo que se puede comprar con un token robado.
Web Bot Auth. Los agentes firman cada petición según RFC 9421 HTTP Message Signatures (Standards Track, febrero de 2024). El artículo de Cloudflare sobre Web Bot Auth usa las cabeceras Signature, Signature-Input y Signature-Agent y claves Ed25519 publicadas por el firmante.
Programas de agentes de las redes de tarjetas. Visa creó su Trusted Agent Protocol "en colaboración con Cloudflare" sobre el estándar HTTP Message Signature, para distinguir a los agentes de confianza "de la automatización maliciosa y los bots descontrolados" (Visa, 14 de octubre de 2025). El anuncio de Cloudflare del mismo día dice que "Mastercard está incorporando Web Bot Auth a Mastercard Agent Pay".
En una llamada ACP, el RFC indica que es ChatGPT quien llama a tus endpoints de checkout, así que la IP de conexión pertenece a la plataforma del agente, no al comprador. Verifica la credencial en ese carril y reserva la puntuación de IP para el tráfico web directo. Nuestra guía para verificar rastreadores y agentes de IA por IP, rDNS y Web Bot Auth recorre cada comprobación.
Por qué las listas de IP permitidas por sí solas son frágiles, incluso para agentes reales
Una lista de permitidos mantenida a mano se rompe porque las direcciones de los agentes se comparten y cambian constantemente. Cloudflare lo dice claramente: "la lógica de que unos rangos de direcciones IP representen a un producto o a un grupo de usuarios es frágil". Añade que las conexiones "pueden ser compartidas por varios usuarios, como en el caso de los proxies de privacidad y las VPN", y que los rangos en la nube "cambian con el tiempo" (Cloudflare).
El propio archivo de OpenAI muestra la deriva:
| Fecha de descarga | Prefijos IPv4 en chatgpt-user.json | creationTime |
|---|---|---|
| 2026-10-06 | 230 | 2026-09-25 |
| 2026-10-23 | 234 | 2026-10-20 |
El recuento del 6 de octubre de 2026 procede de nuestra comparación de GPTBot, OAI-SearchBot y ChatGPT-User. OpenAI también dice de ChatGPT-User que "como estas acciones las inicia un usuario, es posible que las reglas de robots.txt no se apliquen" (OpenAI).
Nuestro lado también tiene retraso. GeoIPHub vuelve a descargar 19 archivos oficiales de rangos y reconstruye su base de datos de consultas a diario, así que un prefijo nuevo puede tardar hasta unos dos días en verificarse. Trata una coincidencia de rango como una corroboración fuerte y da preferencia a una firma cuando el agente la envíe.
Fraude de agentes de compra con IA: las amenazas en el paso de pago
Tres ataques impulsan el fraude de agentes de compra con IA en el checkout, y ninguno se parece a un pedido legítimo de un agente: un carrito para un comprador.
- Card testing (enumeración). Ráfagas de intentos pequeños o de solo autorización con altas tasas de rechazo. Visa dice que los ataques de enumeración causan "1.100 millones de dólares anuales en pérdidas por fraude", y que "el treinta y tres por ciento de las cuentas enumeradas sufrieron fraude en un plazo de cinco días" (Visa, mayo de 2024).
- Toma de control de cuentas. Credenciales robadas usadas para comprar con tarjetas guardadas. Imperva dice que los servicios financieros concentraron "el 46% de los incidentes de toma de control de cuentas" (Imperva 2026). Nuestra guía de defensa contra la toma de control de cuentas cubre el lado del inicio de sesión.
- Scalping. Bots que acaparan existencias limitadas en lanzamientos de alta demanda.
El card testing repartido entre muchas direcciones supera a un contador por IP, así que cuenta también los rechazos y las tarjetas distintas por ASN y por BIN.
Asigna la puntuación de 0 a 100 a una acción de checkout
Una puntuación de 0 a 100 solo es útil en el checkout cuando cada banda corresponde a una acción fija. La puntuación de riesgo explicable de GeoIPHub cubre las entradas del lado de la IP, y scoring.detection_methods nombra cada señal que se activó. Tu código y tus datos de pago aportan el resto:
| Entrada | Efecto en la decisión |
|---|---|
| Credencial ACP o firma Web Bot Auth válida | Carril de confianza, poca fricción |
crawler.verified true y el nombre coincide con el User-Agent | Anula las señales de hosting |
| User-Agent de agente sin coincidencia verificada | Verificación adicional o rechazo, sea cual sea la puntuación |
Red de hosting (datacenter_ip) | Subida pequeña, 10 por sí sola hoy |
| VPN o salida de Tor | Subida grande, a menudo block |
Relé (relay_ip) | Subida pequeña, con tope de 60 |
| Velocidad de tarjetas, BIN y rechazos por IP y por ASN | Subida grande |
| El país de la IP difiere del país de facturación | Subida, evaluada a nivel de país |
Después asigna las bandas a acciones:
| Banda | Puntuación | Acción de checkout |
|---|---|---|
allow | 0 a 25 | Dejar pasar, salvo que una declaración de agente no superase la verificación |
review | 26 a 50 | 3-D Secure |
step_up | 51 a 75 | 3-D Secure, más una comprobación de velocidad |
block | 76 a 100 | Rechazar o retener para revisión manual |
Los topes mantienen las direcciones compartidas fuera de block. Una dirección de relé tiene un tope de 60, así que no puede rechazarse solo por la puntuación, y se aplica un tope de 50 a las direcciones que la API identifica como NAT de nivel de operador. ACP también incluye su propia señal de card testing: el RFC de delegate-payment envía risk_signals de tipo card_testing con una acción blocked, manual_review o authorized. La plataforma del agente es quien la rellena; tu puntuación sigue siendo una comprobación aparte. Nuestro artículo sobre los umbrales de puntuación de fraude de IP para inicio de sesión, registro y checkout pone a prueba estas bandas con cinco direcciones más.
Escala, no bloquees: 3-D Secure traslada la responsabilidad
Envía las bandas intermedias a 3-D Secure en lugar de rechazarlas, porque una verificación adicional conserva la venta y normalmente traslada el riesgo de contracargo. La guía de responsabilidad de 3-D Secure v2 de Trust Payments dice que, tras una autenticación correcta, "el emisor de la tarjeta será responsable en caso de un contracargo fraudulento en la mayoría de los casos". También advierte de que "la autenticación correcta de una transacción no garantiza el traslado de responsabilidad ni una autorización correcta".
Una verificación adicional da a un comprador real una forma de pasar y obliga a quien hace card testing a demostrar que tiene la tarjeta. Nuestra guía sobre los falsos positivos en la detección de VPN explica quién más cae en esa banda intermedia.
La cuestión del agente autorizado es jurídica, no técnica
La pregunta más difícil es si el agente puede comprarte en absoluto. El 9 de marzo de 2026, el Tribunal de Distrito de EE. UU. para el Distrito Norte de California concedió a Amazon una medida cautelar contra Perplexity. The Register informa de que la jueza escribió que el agente Comet de Perplexity "accede con el permiso del usuario de Amazon pero sin la autorización de Amazon" (The Register). Perplexity recurrió, y el 4 de agosto de 2026 el Noveno Circuito anuló la medida cautelar y devolvió el caso al tribunal de distrito, donde sigue abierto.
Esa resolución no zanjó la cuestión. Las comprobaciones de IP te dicen quién envió la petición. Tus condiciones de servicio dicen si ese remitente puede comprar.
Dónde fallan las comprobaciones de IP en el checkout
Las señales de IP cubren solo una parte del panorama del checkout, y estas son las lagunas conocidas:
- Sin detección de proxies residenciales. El fraude desde conexiones domésticas necesita tus datos de velocidad y de pagos.
- Sin visibilidad del User-Agent. La API nunca marca un agente suplantado; lo hace la comparación de nombres en tu código.
- Retraso en los rangos y lagunas de DNS. Un prefijo nuevo puede tardar unos dos días en verificarse, y esta mañana vimos un
fcrdns_mismatchfalso. - Hoy el NAT de nivel de operador no se marca por rango. Cuando consultamos
100.64.0.1el 22 de octubre de 2026, no volvió marcada como CGNAT. No construyas todavía una regla sobre ese indicador.
Después de cualquier cambio de reglas, sigue los falsos positivos por segmento, como iOS Safari, operadores móviles y Private Relay. Nuestra nota sobre qué tan precisa es realmente la geolocalización IP explica por qué el país es más fiable que la ciudad.
Llévalo a tu manejador de checkout
Intégralo en el servidor, en el endpoint de checkout, en cuatro pasos:
- Verifica primero cualquier credencial ACP o firma Web Bot Auth, y da a una válida el carril de confianza.
- Consulta la IP de conexión, como en nuestra guía para añadir detección de fraude por IP a tu aplicación con la API gratuita.
- Aplica el mapa de User-Agent contra
threat.crawler.name. Una declaración de agente fallida recibe una verificación adicional o un rechazo. - Asigna
scoring.recommended_actiona la tabla de bandas y añade encima tu velocidad de tarjetas y de ASN.
Cuando una decisión parezca incorrecta, usa los pasos de cómo investigar una dirección IP para ver por qué. Empieza con una dirección de tus propios logs de checkout que dijera ser ChatGPT-User esta semana. Consúltala y compara crawler.name con lo que declaraba.
Preguntas frecuentes
¿Debo bloquear todas las IP de centros de datos o de proxy en el checkout para frenar a los bots?
No. Los agentes reales funcionan en redes en la nube: el 23 de octubre de 2026, una dirección verificada de ChatGPT-User en el AS8075 de Microsoft obtuvo 0, allow. Los bloqueos generales también rechazan a usuarios de Private Relay y de NAT de nivel de operador. Pondera el hosting en la puntuación y envía las bandas intermedias a 3-D Secure.
¿Cómo distingo un agente de compra con IA legítimo de un bot fraudulento en el paso de pago?
Verifica primero la identidad: una credencial ACP o una firma Web Bot Auth según RFC 9421. Si no la hay, consulta la IP, que devuelve threat.crawler.verified y el nombre del bot, y haz que tu código compare ese nombre con el User-Agent que declaró la petición.
¿Por qué una lista de IP permitidas por sí sola es frágil para los agentes de IA?
Cloudflare señala que las conexiones de un servicio de rastreo pueden compartirse, como ocurre con los proxies de privacidad y las VPN, y que los rangos en la nube cambian con el tiempo. El chatgpt-user.json de OpenAI pasó de 230 a 234 prefijos IPv4 entre nuestras descargas del 6 y del 23 de octubre de 2026.
¿Cómo debe traducirse una puntuación de riesgo de IP de 0 a 100 en una decisión de checkout?
Deja pasar allow (25 o menos), envía review (50 o menos) y step_up (75 o menos) a 3-D Secure, y rechaza o retén block (más de 75). Una declaración de agente que no supera la verificación recibe una verificación adicional sea cual sea la puntuación.
¿Pedir 3-D Secure perjudica más la conversión que bloquear?
Un bloqueo pierde la venta con seguridad; una verificación adicional da a un comprador real una forma de pasar. Trust Payments afirma que, tras una autenticación correcta, el emisor es responsable de un contracargo fraudulento en la mayoría de los casos, aunque no está garantizado.
¿Es legal impedir que los agentes de IA compren en mi tienda?
Depende de la autorización, y esto no es asesoramiento jurídico. En marzo de 2026, un tribunal federal concedió a Amazon una medida cautelar contra Perplexity, cuyo agente Comet, según la jueza, accedía a Amazon con el permiso del usuario pero sin la autorización de Amazon. El Noveno Circuito anuló esa medida cautelar en agosto de 2026, y el caso sigue abierto.
El equipo detrás de la API de GeoIPHub
Escrito por el equipo de GeoIPHub, las personas que crean la API de inteligencia IP de GeoIPHub y su escáner. Los borradores se preparan con ayuda de IA y el equipo los edita; los ejemplos de la API son consultas reales contra la API en producción, salvo que se indique que son ilustrativos.
Seguridad de red
Inteligencia IP