Incluso Google no puede mantenerse al día: La seguridad en la era de la IA se ha convertido en una lucha "en cuestión de segundos"

Incluso Google ha entrado en la era de "proteger mientras se corre"

La IA es una herramienta que aumenta la productividad de las empresas, pero al mismo tiempo se convierte en una nueva superficie de ataque para los responsables de seguridad. La IA generativa, los agentes internos, los datos de aprendizaje, los prompts, los SaaS externos, los entornos multicloud. Antes, la defensa se centraba en los límites de la red, los terminales, los servidores y la gestión de identidades, pero ahora se ha expandido a "todo lo que toca la IA".

Las declaraciones de Francis de Souza, COO de Google Cloud, reportadas por TechCrunch, simbolizan este cambio. De Souza enfatiza que si las empresas van a adoptar la IA, la seguridad no debe ser un añadido posterior, sino que debe estar integrada desde el diseño de la plataforma. El "Shadow AI", el manejo de datos a través de múltiples nubes, la auditabilidad, la gobernanza; estos ya no son problemas solo del departamento de sistemas de información, sino riesgos que deben ser tratados por la alta dirección y la junta directiva.

Lo especialmente importante es que la adopción de IA no se trata solo de "añadir nuevas funciones convenientes". Cuando los agentes de IA comienzan a operar a través de los sistemas internos, pueden desenterrar antiguos depósitos de datos olvidados, permisos de acceso no actualizados, SharePoints abandonados y archivos de trabajo antiguos. Los datos que antes "no eran un problema porque nadie los encontraba" ahora se hacen visibles rápidamente gracias a la IA. Es decir, la IA no solo descubre a los atacantes, sino también las "deficiencias de gestión pasadas" dentro de la empresa a gran velocidad.

Los ataques avanzan en "segundos", no en "horas"

De Souza explica que el tiempo promedio para avanzar de una violación a la siguiente etapa de un ataque se ha reducido de horas a segundos. Esto tiene un significado extremadamente serio para los responsables de seguridad. Mientras los humanos miran alertas, verifican la situación, reúnen a las partes interesadas, toman decisiones y bloquean manualmente, el ataque ya ha avanzado a la siguiente etapa.

La respuesta de Google Cloud a esta situación es la "defensa nativa de IA". En lugar de que los humanos operen todo directamente, los agentes de IA supervisan, defienden y responden inicialmente, mientras los humanos supervisan. Si los ataques avanzan a la velocidad de las máquinas, la defensa también debe moverse a esa velocidad.

Este enfoque es razonable, pero también tiene una gran contradicción. Para proteger usando IA, esa IA debe ser segura. Los datos que la IA consulta, las API que llaman a la IA, la información de autenticación que usa la IA, el sistema de facturación que gestiona los costos de uso de la IA. Si hay agujeros en esas bases, la defensa de IA se convierte en un nuevo riesgo en lugar de una protección.

El colapso de los "supuestos antiguos" mostrado por el problema de las claves API de Gemini

Lo interesante del artículo de TechCrunch es que no solo presenta las recomendaciones de seguridad de Google Cloud, sino que también aborda los problemas que enfrenta Google. En particular, se destacó la serie de problemas de facturación elevados relacionados con la API de Gemini.

El problema central es el manejo de las claves API de Google Cloud. Durante años, en servicios como Google Maps o Firebase, no era raro que las claves API se incrustaran en el código del lado del cliente. Para los desarrolladores, esto no siempre se percibía como "publicar una contraseña". Se trataba como una clave que se podía hacer pública para la identificación del servicio y la facturación.

Sin embargo, cuando se habilitan servicios de inferencia de IA costosos como la API de Gemini en el mismo proyecto, las claves API existentes pueden estar disponibles para solicitudes de IA. Si esas claves permanecen en JavaScript de sitios web antiguos, repositorios públicos o configuraciones pasadas, los atacantes pueden encontrarlas y enviar una gran cantidad de solicitudes a Gemini o modelos de generación de imágenes y videos, generando enormes costos en la cuenta de facturación del desarrollador.

Esto no se puede resolver simplemente diciendo que "los desarrolladores no gestionaron bien las claves". Porque algunos desarrolladores usaron las claves siguiendo la documentación y las prácticas comunes de la época. Los identificadores que se consideraban seguros para publicar se convirtieron en algo cercano a la autenticación de servicios de IA costosos. Aquí radica la dificultad de la seguridad en la era de la IA. Un diseño que era seguro hasta ayer puede volverse peligroso con la adición de nuevas funciones hoy.

La desconfianza de que el "límite" no es realmente un límite

Lo que aumentó aún más la desconfianza de los desarrolladores fueron los problemas relacionados con los límites de uso y facturación. Según el informe de The Register, se presentaron casos donde desarrolladores de Google Cloud recibieron facturas de miles a decenas de miles de dólares debido al uso no autorizado de la API. Algunos casos incluyeron situaciones donde el uso mensual, que solía ser de unos pocos dólares, se disparó a más de 10,000 dólares en poco tiempo, o donde un límite de 250 dólares se elevó automáticamente a un umbral más alto basado en el historial de la cuenta.

