Simon Willison expone el conflicto detrás del acceso económico mediante relés de LLM

Simon Willison ha puesto el foco en un mercado de relés donde el acceso con descuento a LLM puede depender de credenciales compartidas, bots expuestos y fraude en los pagos. Su publicación del 26 de julio dirige a los lectores a una investigación del ingeniero de software Matt Lenhard. Esa investigación describe una cadena de suministro comercial que presta servicio a desarrolladores, startups y otros compradores, principalmente a través de comunidades en chino.

El conflicto no es simplemente entre las API oficiales y competidores más baratos. Se trata de la tensión entre una tecnología de gateway legítima y un mercado de reventa cuyos operadores pueden ocultar el origen de su capacidad de cómputo. Los compradores ven un único endpoint compatible y una facturación conveniente. No pueden verificar fácilmente si el acceso ascendente se adquirió de forma legítima, se extrajo de otra aplicación o se obtuvo mediante cuentas fraudulentas.

Esa incertidumbre presiona a tres grupos a la vez. Los proveedores de modelos absorben el uso no autorizado y las devoluciones de cargos. Los desarrolladores de aplicaciones afrontan el riesgo de que los endpoints expuestos se conviertan en inventario para relés. Los compradores envían prompts, código fuente y datos empresariales a través de intermediarios cuya identidad y prácticas de datos pueden no estar claras.

Simon Willison puso a la vista una economía oculta de relés

El cambio importante es la visibilidad: un problema de abuso disperso ahora parece un mercado organizado, con proveedores especializados, infraestructura y clientes.

Willison no llevó a cabo la investigación de campo original. Su advertencia sobre los relés amplificó los hallazgos de Lenhard y los vinculó con un problema práctico al que se enfrentan los desarrolladores de aplicaciones. Una función de LLM expuesta ya no atrae solo abuso oportunista. Puede alimentar un negocio posterior diseñado para monetizar el acceso no autorizado.

Lenhard publicó su investigación el 28 de junio tras examinar un foro en chino donde los operadores hablaban sobre terminología y métodos de relés. Afirma que su interés comenzó mientras trabajaba en un gateway de IA que sufría repetidos abusos de créditos gratuitos y bots de soporte. Las conversaciones con otras empresas le convencieron de que el patrón iba más allá de un único servicio.

La fuente principal del informe fue un foro activo entre el 5 de marzo y el 23 de junio. Según Lenhard, el debate atrajo unas 35.000 visualizaciones y 190 respuestas. Estas cifras muestran interés dentro de una comunidad, aunque no establecen el tamaño total del mercado más amplio.

Un relé, a veces denominado estación de transferencia, ofrece a los clientes un endpoint de API que se asemeja a la interfaz de un gran proveedor de modelos. Los clientes cambian la URL base de una aplicación y envían una credencial emitida por el relé. El relé reenvía entonces cada solicitud a una cuenta ascendente o a otro intermediario.

Este diseño oculta una complejidad considerable. Un cliente ve un nombre de modelo conocido, saldo de uso y formato de solicitud. Detrás de esa interfaz, el operador puede rotar credenciales, sortear límites de tasa, reintentar llamadas fallidas o asignar un modelo solicitado a otro distinto.

Lenhard describe cuatro grandes capas. Los comerciantes de tarjetas y cuentas obtienen instrumentos de pago o cuentas registradas. Los grupos de cuentas combinan credenciales y gestionan sus límites. Los relés orientados al consumidor empaquetan esa capacidad en un servicio conveniente. Los desarrolladores y usuarios comerciales compran el acceso resultante.

Estas funciones pueden solaparse. Un operador puede controlar tanto el grupo de cuentas como la tienda. Otro relé puede comprar capacidad de un grupo independiente sin conocer el origen de cada credencial. Esa separación hace más difícil rastrear la responsabilidad cuando un proveedor detecta abusos.

El mercado también parece contar con infraestructura de consumo más allá de los vendedores individuales. Lenhard informa de sitios de comparación de precios, programas de afiliados, grupos de atención al cliente y productos de gateway especializados. Afirma que los diez relés más activos rastreados por su equipo recibieron 3,6 millones de visitas mensuales combinadas.

Esta estimación de tráfico procede de la investigación de Lenhard y debe tratarse como una medición atribuida. No muestra cuántos visitantes se convirtieron en clientes de pago. Tampoco permite distinguir entre acceso legítimo y acceso suministrado en última instancia mediante fraude.

