Cómo prevenir costos descontrolados de credenciales de API de IA

Una clave de API de IA no es solo una cadena de inicio de sesión. Es una vía hacia capacidad informática medida, y una clave copiada puede seguir autorizando solicitudes mucho después de que un atacante abandone la aplicación donde quedó expuesta. Por tanto, el control de costos pertenece al diseño de seguridad de todo sistema de IA, incluidas las herramientas temporales de investigación y los prototipos internos.

La divulgación de METR de 2026 da una forma concreta a este riesgo. Un panel de agentes accesible desde internet tenía un fallo de autenticación de apertura en caso de fallo, lo que significaba que la aplicación permanecía disponible cuando fallaba su control de acceso. METR informó de que un atacante llegó al panel, indujo a un agente a revelar una credencial de proveedor de modelos, añadió una clave SSH para acceso persistente al host y usó la credencial robada durante tres semanas. Los créditos consumidos se valoraron en aproximadamente 600.000 dólares, aunque METR no pagó esa cantidad porque el proveedor había suministrado los créditos sin cargo.

La lección útil no es el valor que ocupó el titular ni el estilo de desarrollo de una aplicación. Varios controles independientes no lograron detener la misma ruta. Un plan de prevención duradero presupone que una interfaz, un host o una clave pueden llegar a verse comprometidos y limita lo que puede suceder después.

Defina el radio de impacto antes de desplegar un agente

Clasifique una aplicación de IA según lo que un usuario no confiable podría alcanzar a través de ella, no según que el equipo la llame prototipo. Un experimento pasa a ser operacionalmente relevante cuando acepta tráfico de internet, puede llamar a un modelo de pago o escaso, puede alcanzar datos no públicos o puede invocar herramientas con efectos fuera de su propio proceso. Una vida útil breve no reduce esas capacidades.

Cree un pequeño registro de despliegue antes de la exposición. Indique el propietario, los puntos de conexión públicos, la cuenta en la nube, los modelos, las credenciales, los almacenes de datos, los permisos de herramientas, el rango de uso esperado, la fecha de vencimiento y el procedimiento de apagado. Este inventario hace detectables los experimentos olvidados y da a quien responde a un incidente un mapa fiable. Los servicios públicos deben ejecutarse en un entorno arquitectónicamente separado de los sistemas internos, de modo que un defecto en un visor o panel no cree una ruta hacia infraestructura sensible.

La divulgación de METR describió un segundo fallo en un visor público de transcripciones: un mecanismo SQL de solo lectura podía manipularse para exponer datos de evaluación no publicados, y alguna salida sensible había entrado en una base de datos que se esperaba que contuviera solo resultados de modelos públicos. METR dijo que la evidencia disponible no indicaba que los atacantes descubrieran la vulnerabilidad o accedieran a información no pública. Aun así, el episodio muestra por qué la clasificación prevista de los datos no basta. El aislamiento debe cubrir dónde se almacenan los registros, cómo se delimitan las consultas y si el material restringido puede colocarse en un almacén de datos orientado al público.

Establezca una regla fácil de aplicar: la exposición a internet o el acceso a credenciales activas activa automáticamente una revisión de seguridad básica. La revisión puede ser ligera, pero debe confirmar autenticación que deniegue por defecto, alojamiento gestionado, propiedad identificada, registro, límites de credenciales y una fecha de finalización.

Mantenga los secretos sin procesar fuera del alcance del agente

Una aplicación puede necesitar permiso para llamar a un modelo, pero el modelo no necesita leer la credencial reutilizable. Guarde los secretos fuera de prompts, transcripciones, herramientas de inspección del entorno, archivos que el agente puede abrir y salida de comandos que el agente puede devolver. Instrucciones como "nunca revele esta clave" no son un límite de seguridad porque un modelo de lenguaje procesa instrucciones no confiables y puede ser manipulado para divulgar información accesible.

Coloque un intermediario o servicio estrictamente definido entre el agente y el proveedor. El agente solicita una operación permitida; el intermediario guarda la credencial, valida la solicitud, aplica la política, registra el uso y devuelve solo el resultado necesario. Limite el intermediario a modelos y operaciones aprobados. Cuando las funciones del proveedor lo permitan, emita credenciales independientes para cada aplicación y entorno, reduzca los ámbitos de permisos y use duraciones breves.