La lógica de Google es evitar la interrupción del servicio y permitir que los clientes en crecimiento amplíen su uso sin problemas. De hecho, para un servicio legítimo que experimenta un aumento repentino de tráfico, un límite rígido podría ser un obstáculo. En la era del rápido crecimiento de las aplicaciones de IA, la expansión automática de los límites de uso también puede mejorar la experiencia del desarrollador.

Sin embargo, en el momento en que ocurre un uso no autorizado, ese diseño funciona en la dirección opuesta. Para los atacantes, se amplía el margen para usar más con la clave robada. Para los usuarios, se siente como "debería haber un límite, pero no se detiene". Las reacciones más fuertes en las redes sociales también se centraron en este punto. Los desarrolladores claman por "un límite que realmente detenga, no solo una alerta".

La ira y el miedo que se extendieron en Reddit

En r/googlecloud de Reddit, han proliferado publicaciones sobre las facturas elevadas relacionadas con la API de Gemini y Google Cloud. Un usuario explicó que, operando un SaaS B2B, su factura de Google Cloud, que normalmente era de unos 50 dólares al mes, se disparó a más de 10,000 dólares debido a los tokens de salida de imágenes de Veo 3 y Gemini. Aunque no usaba esos servicios en su producto, cuando reportó el uso no autorizado al soporte de Google, inicialmente le dijeron que "no se podía confirmar evidencia de uso no autorizado".

En otra publicación, se informó que una clave API antigua de Google Maps fue mal utilizada después de habilitar la API de Gemini, resultando en una factura de aproximadamente 36,800 euros. En los comentarios, se expresaron sorpresas como "este problema ya debería haber sido reportado, ¿por qué no ha cambiado el comportamiento?" y "me da miedo la consola de Google Cloud. No puedo confiar en tener una clave que pueda generar decenas de miles de dólares".

Un usuario que se identificó como una pequeña empresa japonesa también enfrentó un riesgo de facturación de aproximadamente 128,000 dólares debido al uso no autorizado de la API de Gemini, mencionando incluso la posibilidad de quiebra. En los comentarios, se destacó la opinión de que Google debería proporcionar un "hard stop" opcional, es decir, un mecanismo que detenga el proyecto o la API de manera segura una vez que se supere una cierta cantidad. A medida que más desarrolladores interactúan con Google Cloud debido a la proliferación de herramientas de codificación de IA, la premisa de que "todos pueden proteger perfectamente las claves" se vuelve menos realista.

Las reacciones en Reddit no solo incluyeron ira, sino también sugerencias prácticas para evitar problemas. Propuestas como no usar claves API, cambiar a cuentas de servicio o métodos de autenticación más restringidos, deshabilitar la API de Gemini a nivel organizacional, separar proyectos de servicios públicos y uso de IA, y siempre establecer restricciones de API. En otras palabras, la comunidad, mientras critica la respuesta de Google, también se convirtió en un lugar para compartir medidas de autoprotección.

En Hacker News, las críticas se centran en la "filosofía de diseño"

En Hacker News, las discusiones se centraron más en la filosofía de diseño. En un hilo sobre la investigación de Truffle Security, se criticó que las claves API de Google, que durante mucho tiempo se trataron como "identificadores que se pueden publicar", se convirtieron en llaves para el uso de IA costosa y el acceso a datos debido a Gemini.

En un comentario, se comparó que debería ser posible establecer límites claros de gasto como 10 o 100 dólares por cada clave API. También se mencionó que en servicios como OpenAI u OpenRouter, es más fácil gestionar el gasto por clave o cuenta, y se expresó insatisfacción con las alertas de facturación de Google Cloud debido a su retraso, lo que las hace ineficaces como barrera.

Además, se extendió la crítica de que "esto es como usar un nombre de usuario como contraseña". Por supuesto, hay contraargumentos que dicen que culpar completamente a Google es simplificar demasiado. La API de Gemini no se habilita por defecto en todos los proyectos; el propietario del proyecto debe habilitarla. Por lo tanto, hay una fuerte opinión de que se deben separar los proyectos, restringir las claves y mantener el principio de privilegio mínimo.

Sin embargo, en general, se ve que la IA ha hecho peligrosas las "prácticas antiguas de la nube". Claves que se suponían públicas, inferencias de IA costosas, datos de facturación retrasados, límites de uso que se expanden automáticamente. Aunque cada especificación es explicable individualmente, combinadas se convierten en un riesgo fatal para los pequeños desarrolladores.

El problema de los "23 minutos" que no termina al eliminar la clave

Además, la investigación de Aikido Security planteó otra preocupación. Según su verificación, incluso después de eliminar una clave API de Google, algunas solicitudes pueden seguir siendo autenticadas durante un máximo de aproximadamente 23 minutos. En sistemas distribuidos a gran escala, no es raro que los cambios de configuración tarden en propagarse a todos los servidores. Sin embargo, en lo que respecta a la expiración de la información de autenticación, esa demora se convierte directamente en tiempo de ataque.