Aun así, la infraestructura circundante importa. Los sitios de comparación y los programas de afiliados reducen el esfuerzo necesario para encontrar un relé. El software estandarizado reduce el esfuerzo necesario para operar uno. Los grupos de cuentas reducen el daño cuando deja de funcionar cualquier credencial ascendente individual.

Por eso merece atención la intervención de Willison. Reformuló el mercado de relés como un problema de seguridad de aplicaciones, no simplemente como una disputa sobre precios de modelos o disponibilidad geográfica. Cualquier producto que exponga inferencia costosa puede convertirse en un proveedor involuntario.

La lección más contundente también es la más sencilla. Un endpoint de LLM no necesita revelar la clave de su proveedor para generar riesgo. Si terceros pueden enviar solicitudes sin medición a través de él, el propio endpoint se convierte de hecho en una credencial reutilizable.

Los tokens baratos generan presión en toda la cadena de suministro de IA

La demanda de relés convierte cada control de gasto débil, chatbot abierto y aplicación mal protegida en inventario potencial.

La presión más inmediata recae sobre los proveedores de modelos y las empresas que pagan sus facturas. Las pruebas gratuitas crean un canal de adquisición de clientes, pero los registros automatizados pueden convertir esos créditos en capacidad para reventa. Las devoluciones de cargos pueden trasladar costes de inferencia ya consumidos de vuelta a proveedores o comerciantes.

Las tarjetas robadas crean una forma más directa de pérdida. La cuenta puede permanecer activa el tiempo suficiente para que un relé consuma la capacidad disponible. Para cuando el titular de la tarjeta o el emisor impugna las transacciones, la salida del modelo ya se ha entregado aguas abajo.

Las tarjetas prepago y virtuales complican las decisiones de riesgo sin demostrar por sí mismas una conducta indebida. Muchos clientes legítimos utilizan ambos productos. Por tanto, los proveedores deben combinar señales de pago con la antigüedad de la cuenta, el comportamiento de las solicitudes, la información del dispositivo y los patrones de red.

Las empresas de aplicaciones afrontan un problema distinto. Un asistente público de soporte, una función de redacción o un endpoint de análisis de documentos puede reenviar solicitudes mediante una cuenta controlada por la empresa. Si ese endpoint carece de autenticación o límites estrictos, un atacante puede integrarlo en otro servicio.

El atacante no necesita extraer la clave subyacente. En su lugar, reproduce el formato de solicitud de la aplicación y envía prompts no relacionados a través de su backend. La aplicación se convierte en un proxy mientras su propietario recibe la factura.

Willison afirma que esta posibilidad le hace ser más cauteloso al publicar sus propias aplicaciones respaldadas por LLM. Quiere controles del lado del proveedor que detengan una aplicación cuando el gasto alcance un umbral definido por el desarrollador. Las alertas son útiles, pero una alerta que llega después de un pico no evita la pérdida.

Esta preocupación crece a medida que los agentes de IA aumentan el volumen y la concurrencia de solicitudes. Un chatbot interactivo puede enviar una solicitud tras una acción del usuario. Un agente de programación puede realizar llamadas repetidas, adjuntar un contexto extenso y seguir trabajando con supervisión limitada.

La concurrencia también puede derrotar una comprobación básica de saldo. Varias solicitudes pueden comenzar mientras una cuenta permanece por debajo de su límite. Si el sistema registra su coste solo tras completarse, el uso combinado puede superar el tope previsto.

Un diseño más seguro reserva presupuesto para cada solicitud en curso. También aplica límites por cuenta, credencial, endpoint y ventana temporal. Estos controles reducen el daño tanto del abuso de relés como de los ataques de denegación de cartera.

La denegación de cartera describe solicitudes destinadas a consumir la asignación de API de pago de otra parte. A diferencia de la reventa, el atacante puede no tener ningún cliente posterior. La debilidad técnica sigue siendo similar porque el objetivo acepta trabajo costoso sin autorización o límites adecuados.

La presión se desplaza entonces hacia equipos de aplicaciones más pequeños. Los grandes proveedores de modelos pueden mantener sistemas de riesgo de pagos, equipos antifraude y una amplia telemetría de comportamiento. Una startup que añade una única función de soporte con IA puede carecer de las tres cosas.