Las identidades separadas facilitan tanto la contención como la investigación. Si una clave sirve a varios experimentos, el uso elevado tiene muchas explicaciones plausibles y la revocación interrumpe trabajo no relacionado. Una clave dedicada a una carga de trabajo tiene un rango de comportamiento menor, un propietario claro y un interruptor de apagado práctico. Las credenciales de corta duración también reducen el periodo durante el cual un valor copiado sigue siendo útil, mientras que los permisos de ámbito limitado restringen lo que el atacante puede hacer durante ese periodo.

El acceso al host necesita su propio límite. El atacante de METR añadió una clave SSH después de entrar en el sistema expuesto, por lo que rotar solo la credencial del proveedor no habría eliminado la persistencia. Supervise los cambios de configuración de acceso remoto, restrinja quién puede añadir claves y trate un nuevo método de acceso persistente como un incidente incluso cuando el consumo de API siga pareciendo ordinario.

Convierta los presupuestos en límites de seguridad aplicados

Una alerta de gasto es útil, pero una alerta es solo una petición para que una persona investigue. Prefiera un límite estricto del proveedor o del intermediario que rechace más uso una vez agotado el presupuesto aprobado. Aplique límites en varios niveles cuando estén disponibles: organización, proyecto, credencial de aplicación y ventana temporal. Un techo mensual de cuenta por sí solo aún puede permitir un pico dañino al principio del periodo.

Algunos proveedores o acuerdos de cuenta pueden no exponer un límite directo de gasto. METR dijo que no podía establecer uno en la clave afectada en ese momento, y los créditos donados eliminaron la factura creciente que de otro modo podría haber llamado la atención. En esa situación, recree el límite en la capa de llamada. Un intermediario de credenciales puede contar solicitudes o tokens, aplicar asignaciones diarias y por ejecución, limitar la concurrencia y suspender el acceso cuando se cruza un umbral. La capacidad concedida o prepagada debe tratarse como un activo con valor de reemplazo incluso cuando la facturación actual en efectivo sea cero.

Elija los umbrales a partir del propósito declarado de la credencial. Una evaluación programada, un panel interactivo y un trabajo por lotes no deberían compartir los mismos límites. Defina un máximo esperado para una sola ejecución, un techo móvil por hora o por día y una tasa máxima de solicitudes fallidas o rechazadas. Documente quién puede aprobar un aumento temporal y cuándo vence esa excepción. De lo contrario, las anulaciones de emergencia se convierten silenciosamente en el marco operativo normal.

La aplicación debe fallar cerrada. Si el servicio de autenticación, la comprobación de política, el contador de uso o la consulta de aprobación no están disponibles, el sistema debe denegar o restringir drásticamente la operación protegida. Un servicio de supervisión degradado no debe convertir silenciosamente una credencial limitada en una ilimitada.

Detecte comportamientos que una factura no puede mostrar

Un volumen elevado de tokens no es automáticamente sospechoso en el trabajo de investigación o evaluación. METR explicó que los experimentos legítimos podían generar uso sustancial, respuestas de limitación de tasa y errores del proveedor. Su panel interno tampoco mostraba todas las solicitudes con limitación de tasa de cada usuario durante el incidente. Esa combinación permitió que actividad no autorizada se mezclara con ruido operativo conocido.

Construya líneas de base alrededor de la identidad y el propósito en vez de observar solo el volumen total de la cuenta. Para cada credencial de aplicación, conserve la hora de la solicitud, el modelo, el resultado, la cantidad de tokens o de uso, la carga de trabajo de origen y el propietario responsable cuando esas señales estén disponibles. Incluya los intentos fallidos y limitados por tasa, porque el reconocimiento y el consumo intentado quizá nunca aparezcan en los totales de uso exitoso. No coloque el secreto sin procesar en los registros.

Las reglas útiles de anomalías comparan el comportamiento actual con el registro de despliegue. Los ejemplos incluyen actividad fuera del horario de la carga de trabajo, uso sostenido tras el fin de un experimento planificado, un origen desconocido, un modelo al que la aplicación no estaba autorizada a llamar, una proporción inusual de errores frente a éxitos o un cambio repentino en la tasa de solicitudes. Estas señales son más accionables que una alerta genérica de "uso elevado" porque explican qué expectativa se vulneró.

Ajuste las alertas sin borrar evidencia importante. Los mensajes ruidosos de limitación de tasa deben agruparse y resumirse, no omitirse del panel. El objetivo es un flujo de alertas manejable respaldado por eventos completos que se puedan buscar. Cada alerta necesita una persona responsable identificada, gravedad, fecha límite de investigación y una ruta de escalamiento automático. Una advertencia sin dueño es solo telemetría almacenada.

Diseñe un panel de agentes para tomar decisiones