Si un atacante tiene una clave filtrada y el usuario se apresura a eliminarla, aún podría enviar una gran cantidad de solicitudes durante un tiempo. Si la API de Gemini está habilitada, no solo se generan costos, sino que también hay un riesgo de acceso a archivos subidos o contenido de conversaciones en caché.

Este punto se acerca al núcleo de la seguridad de la IA. En los recursos de nube tradicionales, puede haber situaciones donde se tolera un retraso de unos minutos. Sin embargo, las solicitudes a modelos de IA son costosas y los datos son altamente confidenciales. En unos minutos, un atacante podría ejecutar una gran cantidad de inferencias. En la era de la IA, la idea de que la autenticación "eventualmente se sincroniza" es peligrosa tanto en términos de costos como de protección de datos.

La recomendación de Google es correcta. Por eso se cuestiona

Lo importante aquí es que la recomendación del COO de Google Cloud no es incorrecta. Una estrategia de IA requiere una estrategia de datos y una estrategia de seguridad, y no se debe dejar el "Shadow AI" sin supervisión. Se debe mantener una postura de seguridad coherente a través de múltiples nubes, SaaS, socios externos y agentes internos. Dado que los ataques se han vuelto tan rápidos como las máquinas, también es necesario utilizar IA para la defensa.

El problema es hasta qué punto los propios proveedores de plataformas pueden ofrecer de manera segura la base para implementar esa recomendación correcta. Si se les dice a las empresas "no añadan la seguridad después", entonces el lado de la nube también debe evitar la situación de "añadir funciones de IA después y hacer que el diseño existente de autenticación y facturación se vuelva peligroso".

Este problema no es solo de Google. Es una advertencia común para todos los proveedores de nube, plataformas de IA y empresas de SaaS. Cuando se incorporan funciones de IA a servicios existentes, es necesario revisar siempre los supuestos de diseño anteriores. Claves que se pueden hacer públicas, claves que solo se usan internamente, límites de facturación, rangos de acceso a datos, procesos de expiración, registros de auditoría, sistemas de soporte. Si se reutilizan las normas anteriores a la IA tal cual, en algún lugar se producirá un colapso.

Lo que las empresas y los desarrolladores deben revisar de inmediato

La lección práctica de este problema es clara. Primero, separar los proyectos que habilitan IA de los que usan frontends públicos, Maps, Firebase, etc. Segundo, establecer restricciones de API y restricciones de aplicación en todas las claves API y deshabilitar las API innecesarias. Tercero, confirmar límites de gasto y cuotas que realmente detengan el uso, no solo alertas de facturación. Cuarto, inventariar las claves que quedan en sitios web antiguos, repositorios antiguos y aplicaciones móviles antiguas. Quinto, en el uso de IA, priorizar el diseño de autenticación con cuentas de servicio, OAuth y privilegios mínimos sobre las claves API.

Y la alta dirección debe tratar la adopción de IA no como una "herramienta conveniente para el campo", sino como un cambio de infraestructura que conlleva riesgos financieros y de fuga de información. Si una fuga de una sola clave puede llevar a facturas de cientos de miles de dólares o a la filtración de datos confidenciales, entonces no es solo un tema para el CISO o el equipo de desarrollo, sino también para el CFO, el departamento legal y las reuniones de gestión.

El verdadero desafío de la seguridad de la IA no es la "diferencia de velocidad", sino el "diseño de la responsabilidad"

La seguridad en la era de la IA ciertamente se está volviendo en tiempo real. Los ataques son rápidos y la defensa también debe ser rápida. Pero el verdadero desafío no es solo la velocidad. ¿Quién asume el riesgo? ¿Quién tiene la autoridad para detenerlo? ¿Qué es seguro por defecto? ¿Qué se debe priorizar, el diseño para evitar fallos o el diseño para detener el uso no autorizado? En otras palabras, se cuestiona el "diseño de la responsabilidad".

Incluso Google está avanzando a tientas en esta fase de transición. Por eso es peligroso que otras empresas avancen en la adopción de IA sin protección. Si se espera que la IA pueda proteger, detectar y automatizar, antes de eso, se deben revisar los sistemas de autenticación, facturación, datos, permisos y auditoría que rodean a la IA.

La seguridad de la IA no es un tema del futuro. Ya estamos en una etapa donde una sola clave API, un solo proyecto antiguo o una alerta retrasada pueden determinar la supervivencia de una empresa.

URL de la fuente

TechCrunch "Everyone is navigating AI security in real time — even Google"
Declaraciones de Francis de Souza, COO de Google Cloud, sobre la seguridad de la IA, Shadow AI, multicloud, defensa basada en agentes, y referencia a los problemas relacionados con la API de Gemini.
https://techcrunch.com