Los desarrolladores deben tratar cada función pública de IA como una interfaz financiera medida. La autenticación por sí sola es insuficiente cuando los atacantes pueden crear muchas cuentas. Los límites por usuario por sí solos son insuficientes cuando las solicitudes comparten un único presupuesto organizativo.

Las restricciones de entrada pueden ayudar, pero necesitan aplicación del lado del servidor. Una interfaz de navegador que solo acepta preguntas de soporte puede seguir llamando a un backend capaz de procesar texto arbitrario. Los atacantes pueden sortear la interfaz e invocar directamente la solicitud subyacente.

Los equipos también deberían separar las credenciales experimentales de las cuentas de producción. Una ruta de prueba filtrada no debería exponer toda la capacidad de gasto de una organización. Los permisos limitados, las restricciones de modelos y los presupuestos independientes reducen las consecuencias de un control omitido.

Este trabajo genera fricción para los usuarios legítimos. Las comprobaciones estrictas de identidad pueden bloquear a clientes que carecen de documentos o métodos de pago compatibles. Los filtros de red agresivos pueden perjudicar a viajeros, oficinas compartidas y usuarios preocupados por la privacidad.

Ese equilibrio ayuda a explicar la persistente demanda de relés. Algunos compradores buscan costes operativos más bajos. Otros quieren modelos que no están disponibles mediante canales oficiales locales. Algunos buscan un endpoint compatible con OpenAI que funcione con las herramientas de desarrollo existentes.

Estas necesidades no convierten a todos los compradores en cómplices del fraude ascendente. Sin embargo, un servicio inusualmente barato con propiedad poco clara transfiere un riesgo significativo al cliente. La conveniencia puede ocultar acceso poco fiable, modelos sustituidos o datos sin protección.

Un endpoint de API puede ocultar cientos de credenciales

El mecanismo de relé funciona porque las funciones estándar de gateway pueden separar la experiencia del cliente del origen de cada solicitud ascendente.

Lenhard afirma que la mayoría de los relés que examinó utilizaban one-api o new-api. Ambos son gateways de código abierto que pueden colocar varios proveedores de modelos detrás de una única interfaz compatible. Son productos legítimos con usos internos y empresariales habituales.

El software de gateway admite múltiples proveedores, gestión de tokens, grupos de canales, mapeo de modelos, comportamiento de reintento y balanceo de carga. Una empresa puede utilizar esas funciones para centralizar credenciales y, al mismo tiempo, proporcionar a sus empleados tokens de acceso más restringidos.

Su documentación también indica a los usuarios que respeten los términos de los proveedores y las leyes aplicables. Por tanto, el software no constituye prueba de fraude. La cuestión relevante es cómo obtiene un operador las cuentas ascendentes que incorpora a sus canales.

New API amplía la misma arquitectura general. El proyecto se describe como un gateway para agregación, autenticación organizativa, análisis de uso y despliegue privado. Su fork de gateway añade funciones de pago, contabilidad, permisos y enrutamiento útiles para operadores de servicios autorizados.

New API también afirma que las claves y cuentas ascendentes deben obtenerse legalmente. Advierte a los operadores de servicios públicos y de reventa que cumplan las obligaciones de autorización, licencias, registro, identidad, pagos y regulación. Estos avisos distinguen los usos previstos del software de los despliegues abusivos.

Un operador de relé comienza configurando canales. Cada canal apunta a un proveedor de modelos, un servicio de aplicaciones u otro grupo. El gateway asigna credenciales a esos canales y elige una cuando un cliente envía una solicitud.

El enrutamiento convierte credenciales poco fiables en un producto más estable. Cuando una cuenta alcanza un límite de tasa o queda suspendida, el sistema puede intentar otro canal. El enrutamiento ponderado puede favorecer fuentes que parecen más baratas o fiables.

Luego, la pasarela registra el uso contra el saldo de retransmisión del cliente. Esta capa de contabilidad no revela lo que cobró el proveedor upstream. Solo refleja las propias reglas, multiplicadores y asignaciones de modelos del operador.

Esa separación crea la brecha de información central. Un cliente que solicita un modelo frontier con nombre no puede ver de forma independiente qué cuenta upstream gestionó la llamada. También puede tener dificultades para confirmar que el modelo solicitado produjo la respuesta.

