La guía de CISA sobre tokens de IA advierte que el uso puede convertirse en un ataque

CISA y organismos aliados de ciberseguridad advierten que el consumo de IA puede convertirse en una amenaza de seguridad antes de que un sistema quede fuera de servicio. La guía de CISA sobre tokens de IA aborda los ataques de denegación de billetera, un abuso deliberado que eleva los cargos basados en el uso de una organización. Su importancia va más allá de facturas inesperadas: los límites de gasto y la capacidad agotada también pueden interrumpir el trabajo que depende de la IA.

La cobertura de ciberseguridad de octubre de ExecutiveGov fechó la noticia el 23 de octubre de 2026. La tensión central es sencilla. Las empresas quieren sistemas de IA que sigan funcionando durante tareas complejas, pero la actividad continuada también consume recursos. Un sistema que prosigue de forma fiable una tarea no autorizada o derrochadora crea un problema distinto de fiabilidad.

Esta preocupación ya aparece en el marco de seguridad de OWASP y en la documentación de seguridad empresarial de Microsoft. La guía la incorpora a una discusión sobre adquisición y resiliencia operativa. Los compradores empresariales, desarrolladores y equipos de seguridad afrontan ahora una pregunta común: ¿quién decide cuándo un flujo de trabajo de IA ha hecho lo suficiente y quién puede detener su gasto?

La guía de CISA sobre tokens de IA vincula el gasto con la continuidad del servicio

El cambio relevante es tratar el consumo de IA como una dependencia operativa que merece supervisión de seguridad.

La publicación conjunta, disponible a través del Canadian Centre for Cyber Security, se titula AI token consumption. Los tokens son unidades de información que los modelos de IA procesan o generan. Ayudan a medir el uso, aunque la relación entre el número de tokens, el trabajo computacional y los cargos depende del servicio.

La publicación distingue el perjuicio financiero del acceso agotado. Los ataques de denegación de billetera aumentan deliberadamente los costes basados en el uso. Los ataques de denegación de tokens consumen asignaciones o activan límites, interfiriendo con el acceso legítimo. Los resultados se solapan, pero no son intercambiables.

La guía también identifica causas operativas habituales de agotamiento, incluida la demanda legítima y las aplicaciones ineficientes. Insta a las organizaciones a comprender el consumo y las condiciones del servicio antes de celebrar acuerdos con proveedores. Para los operadores de infraestructuras críticas, la preocupación incluye la continuidad cuando las capacidades de IA se degradan o dejan de estar disponibles.

Este enfoque importa porque una salvaguarda financiera puede convertirse en una restricción de disponibilidad. Detener el consumo protege un presupuesto, pero una interrupción indiscriminada puede afectar trabajo importante. Continuar el consumo preserva temporalmente el acceso, pero deja a la organización expuesta a más gastos.

La implicación práctica es un conflicto entre objetivos que compiten. Finanzas quiere una exposición predecible. Operaciones quiere acceso fiable. Los equipos de producto quieren completar las tareas con éxito. Seguridad quiere contener el comportamiento sospechoso. Un despliegue de IA necesita una forma explícita de resolver esos objetivos cuando entran en conflicto.

Consideremos un asistente empresarial de documentos utilizado para consultas rutinarias e investigaciones operativas urgentes. Ambas actividades podrían depender de la misma cuenta de modelo subyacente. Una tarea de segundo plano derrochadora se vuelve relevante si consume los recursos necesarios para la investigación urgente.

Ese ejemplo no demuestra que una organización concreta haya sufrido un incidente de este tipo. Muestra por qué importa la ubicación del límite de gasto. Un límite aplicado a una cuenta completa produce consecuencias distintas de un límite aplicado a un flujo de trabajo individual.

También cambia cómo debe interpretarse una demostración exitosa. Una demostración establece que un asistente puede completar tareas seleccionadas en condiciones seleccionadas. No establece cómo se comporta el servicio cuando cambia la demanda, fallan las dependencias o la actividad permitida se vuelve excesiva.

Para los compradores, eso crea una brecha entre la evidencia de capacidad y la evidencia operativa. La primera responde si el sistema puede realizar el trabajo. La segunda responde si la organización puede seguir utilizándolo en condiciones adversas.

La guía de CISA sobre tokens de IA hace más difícil dejar esa segunda pregunta fuera del proceso de compra. El asunto debe considerarse junto con la disponibilidad del servicio, las expectativas de recuperación y la responsabilidad ante los fallos.

La presión recae sobre los compradores que no pueden ver las cargas de trabajo individuales

Una factura agregada de IA no puede explicar si un flujo de trabajo individual merece seguir ejecutándose.

