Workshop presencial para equipos técnicos
Desarrollar con IA sin regalarle las llaves del repositorio
Un día de trabajo para que desarrollo, arquitectura y seguridad compartan el mismo sistema: qué puede tocar el asistente, qué debe preguntar y qué pruebas tienen que bloquear un cambio inseguro antes del merge.
Presencial en vuestra empresa. Para equipos que ya usan Cursor, GitHub Copilot o Claude. El workshop se imparte en español o en inglés.
El problema que ya tenéis
La IA ya está dentro del SDLC. Los controles siguen fuera.
El equipo gana velocidad con Cursor, Copilot o Claude. También ha añadido nuevas entradas al proceso: ficheros de instrucciones que cambian el comportamiento del agente, Skills descargados de terceros, servidores MCP con credenciales y modos que ejecutan comandos sin pedir permiso.
El riesgo no termina en el código que genera. Empieza antes, en todo lo que el asistente lee, instala y puede ejecutar, y continúa después, cuando un pull request parece correcto porque compila.
Este workshop convierte ese problema en decisiones concretas. El equipo sale sabiendo qué revisar antes de habilitar una capacidad, cómo limitarla y qué evidencia exigir antes de aceptar el resultado.
Resultado del workshop
Cinco decisiones que el equipo podrá tomar sin improvisar
Cada resultado se demuestra durante el día. No basta con reconocer el concepto en una diapositiva.
- 01
Distinguir el modelo del orquestador
Saber si el riesgo viene de la respuesta del modelo o de la política que decide qué archivos carga, qué herramientas llama y con qué permisos.
Evidencia: mapa de confianza del asistente que usa el equipo. - 02
Auditar contexto, Skills y MCP
Detectar instrucciones envenenadas, capacidades sobredimensionadas y descripciones de tools que intentan dirigir al agente.
Evidencia: revisión de tres artefactos inseguros y decisión documentada. - 03
Elegir el nivel de autonomía
Separar lectura, edición y ejecución. Aplicar ask-first y una lista de denegación donde hay credenciales o impacto sobre el sistema.
Evidencia: el agente pide permiso ante env, instalaciones y cambios en tests. - 04
Definir cuándo el código está terminado
Traducir el riesgo a una Definition of Done con unit, golden, smoke, end-to-end, SAST, secretos y dependencias.
Evidencia: definición reutilizable lista para incorporar al proyecto. - 05
Revisar sin leer cada línea
Concentrar la revisión humana en aserciones, YAML de CI, lockfiles, instrucciones del proyecto y cambios sensibles.
Evidencia: un cambio generado se bloquea con un test visto primero en rojo.
Casos de uso
Situaciones que vuestro equipo reconocerá
No son riesgos de laboratorio inventados para asustar. Son decisiones habituales cuando el asistente ya trabaja sobre un repositorio.
Context poisoning
Un fichero del repo convence al agente para escribir SQL inseguro
La instrucción parece una convención técnica más. El asistente la trata como autoridad y concatena parámetros en una consulta.
Excessive agency
Un MCP de solo lectura termina con acceso a repositorios privados
La configuración enseña un comando y un token. No enseña el alcance real de ese token ni lo que hace el servidor con él.
Supply chain
El asistente inventa una dependencia que existe por casualidad
El nombre suena correcto. Alguien lo registró después y el agente lo añade al lockfile como si fuera una librería conocida.
Test tampering
Los tests pasan porque el agente ha rebajado lo que comprobaban
El cambio queda verde después de borrar una aserción, saltar un caso o refrescar un snapshot sin autorización.
Sensitive information disclosure
Un secreto acaba en el contexto sin aparecer en el diff
Puede entrar al pegar un log, ejecutar env, leer un .env mediante una tool o guardar datos sensibles en el fichero de proyecto.
Programa completo
Lo que se enseña, bloque por bloque
El orden sigue el camino real de una petición: entra contexto, el agente obtiene capacidades, actúa y propone un cambio que debe superar controles.
Cómo funciona de verdad un asistente de desarrollo
El riesgo cambia cuando se separan modelo y orquestador.
- Modelo, orquestador, tools y resultados de tools.
- Tokens, ventana de contexto y qué se pierde entre sesiones.
- Contexto estático frente a contexto dinámico.
- Fronteras de confianza dentro del IDE y del repositorio.
Caso real: Rules File Backdoor, Pillar Security, 2025.
Contexto envenenado y cadena de instrucciones
El texto que el agente lee puede convertirse en política.
- CLAUDE.md, Cursor rules y Copilot instructions como código ejecutable por el modelo.
- Prompt injection indirecto desde repositorios, issues y resultados de tools.
- Caracteres invisibles, instrucciones escondidas y persistencia entre chats.
- Provenance para documentación interna, RAG y bases vectoriales.
Caso real: EchoLeak, CVE-2025-32711, y el salto de una entrada externa a una acción del agente.
Skills y MCP sin ampliar el perímetro a ciegas
Instalar una habilidad y conectar un servicio son dos decisiones distintas.
- Cuándo usar un Skill, cuándo usar MCP y cuándo basta un CLI.
- Tool poisoning dentro de nombres y descripciones.
- Scopes, tokens, identidad humana frente a identidad del agente.
- Pinning, revisión de terceros y retirada de capacidades al terminar.
Caso real: GitHub MCP private-repo leak, Invariant Labs, 2025.
Autonomía, permisos y secretos
El mismo prompt cambia de riesgo según lo que el agente pueda ejecutar.
- Los cuatro niveles: lectura, preguntar, autoeditar y auto completo.
- Allowlist para lo cotidiano y deny list para operaciones con impacto.
- Credenciales de producción, shell, nube y cambios destructivos.
- Qué se puede pegar, qué se redacta y qué se rota.
Caso real: Replit contra producción y Nx s1ngularity ejecutando CLIs locales en modo yolo, 2025.
DevSecOps para código que nadie leerá entero
La autoría cambia. Los gates no se negocian.
- Definition of Done persistente en el fichero de proyecto.
- Unit, golden, smoke y end-to-end: qué demuestra cada capa.
- SAST, secret scanning, dependencias y slopsquatting.
- Qué revisa una persona: aserciones, CI, lockfile, instrucciones y zonas sensibles.
Caso real: Un pipeline de Azure DevOps que bloquea el merge cuando falta la evidencia.
Práctica deliberada
Cinco laboratorios. Cinco controles comprobados.
Cada práctica sigue el mismo patrón: observar el comportamiento inseguro una vez, aplicar el control y demostrar que el resultado cambia.
- 01
El proyecto que da malas instrucciones
El equipo carga un fichero envenenado, pide una búsqueda de productos y localiza por qué el agente propone SQL vulnerable.
Resultado: instrucciones revisadas, caracteres ocultos detectados y contexto limpio en una sesión nueva. - 02
El Skill que nunca debería instalarse
Cada participante revisa un Skill que exige volcar el entorno y saltarse la confirmación humana.
Resultado: decisión de rechazo justificada por una línea concreta, no por una impresión. - 03
Dos MCP que parecen iguales en la configuración
El equipo compara el servidor acotado con otro capaz de leer cualquier fichero del equipo.
Resultado: solo se habilita la allowlist y la petición de un secreto queda bloqueada. - 04
El código generado frente al arnés
La IA implementa una función bajo una Definition of Done. Después se rompe a propósito para demostrar que el test de inyección falla.
Resultado: evidencia red first y condiciones claras para aceptar o rechazar el pull request. - 05
El dial de autonomía bajo presión
El prompt intenta empujar al asistente a ejecutar env, instalar paquetes y tocar tests sin preguntar.
Resultado: modo ask-first y deny list comprobados en la herramienta real de cada participante.
Material que se queda en la empresa
El workshop termina. Los controles se quedan.
El material está diseñado para reutilizarse en el repositorio y en las conversaciones entre arquitectura, seguridad y desarrollo.
- Definition of Done para cambios con IAPlantilla lista para adaptar al fichero de instrucciones del proyecto.
- Workspace con cinco laboratoriosEnunciados, fixtures seguros e inseguros y tests para repetirlos.
- Tarjeta de control de una páginaContexto, Skills, MCP, autonomía, secretos, código y supply chain.
- Deny list inicialOperaciones de git, shell, cloud y secretos que requieren una persona.
- Guía de higiene de contextoQué redactar antes de pegar y qué hacer cuando un secreto ya se compartió.
- Matriz de autonomíaEquivalencia de modos en Cursor, Copilot, Claude Code y Gemini CLI.
- Disciplina de git multiagenteRutas explícitas, estado antes de commit y propiedad de cada fichero.
- Pipeline de referenciaEjemplo para Azure DevOps con pytest real y los siguientes gates identificados.
A quién va dirigido
Para organizaciones que ya han pasado de probar la IA a depender de ella
Encaja especialmente con
- Responsables de arquitectura de seguridad que necesitan convertir riesgos de IA en controles aplicables por desarrollo.
- AppSec, DevSecOps y Platform Engineering responsables de los gates del pull request y de las conexiones con herramientas.
- Engineering managers y tech leads que ya ven código generado en repositorios de producción.
- Security champions y desarrolladores senior que van a extender estas prácticas al resto del equipo.
- Equipos que usan Cursor, GitHub Copilot o Claude y todavía deciden permisos caso por caso.
No es la formación adecuada si
- El equipo aún no ha usado un asistente sobre un repositorio real.
- Buscáis una introducción a qué es un LLM o cómo escribir prompts.
- Necesitáis una política corporativa, gobierno de modelos o una formación para dirección.
- Esperáis una auditoría o una adaptación en directo sobre vuestro código.
Arquitectura del día
Seis horas para recorrer el riesgo de extremo a extremo
La agenda alterna explicación, decisión y práctica. No hay un bloque de teoría de cuatro horas seguido por un laboratorio apresurado.
Trazar el sistema que ya usa el equipo
Modelo, orquestador, contexto y tools. Se dibujan las fronteras de confianza antes de hablar de controles.
Romper la confianza en el contexto
Poisoning, instrucciones persistentes y laboratorio 1. El equipo comprueba cómo una regla del repositorio cambia el código.
Decidir qué se conecta y con qué permisos
Skills, MCP, identidad, scopes, autonomía y secretos. Laboratorios 2, 3 y 5.
Definir qué significa terminado
Unit, golden, smoke, end-to-end, SAST, secretos y dependencias. La Definition of Done deja de vivir en el chat.
Bloquear un cambio inseguro antes del merge
Laboratorio 4, revisión humana de alto valor y pipeline. El cierre fija un control concreto que cada participante aplicará en su proyecto.
Quién imparte el workshop
Seguridad y desarrollo explicados por alguien que ha trabajado en los dos lados
Soy Daniel Alfocea. Llevo veinte años trabajando en desarrollo y seguridad dentro de bancos y grandes empresas. En Banco Santander fui responsable técnico del equipo de IA durante la puesta en marcha del área.
Fundé Navaja Negra y el chapter de OWASP Madrid. He presentado investigación en RootedCON, RSA y Codemotion, y he publicado más de cien herramientas de código abierto. Con Alfonso Muñoz escribí MCP Seguro, una guía práctica sobre autenticación, permisos y amenazas en Model Context Protocol.
Este workshop une las dos partes que suelen enseñarse por separado: cómo trabaja el asistente dentro del repositorio y cómo se construyen controles que un equipo de desarrollo puede cumplir.
Formato e inversión
Un equipo, una sala y un sistema común para decidir
El precio cubre la preparación, seis horas presenciales y todo el material de trabajo. El límite de doce personas permite revisar los laboratorios mientras ocurren; con más asistentes, la práctica se convierte en demostración.
- Hasta 12 participantes del mismo equipo o de áreas que trabajan juntas.
- Impartición en español o en inglés.
- Sala, pantalla, wifi y portátiles a cargo de la empresa.
- Desplazamiento fuera de Madrid acordado antes de cerrar la fecha.
Antes de reservar