La asignación de modelos es útil en implementaciones legítimas. Una empresa puede mover tráfico entre sistemas compatibles o proporcionar un nombre de modelo interno estable. Un operador deshonesto puede usar la misma función para sustituir un modelo más barato mientras conserva una etiqueta premium.

Las pruebas simples de salida no resuelven por completo este problema. Los modelos estrechamente relacionados pueden responder de forma similar a indicaciones comunes. Los proveedores pueden actualizar modelos sin cambiar todas las etiquetas públicas. Los operadores de retransmisión también pueden enrutar solo solicitudes seleccionadas al modelo prometido.

El proxy ve la solicitud completa porque debe reenviarla upstream. En herramientas de programación, la carga útil puede incluir archivos de repositorio, notas arquitectónicas, registros de depuración e instrucciones del sistema. En aplicaciones empresariales, puede contener registros de clientes o documentos internos.

Una pasarela empresarial legítima opera bajo el control y las políticas de seguridad de la organización. Una retransmisión desconocida crea otro encargado del tratamiento de datos fuera de ese límite. Los compradores deben confiar en sus afirmaciones sobre retención, acceso, cifrado, respuesta a incidentes y eliminación.

La retransmisión también puede reenviar solicitudes a través de varios proveedores. La conmutación por error mejora la disponibilidad, pero amplía el número de sistemas que podrían recibir la indicación. Los clientes no pueden evaluar esa exposición sin divulgaciones precisas sobre enrutamiento y tratamiento de datos.

Esta distinción importa para los debates sobre políticas de código abierto. Culpar a one-api o new-api confundiría la capacidad con la conducta. Los servidores web, los sistemas de pago y los balanceadores de carga también respaldan negocios legítimos y operaciones abusivas.

La mejor respuesta se centra en la procedencia de las credenciales, la autorización y el comportamiento observable. Los proveedores pueden detectar cuentas relacionadas, patrones de solicitud inusuales, anomalías de pago y consumo rápido tras el registro. Los propietarios de aplicaciones pueden restringir lo que aceptan sus propios endpoints.

Los mantenedores de código abierto pueden respaldar la administración defensiva sin intentar vigilar cada implementación. Valores predeterminados seguros, advertencias de configuración destacadas, registros de auditoría, controles de gasto y registros claros de enrutamiento de modelos hacen que la operación legítima sea más segura. No eliminan el uso indebido deliberado.

La neutralidad del software es precisamente lo que hace importante esta historia. Los operadores de retransmisión no necesitan infraestructura clandestina especializada. Pueden montar escaparates utilizando los mismos patrones de pasarela que las empresas emplean para la gobernanza y el control de costes.

El descuento puede ocultar fraude, sustitución y exposición de datos

Un cliente de retransmisión no solo compra capacidad incierta; también confía a un intermediario la identidad del modelo, el tiempo de actividad y cada indicación enviada.

Lenhard identifica varias fuentes reportadas de inventario para retransmisión. Incluyen cuentas de prueba creadas masivamente, actividad de contracargos, tarjetas de pago robadas, cuentas prepago y endpoints de aplicaciones abiertos. La combinación probablemente varía entre operadores y a lo largo del tiempo.

Su investigación no demuestra de forma independiente que todas las retransmisiones rastreadas usen esos métodos. Tampoco la existencia de un descuento establece fraude. Revendedores autorizados, proveedores regionales y empresas con capacidad negociada pueden ofrecer ahorros legítimos.

No obstante, la escala de algunos descuentos reportados plantea una cuestión de procedencia. Un servicio sostenible requiere que alguien pague los recursos de computación, acepte márgenes más bajos u obtenga capacidad mediante un acuerdo especial. Los compradores deberían preguntar cuál de esas explicaciones se aplica.

Un intermediario creíble debería identificar su entidad jurídica y ofrecer condiciones de servicio claras. Debería explicar qué proveedores suministran los modelos y si la reventa está autorizada. Debería documentar la retención de indicaciones, los subencargados, la notificación de incidentes y la cancelación de cuentas.

Los compradores también deberían exigir una verificación fiable del modelo. Una etiqueta visible dentro de un panel de retransmisión no basta. La calidad de salida puede disminuir si el operador sustituye un modelo más pequeño, enruta canales sobrecargados o cambia de proveedor sin previo aviso.

