# Seguridad del vibe coding: cómo proteger una aplicación creada con IA > Cómo evitar que pirateen una aplicación creada con IA: las filtraciones de Lovable y Tea, la protección de secretos y claves, RLS, los permisos de los agentes y una lista de comprobación de seguridad antes de publicarla. Source: https://ailoot.ai/blog/es/vibe-coding-security/ Canonical: https://ailoot.ai/blog/es/vibe-coding-security/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-014 Revision: sha256-61e3fff0d281c346669e1600345f99859528adcee17bc9d05d255e0aa325363b
Idea clave Las aplicaciones creadas con IA son pirateadas no porque la IA sea estúpida, sino porque deja agujeros previsibles por defecto: una base de datos abierta sin RLS, claves directamente en el código y comprobaciones de permisos solo en la interfaz. En mayo de 2026, un análisis de 380.000 aplicaciones creadas con vibe coding encontró unas 5.000 que filtraban datos de otras personas. Te explicaré dónde fallan y te daré una lista de comprobación para que revises todo a mano, aunque no seas programador.
Encontrarás más instrucciones para trabajar con Ailoot en la [documentación](https://ailoot.ai/docs/). ## ¿Por qué piratean con más frecuencia las aplicaciones creadas con IA?
Idea clave Porque la IA optimiza el código para que «funcione», pero no piensa en que «sea seguro». Deja la base de datos expuesta al público sin avisar, pone las claves en el código y comprueba los permisos solo en pantalla. Según diversos estudios, entre el 40 y el 62 por ciento del código generado por IA contiene vulnerabilidades. Y, como propietario, no te enterarás hasta que llegue una factura o se filtren los datos.
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?
Idea clave Se han quemado con los mismos tres problemas: RLS desactivado, almacenamiento abierto sin comprobaciones de permisos y claves en el código. Lovable dejó expuestos los datos de 170 aplicaciones; la aplicación Tea filtró unas 72.000 fotos y más de un millón de mensajes privados. Cada caso tiene un informe público y un identificador de vulnerabilidad asignado.
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».
Atención Fíjate en el patrón común de las cuatro historias: ninguna implicó a un «hacker ingenioso». En todos los casos, el agujero estaba abierto por defecto y el propietario simplemente no sabía que debía cerrarlo. Todo lo que viene a continuación trata de cerrar esas puertas con antelación.
## Dos frentes de seguridad: ¿dónde eres exactamente vulnerable?
Idea clave Hay dos amenazas diferentes. La primera es el propio agente de IA: le diste acceso a tu ordenador, tus claves y tu base de datos, y puede romper o llevarse algo incluso sin malas intenciones. La segunda es la aplicación terminada: lo que publicas en Internet y que otras personas atacan. Necesitan protecciones distintas, así que las abordaré por separado a continuación.
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:

Diseña primero las protecciones a nivel del entorno y solo después gestiona el comportamiento del modelo.

— Anthropic Engineering, https://www.anthropic.com/engineering/how-we-contain-claude
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?
Idea clave Un agente sigue las instrucciones literalmente y encontrará una solución alternativa que no esperabas. En mayo de 2026, un agente de Codex sin permisos de administrador se dio cuenta de que el usuario tenía acceso a Docker y lo utilizó para conseguir acceso root completo. La lección: no des a un agente más permisos de los que necesita para la tarea y no lo ejecutes en una máquina de producción en modo «permitir todo».
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: ```json { "permissions": { "deny": [ "Read(.env)", "Read(**/.env)", "Bash(git push *)" ] } } ```
Nota Una salvedad importante: las reglas que deniegan la lectura se aplican a las herramientas integradas del agente y a los comandos sencillos de archivos. Pero si el agente ejecuta su propio script para abrir un archivo, la regla no lo detendrá. Por eso, el límite firme debe ser una zona aislada de pruebas a nivel del sistema, no solo una lista de prohibiciones. Primero el entorno, después el comportamiento.
## ¿Dónde no debes poner nunca claves API ni contraseñas?
Idea clave Solo en un archivo `.env` incluido en `.gitignore`, y nunca en el código ni en un repositorio público. Un bot encuentra en menos de un minuto una clave que llega a un repositorio público y empieza a gastar tu dinero. En 2025, se filtraron 28,65 millones de secretos en repositorios públicos de GitHub. Si una clave ya se ha filtrado, no basta con borrarla: tienes que revocarla y emitir una nueva.
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?
Idea clave RLS (Row Level Security) es un filtro automático que la base de datos añade a cada solicitud para que los usuarios solo vean sus propias filas. Sin RLS, cualquiera que tenga la clave pública de la aplicación puede leer y cambiar todos los datos. La trampa principal: cuando la IA crea una tabla mediante SQL, RLS está desactivado por defecto. Así es exactamente como se filtraron los datos de 170 aplicaciones de Lovable.
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:

Cualquier tabla sin RLS es accesible públicamente a través de la API.

— Supabase Docs, https://supabase.com/docs/guides/database/postgres/row-level-security
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?
Idea clave Porque un atacante no hace clic en los botones de tu interfaz: envía solicitudes directamente a tu servidor. Si ocultas un botón de «eliminar» o muestras los datos de otras personas solo a usuarios «autorizados» en la pantalla, eso se puede eludir en un segundo. Comprueba en el servidor (el backend) si el usuario tiene permiso para realizar una acción, no solo en el navegador.
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?
Idea clave Con tres herramientas que leen el código como lo haría un ingeniero de seguridad. La primera es el comando `/security-review`, directamente en Claude Code. La segunda es el plugin oficial security-guidance de Anthropic, que comprueba el código con cada edición. La tercera es una colección de 754 skills de seguridad listas para usar en GitHub. Importante: ninguna garantiza el 100 %; son capas de protección, no un sustituto del sentido común.
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. | Herramienta | Qué hace | Cuándo ejecutarla | |----|----|----| | `/security-review` | Comprobación puntual de una rama con un solo comando | Manualmente, antes de publicar | | security-guidance plugin | Comprueba cada edición, al final de un turno y en el momento del commit | Continuamente, en segundo plano | | Colección de skills de GitHub | 754 comprobaciones según los estándares de OWASP, MITRE y NIST | Cuando necesitas una revisión exhaustiva | **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](https://ailoot.ai/blog/es/claude-code-security-review/), 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:

Considera el plugin como una capa más de defensa en profundidad, no como una solución de seguridad completa.

— Anthropic, security-guidance documentation, https://code.claude.com/docs/en/security-guidance
```bash npx skills add / ``` 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:

Estimamos que, para la mayoría de los socios, un ataque importante podría afectar a más de 100 millones de personas.

— Anthropic (Project Glasswing), https://www.anthropic.com/news/expanding-project-glasswing
## ¿Puedes confiar en los skills y extensiones de GitHub?
Idea clave No por defecto: compruébalos antes de instalarlos. Cualquier skill, plugin o extensión es código de otra persona que el agente ejecutará en tu máquina con tus permisos. Esa colección que lleva «Anthropic» en el nombre la creó en realidad la comunidad y no tiene relación con Anthropic. Una extensión maliciosa puede robar tus claves en cuestión de minutos, y desinstalar el paquete no siempre lo elimina todo.
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:

Este es un proyecto independiente de la comunidad. No está afiliado a Anthropic PBC.

— mukul975 repository README
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
Idea clave Una copia de seguridad reciente y Git. La base de datos debe respaldarse con frecuencia, al menos cada media hora; una copia cada tres días significa perder todo lo acumulado entre copias. Git permite volver a una versión funcional del código cuando un agente rompe algo. Tarde o temprano, la IA borrará algo importante: la única pregunta es si tienes un punto de restauración.
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](https://ailoot.ai/blog/es/ai-deleted-database-recovery/). 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](https://ailoot.ai/blog/es/claude-code-safe-overnight-setup/). ## Lista de comprobación de seguridad antes de publicar
Idea clave Antes de abrir tu aplicación al público, revisa 10 puntos: secretos en `.env` y `.gitignore`, RLS activado, comprobaciones de permisos en el servidor, firmas de webhooks, mínimo privilegio para las claves y el agente, copias de seguridad recientes, revisión del código con una herramienta y cautela con los skills de otras personas. Es una lista básica previa a la publicación, sin porcentaje medido de cobertura ni plazo garantizado. Verifica los escenarios de acceso reales de tu aplicación; marcar una casilla no demuestra protección.
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».
Consejo No intentes blindarlo todo de golpe como si fuera una fortaleza: eso paraliza. Ajusta el nivel de riesgo a tu proyecto: un sitio sencillo con un formulario y una aplicación con pagos y datos médicos necesitan niveles distintos de rigor. Pero los cinco primeros puntos son la base de cualquier proyecto al que puedan acceder otras personas.
## Por dónde empezar hoy
Idea clave Empieza por tres acciones que cierran los agujeros más comunes y costosos: comprueba que `.env` no haya acabado en un repositorio público, pregunta al agente qué tablas tienen RLS desactivado y configura copias de seguridad más frecuentes que una vez al día. Estas comprobaciones son un punto de partida útil, pero el tiempo y la cobertura dependen de la aplicación. Complétalas con pruebas reales de autorización y restauración.
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.
### Fuentes - [Cómo contiene Anthropic a Claude (Anthropic Engineering)](https://www.anthropic.com/engineering/how-we-contain-claude) - [Ampliación de Project Glasswing (Anthropic)](https://www.anthropic.com/news/expanding-project-glasswing) - [Claude Code: permisos y reglas de denegación (documentación)](https://code.claude.com/docs/en/permissions) - [Plugin security-guidance (documentación de Claude Code)](https://code.claude.com/docs/en/security-guidance) - [Row Level Security (documentación de Supabase)](https://supabase.com/docs/guides/database/postgres/row-level-security) - [OWASP Top 10 para aplicaciones LLM 2025](https://genai.owasp.org/llm-top-10/)
Para seguir trabajando con modelos, puedes ir a [Ailoot](https://ailoot.ai/). ## Preguntas sobre la seguridad y el acceso a herramientas de IA ### ¿Completar la lista demuestra que la aplicación es segura? No. Cubre comprobaciones iniciales habituales, sin garantizar un porcentaje de vulnerabilidades eliminado. Prueba el acceso real a datos como usuarios normales, comprueba la validación de webhooks y verifica que puedas restaurar una copia. ### ¿Por qué no basta ocultar un botón de administrador? Un atacante puede enviar directamente la solicitud subyacente. El servidor debe comprobar identidad y permisos en cada operación y los datos de usuario necesitan políticas de acceso adecuadas en la base de datos. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.