La presión inmediata recae sobre las organizaciones que adquieren capacidades de IA mediante aplicaciones, integraciones y servicios compartidos. Su desafío consiste en vincular el consumo con un propósito empresarial. Sin esa conexión, un total de uso creciente ofrece poca ayuda durante un incidente.

Una tarea inusualmente costosa podría ser legítima. Podría implicar un análisis difícil, una gran colección de documentos o intentos repetidos de resolver evidencia contradictoria. El mismo patrón de gasto también podría reflejar una integración defectuosa o abuso deliberado.

Esta ambigüedad hace poco fiables los juicios simples. Un consumo elevado no establece intención maliciosa. Un consumo bajo no establece un comportamiento seguro. La pregunta significativa es si la actividad sigue siendo autorizada, proporcional y útil.

Por ello, los equipos de compras necesitan evidencia sobre los límites de control, en lugar de lenguaje tranquilizador sobre la supervisión. Un panel puede mostrar un problema sin prevenirlo. Una alerta puede notificar a alguien que carece de la autoridad o los medios técnicos para intervenir.

La documentación de Microsoft sobre unbounded AI consumption describe el agotamiento de recursos mediante prompts exigentes, solicitudes repetidas y actividad excesiva de agentes. Recomienda controles en las llamadas al modelo y los servicios posteriores, incluidas cuotas, contención y límites a la expansión de agentes. Microsoft también señala que los incidentes maliciosos ampliamente difundidos siguen siendo limitados.

Esta última salvedad es importante para los compradores. Un modelo de amenaza creíble respalda la preparación, pero no justifica tratar cada aumento de costes como un ataque. Las buenas decisiones de compra requieren distinguir entre un mecanismo demostrado y la prevalencia medida de incidentes.

La posición de Microsoft también ofrece una comparación útil con el marco de seguridad de aplicaciones de OWASP. Microsoft describe controles dentro de un entorno de seguridad empresarial. OWASP clasifica la debilidad de consumo subyacente entre aplicaciones. Estas perspectivas refuerzan el problema sin establecer que un proveedor concreto lo haya resuelto.

La implicación comercial es que los proveedores necesitarán explicar cada vez más el alcance de sus controles. ¿Una restricción se aplica a un cliente, un departamento, una aplicación o una tarea individual? ¿Puede un operador aislar trabajo sospechoso mientras preserva la actividad no relacionada?

Estas preguntas también afectan a la rendición de cuentas dentro de la organización compradora. Un equipo de finanzas podría gestionar el presupuesto mientras ingeniería gestiona la integración. Seguridad podría recibir alertas sin gestionar el contrato. Una transferencia de responsabilidades sin resolver puede dejar a todos informados y a nadie responsable de detener el flujo de trabajo.

Para los desarrolladores, la visibilidad del consumo pasa a formar parte del diagnóstico del comportamiento de las aplicaciones. Saber que una cuenta gastó más dice menos que saber qué tarea repitió una acción fallida. La evidencia útil debería conectar la tarea, su progreso y los recursos que consumió.

Para los trabajadores del conocimiento, las consecuencias aparecen como respuestas retrasadas, investigación interrumpida o asistentes no disponibles. Rara vez controlan la asignación de recursos subyacente. Su experiencia depende de decisiones tomadas por compras e ingeniería mucho antes de la interrupción.

Los equipos que revisan estas dependencias pueden mantener contratos aprobados, decisiones de arquitectura y procedimientos de incidentes en una base de conocimiento técnico con capacidad de búsqueda. La documentación respalda una respuesta coordinada, aunque no puede sustituir los controles aplicados por la aplicación.

La autonomía útil y el consumo acotado tiran en direcciones distintas

La disyuntiva central consiste en permitir que un sistema continúe un trabajo útil y evitar que siga funcionando indefinidamente.

Un agente de IA es software que utiliza un modelo para seleccionar acciones a lo largo de una tarea. Eso puede facilitar la delegación de trabajo difícil. También significa que la solicitud original no necesariamente describe cada acción posterior.

Un usuario podría autorizar una investigación sin saber qué búsquedas, documentos o servicios externos necesitará el agente. Un límite restrictivo corre el riesgo de detener trabajo útil prematuramente. Un límite abierto deja a la organización aceptando consecuencias que no ha especificado por completo.

La categoría de OWASP sobre unbounded consumption identifica el uso no controlado del modelo como una fuente de degradación del servicio y perjuicio económico. Sus ejemplos incluyen solicitudes excesivas y consultas que requieren muchos recursos. El marco recomienda protecciones por capas, incluida la gestión de recursos, los tiempos de espera, la supervisión y la degradación gradual, es decir, una funcionalidad reducida que preserva un servicio útil.