La sustitución de modelos crea algo más que un problema de rendimiento. Los equipos pueden evaluar una aplicación con un modelo y desplegarla sin saberlo con otro. El comportamiento de seguridad, la gestión del contexto, el uso de herramientas y la salida estructurada pueden entonces cambiar sin una actualización de código.

La disponibilidad conlleva una incertidumbre similar. Los conjuntos de credenciales pueden ocultar fallos durante un tiempo porque el tráfico se desplaza a cuentas supervivientes. Sin embargo, una aplicación coordinada de las normas por parte del proveedor puede desactivar muchas cuentas relacionadas de una vez.

Una retransmisión puede desaparecer con los saldos de sus clientes y su historial operativo. Los compradores pueden tener recursos contractuales limitados, especialmente entre jurisdicciones. Eso dificulta comparar el aparente ahorro con el coste de una interrupción o migración.

La privacidad plantea la preocupación más profunda. Cada indicación pasa por infraestructura controlada por la retransmisión o su conjunto upstream. El cifrado protege el tráfico en tránsito, pero el proxy debe acceder al contenido de la solicitud para reenviarlo o transformarlo.

Los desarrolladores que usan agentes de programación pueden exponer más que fragmentos aislados. Las sesiones de agentes pueden incluir archivos completos, información sobre dependencias, URL internas, estructuras de bases de datos y lógica de autenticación. Incluso solicitudes de depuración aparentemente inocuas pueden revelar cómo está organizado un sistema.

Un estudio académico de filtración de credenciales de 2026 ilustra la debilidad más amplia en torno a las aplicaciones conectadas a LLM. Los investigadores examinaron 444 aplicaciones iOS y hallaron credenciales explotables en 282 de ellas.

Los investigadores identificaron tres patrones de filtración. La exposición de tokens basados en JWT representó el 48 por ciento, los proxies de backend no autenticados el 33 por ciento y las claves de API en texto plano el 19 por ciento. Estas categorías muestran que un atacante puede obtener capacidad sin encontrar una clave convencional de proveedor.

Tras la divulgación responsable, los investigadores volvieron a comprobar las aplicaciones vulnerables tres meses después. Solo el 28 por ciento había corregido el problema reportado, mientras que el 72 por ciento seguía siendo explotable. Los persistentes problemas de backend y diseño de tokens ralentizaron la corrección.

Ese estudio no demuestra que los operadores de retransmisión del informe de Lenhard explotaran esas aplicaciones específicas. Sí establece un conjunto considerable de capacidad LLM técnicamente explotable. Los proxies no autenticados son especialmente relevantes porque pueden invocarse sin exponer una clave sin procesar.

Los compradores también se enfrentan a incertidumbre legal y contractual. Un cliente puede no saber que sus solicitudes infringen las condiciones de un proveedor upstream. Sin embargo, una interrupción puede seguir afectando al cliente, independientemente de quién incumpliera originalmente el acuerdo.

Las restricciones geográficas complican el panorama. Algunos usuarios recurren a retransmisiones porque el acceso directo a modelos no está disponible en su región. Las retransmisiones convierten esa demanda insatisfecha en un endpoint funcional, pero no eliminan las restricciones de exportación, contractuales o regulatorias.

La destilación de modelos añade otra dimensión controvertida. Lenhard cita a participantes de foros que afirmaron que algunos compradores comerciales usan salidas retransmitidas para entrenar modelos nacionales. Esos comentarios fueron traducidos de una comunidad de operadores y no se verificaron de forma independiente.

La destilación en sí misma es una práctica técnica amplia. Un modelo más pequeño aprende patrones de las salidas de otro sistema o de señales de entrenamiento relacionadas. Que un uso concreto esté permitido depende de las condiciones de acceso, los derechos sobre los datos y el método exacto.

La conclusión más defendible es más acotada que la acusación más dramática. Una retransmisión crea un punto de control opaco entre los usuarios y los proveedores de modelos. Esa opacidad permite varios riesgos incluso cuando el cliente nunca tuvo la intención de participar en fraude.

La principal disputa es el acceso legítimo frente a la procedencia oculta

El conflicto definitorio del mercado de retransmisión no es código abierto frente a código cerrado; es acceso conveniente frente a autorización verificable.

Las API oficiales ofrecen a los clientes una relación contractual directa con un proveedor de modelos. Esa relación no elimina todas las preocupaciones de privacidad o fiabilidad. Sí establece una responsabilidad más clara sobre facturación, acceso a modelos, documentación de seguridad y soporte.

