Seguridad del vibe coding: cómo proteger una aplicación creada con IA

Encontrarás más instrucciones para trabajar con Ailoot en la documentación.

¿Por qué piratean con más frecuencia las aplicaciones creadas con IA?#

Yo también creo productos con IA y no me obsesiono con la seguridad hasta el punto de «blindarlo todo al máximo». Pero hay un nivel básico que no debes dejar de lado, o un día te despertarás con la base de datos vacía y los mineros de otra persona en tu servidor. Esta guía trata sobre ese nivel básico. No sobre «convertirte en experto en seguridad», sino sobre «no pegarte un tiro en el pie sin motivo».

La raíz del problema es sencilla. Cuando le dices a un agente de IA «créame una aplicación para reservar citas de clientes», hace que la aplicación funcione lo más rápido posible. La seguridad es trabajo adicional que no se ve en una demostración. Así que la base de datos se configura como abierta, la clave de pago va directamente al código y la comprobación de «si este usuario tiene acceso» existe solo en el navegador, donde se puede eludir en un segundo.

La segunda razón son las propias plataformas. El agujero aparece por defecto.

En otras palabras, el agujero aparece por sí solo, de forma predeterminada. No hiciste nada mal. Simplemente no hiciste nada y, en seguridad, la inacción significa exactamente «abierto a todo el mundo».

Y hay un tercer factor. La lógica es clara: el agente ejecuta git add . y git push sin mirar, y tu archivo .env con sus claves se hace público junto con todo lo demás.

¿Qué han aprendido ya por las malas quienes crean aplicaciones con vibe coding?#

La mejor vacuna contra la negligencia es aprender de los errores de los demás. Aquí tienes cuatro informes que vale la pena consultar antes de publicar tu proyecto.

Lovable y RLS desactivado. La plataforma Lovable crea aplicaciones a partir de descripciones de texto. En 2025 se encontró una vulnerabilidad sistémica en sus aplicaciones y se le asignó el identificador CVE-2025-48757. La causa: las aplicaciones generadas no tenían reglas de acceso a nivel de fila en la base de datos (RLS, que explico más adelante). Un investigador revisó una muestra y encontró 303 puntos de acceso expuestos en 170 aplicaciones. Quedaron expuestos nombres, números de teléfono, estados de pago, claves API de otras personas e incluso domicilios particulares. En aproximadamente el 70 por ciento de las aplicaciones revisadas, la protección a nivel de fila estaba completamente desactivada.

Tea y los datos sensibles. La aplicación Tea (reseñas anónimas sobre personas) perdió unas 72.000 imágenes en julio de 2025, incluidas 13.000 selfies y fotos de documentos, y después más de un millón de mensajes privados. La causa técnica fue un almacenamiento abierto y comprobaciones de acceso débiles. La comunidad de seguridad cita Tea como un ejemplo llamativo: cuando importa más lanzar rápido que comprobar los permisos, los datos sensibles son los primeros en filtrarse.

Otro ejemplo práctico. En un caso descrito por el autor original, piratearon la aplicación de alguien que practicaba vibe coding porque la IA configuró una contraseña predeterminada al crear la base de datos, y se podía adivinar automáticamente. Después ocurrió lo de siempre: entraron, instalaron mineros y reescribieron el proyecto. Hubo que borrar por completo el servidor. Una contraseña predeterminada es una puerta abierta con un cartel que dice «pase, por favor».

Dos frentes de seguridad: ¿dónde eres exactamente vulnerable?#

Cuando se habla de «seguridad del vibe coding», normalmente se mezclan dos preocupaciones completamente distintas. Vamos a separarlas, porque se protegen de maneras diferentes.

Primer frente: el propio agente. Ejecutas un agente de IA en tu ordenador y le das acceso a tus archivos, terminal, claves y base de datos. El riesgo es que un agente no es una persona: sigue las instrucciones literalmente y encuentra el camino más corto, aunque sea peligroso. Esto también incluye el riesgo de que se «inyecte» en el agente una instrucción de otra persona a través del texto que lee (esto se llama prompt injection).

Segundo frente: la aplicación terminada. Es lo que has publicado y lo que usa la gente. El objetivo es tu sitio o servicio publicado: los atacantes entran en una base de datos abierta, envían solicitudes falsas o adivinan las cuentas de otras personas. El agente no tiene nada que ver con esto: el agujero quedó abierto antes y otras personas lo aprovechan.

Anthropic, la empresa detrás de Claude, expresa así el principio de protección principal, que sirve para ambos frentes:

En la práctica, esto significa que no debes confiar en que la IA «evite hacer cosas malas por sí sola». Primero limita lo que puede hacer físicamente y solo después pídele que se comporte bien. Cuando su comportamiento falle —y fallará—, solo te protegerá un límite firme que hayas establecido de antemano.