Esta perspectiva hace que el asunto sea más amplio que la longitud de un prompt. Una instrucción breve puede iniciar un flujo de trabajo complicado. Contar solo las solicitudes entrantes dice poco sobre todo lo que hace la aplicación después de aceptarlas.

Un asistente de investigación ilustrativo podría buscar en una colección de documentos, examinar pasajes contradictorios y solicitar más evidencia. Cada acción puede ser razonable individualmente. La pregunta empresarial es si la secuencia sigue haciendo avanzar la investigación autorizada.

Aquí es donde la finalización de tareas y la continuación de tareas divergen. La actividad continuada puede parecer productiva en una interfaz incluso cuando el trabajo subyacente ha dejado de progresar. Un flujo de actualizaciones de estado no establece que la siguiente acción merezca más recursos.

La misma tensión aparece en la recuperación de errores. Reintentar una acción fallida a veces resuelve un problema temporal. Repetir una acción que no puede tener éxito solo prolonga el fallo. Una aplicación necesita una forma de distinguir esas situaciones utilizando evidencia que vaya más allá de la disposición del modelo a intentarlo de nuevo.

Esta distinción también debería determinar cómo las organizaciones evalúan la autonomía. Menos intervención humana no es automáticamente mejor si los operadores pierden la capacidad de comprender qué continúa. Más intervención no es automáticamente más segura si las aprobaciones rutinarias se convierten en interrupciones sin sentido.

Una evaluación útil pregunta qué evidencia permite que el flujo de trabajo continúe. ¿Ha obtenido información nueva? ¿Ha cambiado una dependencia? ¿Ha completado un resultado intermedio significativo? Son preguntas analíticas sobre el progreso, no afirmaciones de que algún producto actual las responda de forma fiable.

La responsabilidad también se extiende más allá del proveedor del modelo. Una aplicación decide qué trabajo solicitar, qué herramientas exponer y cómo gestionar tareas sin terminar. Esas decisiones afectan la exposición incluso cuando el modelo subyacente se comporta según lo previsto.

Esto explica por qué no puede suponerse que cambiar de modelo resolverá el problema. Un modelo que consume menos recursos podría reducir el gasto de cada acción. No establece que la aplicación vaya a elegir un número apropiado de acciones.

Por tanto, la orientación de CISA sobre tokens de IA forma parte de una conversación más amplia sobre la autoridad delegada. Autorizar a un sistema de IA a perseguir un objetivo debería incluir un límite definido sobre los recursos que puede comprometer.

El difícil problema de diseño consiste en preservar una discreción útil dentro de ese límite. Las empresas necesitan suficiente flexibilidad para el trabajo complejo, junto con una explicación creíble de lo que ocurre cuando se alcanza el límite.

El Software que Rodea al Modelo Determina el Límite de Gasto

El criterio de un modelo y el permiso de una aplicación para gastar son decisiones separadas.

El aviso sobre arneses de IA agéntica de la Australian Signals Directorate, publicado el 11 de septiembre de 2026, centra la atención en el software circundante. Un arnés es la capa de software que conecta un modelo con herramientas, datos, memoria y controles de ejecución.

El aviso sostiene que las organizaciones deberían evaluar esta capa como una fuente distinta de riesgo operativo y de seguridad. Su énfasis incluye permisos, monitorización, supervisión y las formas en que los modelos interactúan con sistemas conectados. Esto aporta un complemento arquitectónico útil a la orientación sobre tokens.

La distinción importa porque un asistente puede recomendar una acción sin tener autoridad para ejecutarla. La aplicación que rodea al modelo determina si la acción ocurre. La misma separación puede aplicarse a la autorización de consumo adicional de recursos.

Desde esa perspectiva, un límite de gasto debería ser una decisión de la aplicación que el modelo no pueda sortear simplemente hablando. Pedir a un modelo que sea económico es distinto de imponer una restricción exigible. Lo primero expresa un objetivo; lo segundo modifica el comportamiento permitido.

Una investigación presentada en septiembre añade una preocupación técnica más específica. Un preprint sobre estado facturable persistente examina el contenido de herramientas externas retenido entre interacciones de agentes. Los autores informan de que el contenido retenido puede convertirse en una entrada facturable recurrente cuando solicitudes posteriores lo incluyen de nuevo.

Su estudio prueba ataques y defensas del lado del host en flujos de trabajo controlados. Sus hallazgos se refieren al manejo de información retenida, más que a evidencia de un compromiso empresarial generalizado. Como preprint, requiere escrutinio y replicación independiente antes de extraer conclusiones amplias sobre el riesgo de despliegue.