Una retransmisión añade al menos una parte adicional. Los comerciantes de cuentas y los conjuntos pueden añadir más. Cada capa puede mejorar la disponibilidad o la usabilidad local, pero cada una hace más difícil inspeccionar la procedencia y la responsabilidad.

Esta estructura de contrapartes explica por qué el precio por sí solo es una comparación deficiente. Un endpoint oficial y una retransmisión opaca pueden devolver respuestas sintácticamente similares. No ofrecen la misma cadena de custodia para credenciales, indicaciones, identidad del modelo o fondos del cliente.

Las pasarelas autorizadas ocupan un terreno intermedio legítimo. Una empresa puede centralizar cuentas aprobadas para hacer cumplir presupuestos y observar el uso. Un proveedor regional puede revender capacidad bajo un acuerdo documentado. Una plataforma empresarial puede enrutar entre modelos seleccionados por su cliente.

El elemento diferenciador es la evidencia. Los operadores autorizados pueden divulgar sus relaciones upstream, función contractual, controles de seguridad y prácticas de datos. Los clientes pueden evaluar esas afirmaciones mediante acuerdos, informes de auditoría, documentación y canales de soporte.

Los operadores opacos piden a los compradores que infieran legitimidad a partir del tiempo de actividad o la reputación de la comunidad. Ninguna de esas señales demuestra autorización. Un gran conjunto de credenciales puede mantener la disponibilidad incluso cuando las cuentas individuales son vetadas repetidamente.

Las reseñas de la comunidad pueden identificar estafas evidentes, pero los revisores no pueden observar cada solicitud upstream. Una retransmisión puede operar honestamente durante las pruebas y cambiar posteriormente su abastecimiento. También puede combinar capacidad autorizada con canales de respaldo cuestionables.

Por tanto, los proveedores se enfrentan a una difícil decisión de aplicación. Los controles agresivos sobre cuentas pueden elevar el coste del abuso. Los mismos controles pueden excluir a desarrolladores legítimos, en particular a quienes usan redes compartidas, métodos de pago internacionales o flujos de trabajo automatizados.

La verificación de identidad crea otro efecto de migración. Cuando las cuentas directas se vuelven más difíciles de crear, los atacantes pueden buscar endpoints de aplicaciones expuestos o cuentas establecidas. Lenhard predice que una verificación más estricta de los proveedores desplazará el abuso hacia la capa de aplicación.

Esa predicción no debería tratarse como garantizada. Mejores controles pueden reducir el abuso general cuando los proveedores comparten señales y mejoran los límites de gasto. Los atacantes siguen moviéndose cuando una ruta se vuelve menos rentable, por lo que el desplazamiento sigue siendo una posibilidad seria.

Los propietarios de aplicaciones necesitan defensas que asuman que su endpoint será puesto a prueba. Deberían autenticar solicitudes, imponer esquemas estrictos, limitar la concurrencia, reservar gasto en curso y rechazar indicaciones no relacionadas con la tarea prevista.

La supervisión del comportamiento debería examinar la antigüedad de la cuenta, el momento de las solicitudes, la selección de modelos, las señales de red y los cambios bruscos de volumen. Ningún indicador por sí solo es decisivo. Las señales combinadas pueden separar el uso ordinario del tráfico automatizado de extracción o reventa.

Los equipos deberían mantener controles de emergencia fuera de la aplicación afectada. Un servicio comprometido no debería tener que permanecer en línea antes de que los administradores puedan detener el gasto. Los bloqueos a nivel de proveedor y los controles presupuestarios independientes ofrecen un límite final.

Las organizaciones también necesitan registros operativos consultables. Los ingenieros que investigan un uso sospechoso deben conectar rápidamente cambios de implementación, alertas, facturas y registros de endpoints. Una base de conocimiento de ingeniería estructurada puede acortar esa investigación sin sustituir la telemetría de seguridad.

Los compradores tienen una responsabilidad paralela. Deben inventariar qué aplicaciones utilizan endpoints de relay y qué datos transmiten esas aplicaciones. Los secretos, el código propietario, los datos personales y los documentos de clientes no deben atravesar un proxy no verificado.