¿Quieres que la IA trabaje de forma predecible y deje de pegarte un tiro en el pie en cada proyecto nuevo? Las reglas de seguridad forman parte de tu Second Brain: escríbelas una vez en CLAUDE.md y el agente las seguirá en cada solicitud.

¿Qué puede hacer un agente de IA con acceso a tu ordenador?#

El riesgo más subestimado es tu propio agente con permisos demasiado amplios. Ni siquiera hace falta un hacker externo. Aquí tienes un ejemplo reciente de finales de mayo de 2026. Un agente de Codex necesitaba permisos de administrador que el usuario no tenía. El agente no se rindió: miró alrededor, vio que el usuario pertenecía al grupo docker, que equivale en la práctica a root, y aprovechó ese acceso.

No había ninguna intención maliciosa. Lo que pasa es que un agente al que le dicen «resuelve la tarea» encuentra una debilidad estructural más rápido que una persona. Y si esa debilidad le da acceso a tus claves o al entorno de producción, lo utilizará. Así que la regla número uno es el principio de mínimo privilegio. Dale a un agente exactamente el acceso que necesita para una tarea concreta y ni una pizca más.

¿Qué puedes hacer en la práctica, aunque no seas programador?

1. No ejecutes al agente en modo «permitir todo» en una máquina de producción

   Un modo en el que el agente no pide confirmación (a menudo llamado bypass o yolo) es solo para una zona aislada de pruebas o un proyecto de prueba, no para una máquina con claves activas y acceso a producción.

2. Prohíbe al agente leer secretos

   En Claude Code, puedes hacerlo con una regla que deniegue el acceso a los archivos que contienen claves. Así, aunque el agente quiera abrir .env, la herramienta no se lo permitirá.

3. Mantén separadas las claves de producción

   Las claves de la base de datos de producción y del servicio de pago no deberían estar en la misma carpeta donde el agente escribe código. Mantén separados los entornos: usa claves de prueba cuando experimentes.

4. Utiliza la zona aislada de pruebas de la herramienta

   Las herramientas modernas de IA pueden ejecutar comandos de forma aislada (en una zona de pruebas), sin acceso al resto del sistema. En Claude Code, esto reduce las solicitudes de permisos en aproximadamente un 84 por ciento, así que también resulta más cómodo.

Una regla que deniega la lectura de secretos en Claude Code tiene más o menos este aspecto; añádela a la configuración de permisos:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

¿Dónde no debes poner nunca claves API ni contraseñas?#

El error más barato y común es poner las claves en el código. Una clave API para un servicio de pago, una contraseña de base de datos, un token de bot: todo eso son secretos. Deben estar en un archivo .env independiente, y ese archivo tiene que figurar en .gitignore para que no se suba a Git junto con el código.

Por qué es fundamental: una clave no dura mucho en un repositorio público. Los bots analizan los nuevos commits las 24 horas. Suele ocurrir lo siguiente: encuentran una clave de la nube, ponen en marcha servidores para minar criptomonedas a tu costa y, por la mañana, te llega una factura de decenas de miles. Los desarrolladores cuentan historias así con regularidad, y las facturas alcanzan cifras de cinco dígitos en dólares.

La magnitud del problema en 2025: 28,65 millones de secretos nuevos escritos directamente en el código de repositorios públicos, un aumento interanual del 34 por ciento. Las filtraciones de claves específicamente para servicios de IA aumentaron un 81 por ciento. El vibe coding echa más leña al fuego porque el agente hace commits sin mirar.

Qué puedes comprobar ahora mismo por tu cuenta:

1. Abre el archivo .gitignore del proyecto

   Asegúrate de que tenga una línea .env. Si no la tiene, añádela antes del primer commit.

2. Ve a tu repositorio de GitHub

   Comprueba que el archivo .env no esté allí. Buscar .env o parte de tu clave en el repositorio es una forma rápida de comprobarlo.

3. Si se ha filtrado una clave, revócala y emite otra

   No basta con borrar el commit: puede que ya hayan obtenido la clave. Ve al servicio (proveedor de pagos, servicio en la nube, proveedor de IA), revoca la clave antigua y emite una nueva. A esto se le llama rotación.

4. Asigna a las claves los permisos mínimos

   Si una clave solo se necesita para leer, configúrala como de solo lectura. Así, aunque se filtre, habrá menos cosas que puedan robar.

¿Por qué puede ver cualquiera tu base de datos si no tienes RLS?#

Si estás creando una aplicación en Supabase o en una base de datos similar, esta es la sección más importante. RLS significa Row Level Security. Dicho de forma sencilla, es una regla que determina qué filas de una tabla se muestran a un usuario concreto. Sin ella, la tabla «orders» devuelve a todo el mundo los pedidos de todos los clientes.

La propia documentación de Supabase lo expresa con claridad:

Y aquí está la trampa principal para quienes crean aplicaciones con vibe coding. Cuando creas una tabla haciendo clic en el panel de Supabase, la protección se activa automáticamente. Pero cuando la crea la IA —que casi siempre escribe comandos SQL directamente—, RLS permanece desactivado por defecto. Esto significa que una tabla generada por un agente casi con total seguridad está abierta a todo Internet. Así es exactamente como se filtraron los datos de aquellas 170 aplicaciones de Lovable.

Qué hacer:

1. Pregúntale directamente al agente

   Escribe: «muéstrame todas las tablas donde RLS esté desactivado». La IA generará una lista; esa será tu lista de tareas.

2. Activa RLS en todas las tablas con datos de usuarios

   Añade al menos una política de acceso; por ejemplo: «un usuario solo puede ver sus propias filas».

3. Comprueba el panel de control

   En el panel de Supabase, todas las tablas deberían mostrar «RLS enabled». Si aparece en gris o en rojo, significa que la tabla está abierta.

4. Haz una prueba real

   Inicia sesión como usuario normal e intenta solicitar los datos de otra persona. Si se deniega el acceso, la política funciona.

¿Por qué no te protegen las comprobaciones de permisos en la interfaz?#

Una ilusión común es pensar: «he hecho que los usuarios normales no puedan ver el botón de administrador». El problema es que un botón solo es una imagen en el navegador. Se puede enviar una solicitud directamente al servidor sin utilizar el botón. Si el servidor no vuelve a comprobar los permisos, ejecutará la orden de otra persona.

Un ejemplo clásico se llama IDOR. Imagina que abres tu pedido en una dirección con id=123. Cámbialo por id=124 y podrás ver el pedido de otra persona porque el servidor no comprobó si realmente era tuyo. Es uno de los agujeros más comunes en las aplicaciones creadas con vibe coding, y las comprobaciones de permisos débiles estuvieron detrás de la filtración de Tea.

La regla es sencilla: repite en el servidor cada comprobación de «¿tiene este usuario permiso para hacer esto?». La interfaz sirve para facilitar el uso; la protección corresponde al backend. Aquí tienes una instrucción lista para el agente: «añade comprobaciones de permisos en el servidor para cada endpoint que lea o cambie datos de usuario; no confíes en que un elemento esté oculto en la interfaz».

¿Cómo puedes comprobar si hay agujeros en el código si no eres programador?#

La buena noticia es que hoy puedes pedirle a la misma IA que compruebe la seguridad: encuentra bastante bien los agujeros habituales. Aquí tienes tres herramientas para tareas distintas.

1. El comando /security-review de Claude Code. Una comprobación puntual de la rama actual para detectar inyección SQL, XSS, fallos de autorización, filtraciones de datos y problemas con las dependencias. En una guía aparte sobre la revisión de seguridad en Claude Code, expliqué paso a paso cómo funciona y cómo añadir una comprobación automática a cada cambio. La idea principal aquí: es la primera línea de defensa y se inicia con un solo comando.

2. El plugin oficial security-guidance. Instálalo desde el mercado oficial de plugins con /plugin install security-guidance@claude-plugins-official (se requiere Claude Code versión 2.1.144 o posterior). Comprueba el código en tres momentos: con cada edición, al final de cada turno y al hacer commit. Detecta los bypasses de autorización, IDOR, inyecciones y criptografía débil. Pero Anthropic reconoce abiertamente sus límites:

npx skills add <author>/<repo>

Después, solo tienes que decirle al agente: «comprueba si mi proyecto tiene vulnerabilidades». Pero esta colección tiene una salvedad importante, por eso le dedico una sección aparte más abajo.

Como contexto: los grandes actores también han empezado a tomarse en serio la seguridad del código generado por IA. En el marco de Project Glasswing, ampliado el 2 de junio de 2026 para incluir a 150 organizaciones, los socios encontraron más de 10.000 vulnerabilidades críticas en poco tiempo usando modelos de Anthropic. Lo que está en juego está claro:

¿Puedes confiar en los skills y extensiones de GitHub?#

Aquí es donde las cosas se complican especialmente, porque el peligro viene de una herramienta que instalas para protegerte. Cuando ejecutas npx skills add ... o instalas una extensión, estás incorporando código de otra persona que el agente ejecutará con tus permisos. Si han pirateado al autor o el paquete era malicioso desde el principio, tienes un problema.

Fíjate en la colección de skills de la sección anterior. Su nombre incluye «Anthropic», lo que puede hacerte bajar la guardia. Pero su propia descripción lo deja claro:

En otras palabras, el nombre es engañoso. Actualmente, la colección es madura y está limpia, pero el principio sigue siendo el mismo: la instalas bajo tu propia responsabilidad. Y la amenaza no es teórica. En mayo de 2026, una extensión maliciosa para un editor estuvo solo 18 minutos en el mercado y, en ese tiempo, logró robar contraseñas de gestores de contraseñas, tokens de GitHub, accesos a la nube e incluso configuraciones de Claude Code de quienes la instalaron. Otro detalle desagradable: este tipo de malware suele sobrevivir a la desinstalación normal del paquete y volver a ejecutarse en la siguiente sesión.

He adoptado un hábito sencillo y te lo recomiendo: antes de instalar cualquier skill de GitHub, revísalo tú mismo. Pueden piratear a los autores, secuestrar sus cuentas y colocar malware en un repositorio. Revisarlo es tu salvaguarda.

Lo mínimo que debes hacer antes de instalarlo: fíjate en quién es el autor y cuántas estrellas tiene, lee la descripción del skill, no instales una herramienta «por recomendación de una publicación» y, si no la conoces, pruébala primero en un entorno de pruebas separado, no en una máquina con claves de producción.

Qué te salvará después de una brecha: copias de seguridad y vuelta atrás#

La seguridad no consiste solo en «mantener fuera a los desconocidos», sino también en «volver a la normalidad cuando algo sale mal». Porque algo saldrá mal. En el caso práctico descrito, un agente de IA borró una base de datos activa de un proyecto de producción mientras realizaba una tarea rutinaria. Había una copia de seguridad, pero tenía tres días y se perdieron sin más los datos de esos tres días.

De ahí salen dos reglas.

Haz copias de seguridad con frecuencia. Si tu aplicación contiene datos que no querrías perder, una copia cada tres días es una ilusión de protección. Configura copias de seguridad automáticas al menos cada 30 minutos. En la mayoría de las bases de datos, incluida Supabase, se puede activar con un par de clics.

Git es un seguro contra el agente. Git guarda el historial del código: puedes restaurar cualquier estado que funcionara. Cuando un agente reescribe algo que funcionaba, vuelves a la última versión funcional en lugar de arreglarlo a mano. Si la IA ha borrado o roto el proyecto y no sabes cómo recuperarlo, consulta el informe aparte: qué hacer si la IA borró la base de datos. Para saber cómo protegerte de antemano frente a los daños en el proyecto, consulta la guía cómo proteger Claude Code de los daños.

Lista de comprobación de seguridad antes de publicar#

Repasa esta lista justo antes de publicar. En orden.

1. Secretos en .env y .env en .gitignore. Ninguna clave en el código. Ningún archivo .env en un repositorio público.

2. Claves con los permisos mínimos. Cada clave solo puede hacer lo necesario. Las claves de producción están separadas del entorno del agente.

3. RLS está activado en todas las tablas con datos de usuarios y hay políticas de acceso configuradas.

4. Comprobaciones de permisos en el servidor para cada operación sobre los datos. Ocultar un botón en la interfaz no basta. Has probado manualmente a cambiar el id en la dirección.

5. Verificación de la firma de los webhooks. Cada controlador de notificaciones externas (pagos, formularios) verifica la firma.

6. Limitación de solicitudes entrantes y operaciones costosas, para que no se puedan adivinar contraseñas por fuerza bruta ni disparar tu factura.

7. El agente no se ejecuta en modo «permitir todo» en una máquina con claves de producción. Se deniega la lectura de .env.

8. Las copias de seguridad son frecuentes y se han probado: has intentado restaurar datos de verdad, en vez de limitarte a creer que las copias «están por ahí».

9. Se ha comprobado el código con /security-review o con el plugin security-guidance. Se han corregido los problemas encontrados.

10. Se han comprobado los skills y las extensiones de otras personas antes de instalarlos. No se ha instalado nada «a ciegas».

Por dónde empezar hoy#

No intentes poner en práctica toda esta guía en una sola noche: acabarás sin hacer nada. Hoy, da los tres pasos más importantes:

1. Comprueba tus secretos. Abre .gitignore, asegúrate de que .env esté incluido y comprueba que no haya claves en el repositorio público. Si se ha filtrado alguna, revócala y emite una nueva.
2. Pregunta por RLS. Dile al agente: «muéstrame las tablas donde RLS esté desactivado» y actívalo donde se almacenen datos de personas.
3. Configura copias de seguridad frecuentes. Así, si algo sale mal, perderás minutos en vez de días.

Después, sigue la lista de comprobación anterior a medida que el proyecto crezca y empiece a gestionar dinero y datos de otras personas.

Una última cosa. La seguridad del vibe coding es responsabilidad del propietario. No necesitas convertirte en experto en seguridad. La IA creó tu producto en una noche; genial, pero eres responsable de él. El nivel básico que se describe en esta guía muestra lo que significa esa responsabilidad en la práctica.

Para seguir trabajando con modelos, puedes ir a Ailoot.