Un panel de operaciones útil debe responder rápidamente a cuatro preguntas: qué credencial cambió de comportamiento, qué está autorizada a hacer, cuánto valor está actualmente en riesgo y qué acción lo contendrá. Presente uso y fallos por credencial, aplicación, modelo y ventana temporal en lugar de solo como un total de toda la organización. Muestre el consumo del límite estricto, las excepciones temporales, la antigüedad de la credencial, la última rotación, el propietario y si el despliegue asociado sigue aprobado.

Coloque juntos los indicadores de seguridad y costo. Un pico de errores del proveedor, una nueva clave SSH, un fallo de autenticación y el uso continuado de API pueden parecer menores en herramientas separadas, pero forman una cadena de incidentes clara cuando se correlacionan. Conserve suficiente historial para comparar el comportamiento actual con el patrón normal de la misma carga de trabajo y reconstruir la secuencia después.

El panel debe proporcionar o enlazar directamente a acciones de contención probadas: deshabilitar la credencial de aplicación, detener la carga de trabajo, eliminar el acceso público y contactar al proveedor. Los controles destructivos necesitan la autorización apropiada, pero no deben depender de encontrar un comando no documentado durante un incidente activo. Registre quién realizó cada acción y cuándo.

Ensaye un simulacro de respuesta a credenciales

Realice un ejercicio de mesa o controlado alrededor de una clave copiada. Comience con una señal creíble, como tráfico sostenido fuera de horario más errores repetidos de limitación de tasa. Pida a la persona de guardia que identifique al propietario, confirme la cuenta de proveedor afectada, deshabilite la credencial, detenga o aísle la carga de trabajo y compruebe el host en busca de persistencia. El equipo debe entonces rotar las credenciales relacionadas, conservar registros y una imagen forense cuando corresponda, notificar al proveedor y determinar si se podía acceder a datos u otros sistemas.

La revocación es el primer paso de contención, no el final de la investigación. La respuesta de METR incluyó detener la instancia comprometida, crear una imagen forense, rotar credenciales, examinar y borrar el portátil del investigador, informar a la empresa del modelo y utilizar asistencia de seguridad externa. La secuencia exacta variará, pero el principio es estable: elimine el acceso actual mientras conserva suficiente evidencia para determinar cómo ocurrió la vulneración y qué más debe cambiar.

Mida el simulacro por el tiempo transcurrido y la información faltante. ¿Cuánto tardaron el descubrimiento, la búsqueda de propiedad, la revocación, el aislamiento del host y el contacto con el proveedor? ¿Qué registros estaban incompletos? ¿Podían quienes respondían distinguir créditos concedidos de uso facturado? Actualice la plantilla de despliegue, el panel y el manual operativo tras cada ejercicio.

Lista de verificación de implementación

• Inventaríe cada servicio de agente expuesto a internet, su propietario, fecha de vencimiento, entorno de nube, credenciales, datos y herramientas.
• Exija autenticación que deniegue por defecto y una revisión básica para la exposición pública o el acceso a credenciales activas.
• Mantenga los secretos del proveedor fuera del contexto legible por el modelo, las transcripciones, las herramientas y los archivos recuperables.
• Use credenciales por aplicación con el ámbito disponible más limitado y una duración práctica.
• Dirija las llamadas a través de un intermediario cuando los controles directos del proveedor no puedan aplicar la política requerida.
• Establezca techos de uso por ejecución y móviles; añada una parada estricta donde el proveedor o el intermediario la admita.
• Supervise solicitudes exitosas, fallidas y limitadas por tasa por credencial y carga de trabajo esperada.
• Alerte sobre desajustes de comportamiento, no solo sobre costo agregado o volumen de tokens.
• Correlacione el uso de modelos con eventos de autenticación y persistencia del host en el panel de agentes.
• Dé a cada alerta una persona responsable, fecha límite, ruta de escalamiento y acción de contención probada.
• Ensaye la revocación de claves, el aislamiento de la carga de trabajo, la preservación de evidencia, la notificación al proveedor y la recuperación.
• Retire credenciales y puntos de conexión públicos cuando termine el experimento y luego verifique que el tráfico se haya detenido.

Los costos descontrolados de API se previenen mejor con límites superpuestos. El aislamiento de secretos bloquea la extracción fácil, las identidades limitadas reducen el radio de impacto, los presupuestos aplicados limitan el consumo, la supervisión del comportamiento acorta la detección y los simulacros de respuesta hacen rutinaria la revocación. Nada depende de adivinar correctamente cómo entrará el próximo atacante. En conjunto, convierten una clave robada de un recurso sin límites en un incidente contenido y observable.