También deben diseñar una estrategia de salida. Un endpoint compatible facilita la adopción inicial, pero el comportamiento de los modelos y los detalles de autenticación aún pueden diferir. Probar un proveedor directo o una alternativa autorizada reduce la dependencia de un único intermediario.

El objetivo no es eliminar las gateways. Las gateways resuelven problemas reales relacionados con autenticación, presupuestos, enrutamiento y observabilidad. El objetivo es hacer que la procedencia y la autorización sean lo bastante visibles para que los compradores puedan distinguir la infraestructura del arbitraje basado en abusos.

Tres señales mostrarán si el mercado sigue creciendo

La próxima fase estará determinada por controles de gasto aplicables, la migración hacia endpoints de aplicaciones y pruebas más claras de la procedencia de los modelos.

La primera señal es si los principales proveedores de modelos introducen bloqueos de gasto estrictos e inmediatos. Un bloqueo útil debe detener las nuevas solicitudes cuando se agota un presupuesto definido. También debería reservar capacidad para las solicitudes que ya están en ejecución.

Willison sostiene específicamente que las claves deberían dejar de funcionar al alcanzar un umbral seleccionado por el desarrollador. Esa función reduciría las peores consecuencias de una aplicación expuesta. También limitaría los ataques de denegación de billetera y los bucles accidentales de agentes.

Las alertas por sí solas no superarán esta prueba. Los proveedores necesitan límites estrictos en ámbitos útiles, incluidos proyecto, clave, modelo y ventana de tiempo. Los clientes deberían poder configurarlos sin tener que crear un sistema independiente de control de facturación.

Si los bloqueos estrictos se convierten en estándar, se debilitará el argumento a favor de pérdidas evitables. Los operadores de relay aún podrían explotar cuentas gratuitas o credenciales robadas, pero cada cuenta ofrecería menos capacidad utilizable. Los pools necesitarían más inventario y un mayor esfuerzo operativo.

La segunda señal es un aumento de los ataques contra endpoints de la capa de aplicación. Los proveedores están reforzando los controles de identidad, pago y comportamiento en torno a las cuentas directas. Los atacantes pondrán a prueba si los bots de soporte, los backends móviles y las funciones públicas de IA siguen siendo objetivos más fáciles.

Los investigadores pueden medir este cambio mediante divulgaciones, honeypots, telemetría de credenciales e informes de abuso. Las empresas de aplicaciones también pueden detectar prompts irrelevantes, concurrencia inusual, tráfico continuo o solicitudes que llegan inmediatamente después del registro.

Un aumento claro respaldaría la advertencia de Lenhard sobre la migración. Un abuso de aplicaciones estable o en descenso la debilitaría, especialmente si los proveedores también informan menos cuentas fraudulentas. Los datos públicos seguirán siendo incompletos porque muchas víctimas evitan revelar sus pérdidas.

La tercera señal es si los compradores exigen enrutamiento y autorización verificables. Actualmente, los directorios de relay compiten en gran medida por acceso y fiabilidad. El mercado podría cambiar si los clientes empresariales insisten en relaciones firmadas con proveedores, certificaciones de modelos y políticas de datos auditables.

Las herramientas de procedencia de modelos no necesitan exponer todas las credenciales secretas. Podrían proporcionar registros de enrutamiento firmados, identificadores de modelos estables o pistas de auditoría visibles para el cliente. Evaluaciones independientes podrían verificar que un operador cumple con su política de enrutamiento declarada.

Si estas prácticas se extienden, será más fácil distinguir a los agregadores legítimos de los relays opacos. Si los compradores siguen eligiendo endpoints sin comprobaciones de procedencia, los revendedores de baja fricción conservarán su ventaja informativa.

Los desarrolladores deberían actuar antes de que esas señales de mercado se aclaren. Revisen cada endpoint público de LLM, incluidas las herramientas de soporte y los backends móviles. Apliquen límites estrictos de concurrencia y controles de gasto independientes siempre que el proveedor lo permita.

Los compradores empresariales deberían rastrear cada ruta de solicitud de IA desde la interfaz de usuario hasta el proveedor final del modelo. Si un intermediario no puede explicar su papel, traten esa incertidumbre como un hallazgo de seguridad.

La advertencia de Simon Willison convierte una historia remota del mercado gris en una cuestión directa de ingeniería. ¿Puede su aplicación detener el abuso antes de que sus credenciales, prompts o presupuesto se conviertan en el inventario de otra persona?