🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónEl encargo de ataque a una app con IA: evidencia e informe
4 tareas · 25 min · Principiante
El módulo 6 ya fijó la regla dura: sin reproducción no hay hallazgo, y fabricar evidencia es fraude. El módulo 7 ya fijó que los datos del cliente no salen a un tercero y que el prompt también es un canal de fuga. Esta sala no repite eso: cierra tres huecos que quedan cuando el encargo es, específicamente, auditar una app con un componente de IA y escribir el informe con un modelo al lado. Qué pasa cuando el modelo le pone a un fallo de diseño propio el nombre de una vulnerabilidad de producto que no existe, qué pasa cuando la misma sesión de un modelo se usa para dos clientes distintos, y quién decide la severidad de un hallazgo cuando el modelo ofrece una etiqueta sin más respaldo que el patrón del título. Se razona sobre el borrador; nada se envía ni se publica.
Objetivo de la sala
El módulo 6 ya fijó la regla dura: sin reproducción no hay hallazgo, y fabricar evidencia es fraude. El módulo 7 ya fijó que los datos del cliente no salen a un tercero y que el prompt también es un canal de fuga. Esta sala no repite eso: cierra tres huecos que quedan cuando el encargo es, específicamente, auditar una app con un componente de IA y escribir el informe con un modelo al lado. Qué pasa cuando el modelo le pone a un fallo de diseño propio el nombre de una vulnerabilidad de producto que no existe, qué pasa cuando la misma sesión de un modelo se usa para dos clientes distintos, y quién decide la severidad de un hallazgo cuando el modelo ofrece una etiqueta sin más respaldo que el patrón del título. Se razona sobre el borrador; nada se envía ni se publica.El hallazgo central del engagement de Astilla es que su chatbot no separa instrucción de dato de usuario —un fallo de diseño propio de esa aplicación, no de ningún producto con versión y parche—. Al redactar, el modelo le añade un identificador de vulnerabilidad de catálogo público, porque «suena más formal» y el título se parece al de otros casos que vio. El problema no es cosmético: un identificador de ese tipo le dice al cliente que existe un parche del fabricante que instalar, cuando la corrección real es rediseñar cómo su aplicación trata el texto que llega al modelo.
Un fallo de arquitectura propia se describe como lo que es —una decisión de diseño que hay que cambiar—, nunca con la etiqueta de una vulnerabilidad de un producto de terceros que no aplica.
Esta tarea se hace en el laboratorio
Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.
Para responder aquí hace falta una cuenta
Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.
Responde para continuar
El modelo le añade un identificador de vulnerabilidad de catálogo público a un hallazgo que es un fallo de diseño propio de la app de Astilla, sin relación con ningún producto de terceros. ¿Qué se hace?
Ver pista de ayuda
Un identificador de producto implica que hay un parche del fabricante. Aquí la corrección es rediseñar el flujo propio de Astilla, no instalar nada.
Llevas dos engagements activos y usas la misma sesión de modelo para redactar los dos, «para no perder el hilo del estilo». Al revisar el borrador de Astilla aparece un párrafo entero que describe la arquitectura de otro cliente: el modelo arrastró contexto de la conversación anterior y lo mezcló sin avisar. No hace falta que haya subido nada a propósito: la sesión compartida es, ella sola, el canal de la fuga entre dos clientes que nunca debieron verse en el mismo documento.
La regla es simple y se pone antes de escribir la primera línea: una conversación o instancia de modelo por cliente, nunca una que continúe de un informe al siguiente.
Esta tarea se hace en el laboratorio
Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.
Para responder aquí hace falta una cuenta
Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.
Responde para continuar
El borrador del informe de Astilla incluye un párrafo que describe la arquitectura de otro cliente, porque reutilizaste la misma sesión de modelo para los dos engagements. ¿Qué falló?
Ver pista de ayuda
No hizo falta pegar nada a propósito. Compartir la sesión entre dos clientes ya mezcla lo de uno con lo del otro.
El modelo entrega el hallazgo del chatbot marcado como «Crítico», sin vector de puntuación ni justificación: el título «fuga de instrucciones internas» encaja con el patrón de otros casos críticos que procesó. Pero la severidad depende del impacto real en Astilla —qué hay en esas instrucciones, a qué herramientas conectadas se llega desde ahí, qué puede hacer alguien con eso—, algo que el modelo no conoce de este cliente concreto. Aceptar la etiqueta porque «el modelo lo marcó así» es delegar exactamente la decisión que el módulo 1 ya dijo que no se delega.
La severidad la calcula el operador con el impacto verificado de este engagement, nunca la etiqueta que trae el borrador.
Esta tarea se hace en el laboratorio
Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.
Para responder aquí hace falta una cuenta
Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.
Responde para continuar
El modelo marca un hallazgo como "Crítico" sin vector de puntuación, porque el título encaja con el patrón de otros casos. ¿Qué corresponde?
Ver pista de ayuda
El modelo reconoce patrones de texto, no el impacto real de este cliente. La severidad la decide quien verificó el alcance de lo que se puede hacer con el hallazgo.
Abre la estación. El borrador del informe de Astilla trae un párrafo que no es de Astilla. Localiza la revisión que confirma de qué cliente es y por qué no puede quedarse.
Esta tarea se hace en el laboratorio
Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.
Para responder aquí hace falta una cuenta
Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.
Responde para continuar
Un párrafo del borrador describe la arquitectura de otro cliente, no la de Astilla. Abre la revisión de fugas entre clientes, confirma a qué cliente pertenece ese párrafo y escribe el código que acompaña a esa conclusión.
Formato esperado: IAO-____
Ver pista de ayuda
Lee ~/informe/revision-fugas.txt. El párrafo ajeno queda identificado con el nombre del otro cliente; el código está en esa misma línea.
Preparando la estación…
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio y la seguridad de tu sesión y, solo si lo autorizas, analítica. Puedes aceptar, rechazar o personalizar. Política de Cookies · Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Medimos con Google Analytics cómo se usa la plataforma; solo si lo aceptas
Google Analytics (cookies _ga) nos dice qué páginas se usan y dónde se atascan las personas. No enviamos tu nombre ni tu correo. Sin tu permiso no se carga, y puedes cambiarlo cuando quieras desde «Cookies» al final de la página.
Marketing
Hoy no usamos cookies de marketing; si algún día lo hacemos, será solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.