No obstante, la investigación destaca una distinción importante entre aceptar información y pagar repetidamente por procesarla. Una respuesta de herramienta puede permanecer dentro de un flujo de trabajo después de que haya terminado su propósito inmediato. Por ello, las decisiones de retención merecen atención junto con las decisiones de acceso.

Una investigación documental ilustrativa hace concreto el problema. Un asistente recupera un informe extenso para responder a una pregunta concreta. Si la aplicación sigue proporcionando ese informe durante acciones de seguimiento no relacionadas, el procesamiento continuo necesita su propia justificación.

Simplemente eliminarlo todo no es una respuesta general adecuada. El asistente podría necesitar evidencia anterior para resolver contradicciones o explicar su conclusión. La cuestión arquitectónica es qué información sigue siendo necesaria y cómo la aplicación hace visible ese criterio.

Aquí también es donde las comparaciones entre proveedores cobran más sentido. Los compradores pueden comparar el tratamiento del historial de tareas, la intervención y el comportamiento de reinicio. Un contexto disponible más amplio, es decir, la información que un modelo puede considerar durante una solicitud, no resuelve esas cuestiones operativas.

Del mismo modo, cambiar de proveedor crea una nueva dependencia en lugar de eliminar la necesidad de gobernanza. El servicio receptor podría gestionar la información de forma diferente. Una alternativa que preserva la disponibilidad aún debe evaluarse en cuanto a corrección, permisos y exposición de recursos.

La implicación central es el control organizativo. Las empresas deberían entender qué decisiones corresponden al modelo, cuáles a la aplicación y cuáles requieren autoridad humana. Difuminar esas responsabilidades dificulta investigar tanto el gasto excesivo como las interrupciones innecesarias.

La Advertencia Es Creíble, pero la Prevalencia de los Ataques Sigue sin Estar Clara

Una vía de ataque plausible no establece con qué frecuencia los atacantes la explotan ni cuánto daño causan.

Las fuentes disponibles respaldan tratar el consumo excesivo como una preocupación de seguridad y resiliencia. No proporcionan una medición exhaustiva de incidentes maliciosos de denegación de billetera en empresas. Esa incertidumbre debería seguir siendo visible en la cobertura de la advertencia.

La distinción importa porque varios fallos distintos pueden producir síntomas similares. Una solicitud maliciosa, un defecto de software y una tarea legítima inesperadamente difícil pueden aumentar el consumo. Un pico de gasto por sí solo no puede determinar cuál explicación es correcta.

Calificar cada pico como un ataque distorsionaría los informes de incidentes. Calificar cada pico como demanda ordinaria ocultaría el abuso. Las organizaciones necesitan suficiente evidencia a nivel de tarea para investigar antes de elegir cualquiera de las dos interpretaciones.

También existe un límite importante para las afirmaciones sobre controles protectores. Un umbral configurado demuestra que existe un ajuste. No establece con qué rapidez se aplica la ejecución, qué actividad cubre ni si el trabajo dependiente continúa en otro lugar.

Una alerta presenta una afirmación aún más limitada. Establece que el sistema puede notificar a alguien bajo condiciones especificadas. Los compradores aún necesitan entender los retrasos de notificación, las responsabilidades de escalamiento y las acciones disponibles después de la notificación.

Del mismo modo, una demostración de contención exitosa debe interpretarse dentro de las condiciones probadas. Detener una carga de trabajo artificial demuestra algo útil sobre esa prueba. No establece automáticamente protección frente a cada flujo de trabajo, integración o patrón de abuso.

La pregunta escéptica más sólida se refiere a las consecuencias empresariales. Un control que detiene el consumo excesivo aún puede interrumpir trabajo legítimo. Por tanto, evaluar la protección exige examinar tanto la exposición evitada como el trabajo que la protección bloquea.

Esa compensación se vuelve especialmente importante cuando las organizaciones usan tasas de finalización para evaluar asistentes. Una detención agresiva puede reducir la finalización exitosa. La continuación permisiva puede mejorar la finalización aparente mientras aumenta la exposición. Una comparación significativa necesita considerar ambos resultados.

Otra incertidumbre se refiere a dónde empieza y termina la responsabilidad contractual. Un proveedor podría ofrecer monitorización mientras el cliente configura la ejecución. Un proveedor de aplicaciones podría depender del servicio de modelos de otra empresa. Los compradores deberían evitar inferir responsabilidad a partir del nombre de una función.

La propia orientación también debería describirse con precisión. Una publicación de ciberseguridad no es automáticamente un nuevo mandato legal. Cualquier afirmación sobre obligaciones obligatorias requeriría una autoridad independiente y aplicable. Las fuentes aquí establecen orientación y preocupaciones técnicas, en lugar de un plazo universal de cumplimiento.

Para los equipos de producto, la respuesta razonable es una validación proporcional. Pueden examinar si las tareas representativas siguen siendo útiles bajo límites realistas. También pueden probar si las tareas sospechosas o defectuosas se detienen sin deshabilitar trabajo no relacionado.

Para los lectores, el estándar de información debería seguir siendo igualmente disciplinado. Exijan distinciones claras entre controles recomendados, comportamiento probado de forma independiente e incidentes verificados. Esas categorías responden a preguntas diferentes, y tratarlas como intercambiables hace menos fiables las decisiones de compra.

La orientación de CISA sobre tokens de IA es relevante sin requerir afirmaciones exageradas. Identifica una dependencia que las organizaciones pueden examinar ahora, al tiempo que deja la frecuencia y la gravedad de la explotación en el mundo real abiertas a más evidencia.

Vigile la Ejecución, el Aislamiento de Cargas de Trabajo y las Pruebas Independientes

La próxima evidencia debería mostrar si las organizaciones pueden contener trabajo excesivo mientras preservan el servicio legítimo.

Durante los próximos meses, las señales más útiles se referirán al comportamiento operativo, más que a promesas generales sobre una IA más segura. La publicación ofrece una base clara para plantear preguntas más específicas. No establece que los proveedores o compradores ya las hayan respondido.

La primera señal es una documentación más clara sobre el comportamiento de ejecución. Observe si los proveedores distinguen las notificaciones de las restricciones y explican exactamente dónde se aplica cada restricción. Esto reforzaría la idea de que la gobernanza del consumo se está convirtiendo en una capacidad de producto utilizable.

La señal opuesta debilitaría esa evaluación. Si la documentación continúa describiendo presupuestos sin explicar la intervención, los compradores seguirán teniendo dificultades para estimar la exposición. Una función debería juzgarse por su efecto operativo, incluido lo que sigue permitido después de activarse.

La segunda señal es evidencia de aislamiento de cargas de trabajo en requisitos de compra y pruebas de aceptación. El aislamiento de cargas de trabajo significa restringir un trabajo problemático sin interrumpir innecesariamente otros trabajos. La evidencia relevante mostraría que la actividad crítica continúa mientras se detiene la actividad de menor prioridad o sospechosa.

Esto respaldaría la conexión de la orientación entre los controles de consumo y la continuidad. Un cierre de toda la cuenta aún podría ser apropiado en algunas circunstancias. Sin embargo, presentar ese comportamiento como equivalente a una contención selectiva ocultaría una diferencia importante.

La tercera señal son pruebas independientes que combinen la contención con la finalización útil de tareas. Observe evaluaciones que publiquen sus supuestos de carga de trabajo y expliquen por qué se detuvieron las tareas interrumpidas. Los resultados sólidos mostrarían una exposición limitada junto con una finalización creíble del trabajo autorizado.

Los resultados que solo midan la reducción del consumo dejarían una laguna importante. Gastar menos es fácil si un asistente rechaza suficiente trabajo. La prueba difícil es si los límites preservan el propósito empresarial para el que se adquirió el sistema.

Estas señales también crean una forma práctica de comparar ofertas competidoras. Los compradores pueden examinar la ejecución documentada, el comportamiento de aislamiento y los resultados evaluados de forma independiente. Esto produce una evaluación más útil que depender únicamente de afirmaciones sobre la capacidad del modelo.

Para los desarrolladores, la implicación inmediata es hacer que el comportamiento operativo sea revisable. Una tarea debería tener un propósito identificable, un responsable claro y una condición de detención comprensible. Estas propiedades facilitan el diagnóstico de fallos y la comprobación de las afirmaciones de compra.

Para los líderes empresariales, pidan al equipo responsable de un servicio de IA que rastree un trabajo representativo desde la autorización hasta su finalización o interrupción. Identifiquen quién es responsable de su límite de recursos, quién puede intervenir y qué trabajo no relacionado sigue disponible después. Soliciten evidencia de una prueba real en lugar de aceptar un panel de control como respuesta. Utilicen la orientación de CISA sobre tokens de IA para enfocar esa revisión tanto en la continuidad empresarial como en el gasto. Luego comparen el comportamiento observado con el acuerdo de servicio y las responsabilidades internas. Si esas versiones difieren, resuelvan la discrepancia antes de ampliar el despliegue. La decisión de delegar trabajo debería incluir una respuesta clara sobre quién puede detenerlo.