Workshop presencial para equipos técnicos
Programar con Claude Code o Copilot sin abrir agujeros de seguridad en vuestro código
Un día de trabajo para que desarrollo, arquitectura y seguridad se pongan de acuerdo en tres cosas: qué puede tocar el asistente, cuándo tiene que preguntar y qué pruebas bloquean un cambio inseguro antes del merge. El último bloque lo hacéis sobre vuestro código.
Presencial en vuestra empresa. Para equipos que ya usan Claude Code o GitHub Copilot. Lo doy en español o en inglés.
Bonificable a través de FUNDAE.
El problema que ya tenéis
La IA ya está dentro de vuestro proceso de desarrollo y los controles se han quedado fuera
El equipo gana velocidad con Claude Code o GitHub Copilot. Con ellos han entrado cosas nuevas en el proceso: ficheros como AGENTS.md o CLAUDE.md 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 empieza en el código que genera. Empieza antes, en todo lo que el asistente lee, instala y puede ejecutar. Un fichero de configuración del IDE puede desactivar las confirmaciones, y un issue público puede acabar siendo una orden para el agente que corre en el pipeline. Y sigue después, cuando un pull request parece correcto porque compila.
En este workshop convertimos eso en decisiones concretas. Salís sabiendo qué revisar antes de habilitar una capacidad, cómo limitarla y qué evidencia pedir antes de aceptar el resultado. Antes de iros, lo probáis sobre vuestro código.
Resultado del workshop
Cinco decisiones que el equipo podrá tomar sin improvisar
Cada una se demuestra durante el día, primero en los laboratorios y luego en vuestro repositorio. Reconocer el concepto en una diapositiva no cuenta.
- 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, descripciones de tools que intentan dirigir al agente y servidores remotos que aceptan tokens que no son suyos.
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, una lista de denegación y un sandbox de ficheros y red donde haya 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, escrita en el fichero de instrucciones del proyecto.
Evidencia: definición reutilizable lista para incorporar al proyecto. - 05
Revisar sin leer cada línea
Concentrar la revisión humana de un pull request generado en aserciones, YAML de CI, lockfiles, instrucciones del proyecto, configuración del asistente y cambios sensibles.
Evidencia: un cambio generado se bloquea con un test visto primero en rojo.
Casos de uso
Situaciones que vuestro equipo va a reconocer
No son riesgos de laboratorio inventados para asustar. Son decisiones que se toman a diario cuando el asistente ya trabaja sobre un repositorio, y casi todas tienen un incidente público detrás. Cada riesgo lleva su referencia en OWASP: LLM para aplicaciones con modelos (2025) y ASI para aplicaciones agénticas (2026).
Context poisoning · LLM01, ASI06
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 · LLM06
Un MCP de solo lectura acaba con acceso a repositorios privados
La configuración enseña un comando y un token. No enseña hasta dónde llega ese token ni lo que hace el servidor con él.
Unexpected code execution · ASI05
El agente edita su propia configuración y deja de preguntar
Una instrucción escondida en el código que el agente lee le pide añadir una línea a la configuración del IDE o a mcp.json. A partir de ahí ejecuta comandos sin confirmación.
Goal hijack · ASI01, ASI02
Un issue público da órdenes al agente del pipeline
Un workflow pasa el título de un issue al prompt de un agente con shell y acceso a los secretos del job. Quien escribe el issue decide qué se ejecuta.
Supply chain · LLM03, ASI04
El asistente inventa una dependencia que existe por casualidad
El nombre suena bien. 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 en verde después de borrar una aserción, saltar un caso o refrescar un snapshot sin autorización.
Sensitive information disclosure · LLM02
Un secreto acaba en el contexto sin aparecer en el diff
Puede entrar al pegar un log, ejecutar env, leer un .env con 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 el contexto, el agente consigue capacidades, actúa en el portátil o en el pipeline y propone un cambio que tiene que pasar los controles.
Cómo funciona de verdad un asistente de desarrollo
El riesgo cambia cuando separas el modelo del 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.
- Dónde cae cada riesgo en el OWASP Top 10 for LLM Applications 2025 y en el Top 10 for Agentic Applications 2026.
Caso real: OWASP clasifica EchoLeak como secuestro de objetivo (ASI01), el incidente de Amazon Q como mal uso de herramientas (ASI02) y el de Replit como agente descontrolado (ASI10).
Contexto envenenado y cadena de instrucciones
El texto que lee el agente puede acabar siendo política.
- AGENTS.md, CLAUDE.md e instrucciones de Copilot como código que ejecuta el modelo.
- Prompt injection indirecto desde repositorios, issues, documentos y resultados de tools.
- Caracteres invisibles, instrucciones escondidas y persistencia entre chats.
- Procedencia de la documentación interna, RAG y bases vectoriales.
Caso real: Rules File Backdoor, Pillar Security, 2025: Unicode invisible en ficheros de reglas de Cursor y Copilot. EchoLeak, CVE-2025-32711: instrucciones ocultas en un correo que Microsoft 365 Copilot procesa sin que el usuario haga clic.
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.
- Autorización de un MCP remoto según la especificación: OAuth 2.1 con PKCE, tokens emitidos para ese servidor (RFC 8707 y RFC 9728) y prohibido reenviar tokens a otros servicios.
- Servidores locales por STDIO: toman las credenciales del entorno de quien los arranca.
- Pinning, revisión de terceros y retirada de capacidades al terminar.
Caso real: GitHub MCP, Invariant Labs, 2025: un issue público lleva al agente a copiar datos de repositorios privados en un PR público. MCPoison, CVE-2025-54136: Cursor ligaba la aprobación al nombre del servidor y no a lo que ejecutaba.
Autonomía, sandbox y secretos
El mismo prompt tiene más o menos riesgo según lo que el agente pueda ejecutar y alcanzar.
- Los cuatro niveles: lectura, preguntar, autoeditar y auto completo.
- Allowlist para lo cotidiano y deny list para operaciones con impacto.
- Sandbox de ficheros y de red para el agente y sus subprocesos; contenedor de desarrollo cuando la herramienta no lo trae.
- La configuración del asistente como superficie de ataque: un cambio en settings.json o mcp.json desactiva las preguntas.
- Credenciales de producción, shell, nube y cambios destructivos.
- Qué se puede pegar, qué se redacta y qué se rota.
Caso real: CVE-2025-53773: una inyección activa la autoaprobación de Copilot en VS Code y acaba en ejecución de código. Nx s1ngularity, 2025: paquetes maliciosos lanzan Claude Code, Gemini CLI y Amazon Q con los permisos desactivados. Replit, 2025: un agente borra la base de datos de producción durante una congelación de código.
Agentes en el pipeline
Un agente en CI hereda los permisos del job y lee texto que puede escribir cualquiera.
- Issues, pull requests y mensajes de commit como entrada no confiable aunque el workflow sea vuestro.
- Quién puede disparar el workflow, qué token recibe y qué tools tiene el agente.
- Caché compartida y publicación: separar el job que lee texto ajeno del que tiene los secretos de release.
- Tokens de CI con el alcance justo: el que construye no publica.
Caso real: PromptPwnd, Aikido, 2025: texto de issues inyectado en agentes de GitHub Actions; Google corrigió Gemini CLI en cuatro días. Cline, febrero de 2026: un título de issue acabó en una versión no autorizada publicada en npm durante unas ocho horas. Amazon Q, CVE-2025-8217: un token con demasiado alcance permitió meter código en una release.
DevSecOps y revisión de código que nadie leerá entero
Cambia quién escribe el código, pero los gates no se negocian.
- Definition of Done persistente en AGENTS.md o en el fichero de proyecto, y no en el chat.
- Unit, golden, smoke y end-to-end: qué demuestra cada capa.
- SAST, secret scanning, dependencias y slopsquatting.
- Qué revisa una persona en un pull request generado: aserciones, skips, CI, lockfile, instrucciones, configuración del asistente y zonas sensibles.
- Disciplina de git cuando varios agentes trabajan sobre el mismo checkout.
Caso real: Spracklen et al., USENIX Security 2025: al menos un 5,2 % de paquetes inventados en modelos comerciales y un 21,7 % en modelos abiertos, con 205.474 nombres distintos que cualquiera puede registrar.
Práctica deliberada
Cinco laboratorios y cinco controles comprobados
Todas las prácticas siguen el mismo patrón: ves el comportamiento inseguro una vez, aplicas el control y demuestras que el resultado cambia. Los laboratorios usan un workspace preparado para romperse sin consecuencias. Después, el mismo patrón se repite sobre vuestro repositorio.
- 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, y no por una corazonada. - 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.
Sobre vuestro código
El último bloque lo trabajáis en vuestro repositorio
Lo que habéis visto romperse en los laboratorios lo buscáis después en un repositorio de vuestro equipo. Cada participante trabaja en su portátil y yo paso por los puestos para resolver dudas y desatascar.
- 01
Qué lee el asistente
Localizar AGENTS.md, CLAUDE.md e instrucciones de Copilot, decidir quién puede modificarlos y buscar caracteres invisibles con el comando que usamos por la mañana.
- 02
Qué tiene conectado
Listar los MCP, Skills y ficheros de configuración del asistente que afectan a ese repositorio, con el alcance real de cada token. Lo que nadie sepa justificar se desactiva ese mismo día.
- 03
Qué puede ejecutar
Configurar ask-first, la deny list y el sandbox en la herramienta que usa cada uno, y comprobar que el agente pregunta antes de leer el entorno o tocar un test.
- 04
Cuándo está terminado
Escribir la Definition of Done en el fichero de instrucciones del proyecto y dejar elegido el primer control que entrará por pull request, con su responsable.
Todo pasa en el portátil de cada participante y sobre su repositorio. El código no sale de la empresa, yo no lo copio ni me lo llevo, y no es una auditoría: no hay informe de hallazgos. Lo que escribáis en ese bloque se queda en vuestro repositorio.
Material que se queda en la empresa
El workshop se acaba y los controles se quedan
El material está hecho para reutilizarlo en el repositorio y en las conversaciones entre arquitectura, seguridad y desarrollo.
- Definition of Done para cambios con IAPlantilla lista para adaptar a AGENTS.md o 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, con su referencia OWASP.
- 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, aprobaciones y sandbox en Copilot, Claude Code y Gemini CLI.
- Lista de revisión para agentes en CIEntradas no confiables, permisos del token, tools del agente, caché y separación del job de publicación.
- 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.
Lo que se suma al curso
Cuatro cosas que se quedan con el equipo, sin coste añadido
Son lo que un equipo acaba pidiendo después del curso.
- +1
Paquete de evidencia de cumplimiento
Lista de asistencia firmada, certificado individual con fecha, horas y contenidos, temario mapeado a las normas que os apliquen y una carta de una página para entregar al auditor.
- +2
Encuesta previa de 10 minutos
Antes del día, el equipo responde una encuesta corta sobre su stack y dónde se atasca. Con ella adapto los laboratorios a lo que usáis de verdad.
- +3
Configuraciones en una rama de vuestro repositorio
Durante el bloque final dejo en una rama las configuraciones que hemos probado: instrucciones y permisos del asistente, reglas de MCP y comprobaciones del pipeline. Incluye una plantilla técnica de política de uso de IA y MCP; es técnica, no asesoramiento jurídico. Os las revisáis y las integráis como cualquier otro cambio.
- +4
Laboratorios con soluciones
El repositorio de laboratorios con sus soluciones y una licencia de uso interno de 12 meses, para que quien se incorpore al equipo no dependa de repetir el día.
Cumplimiento
Qué pide cada norma y qué os entrego como evidencia
El curso no cumple ninguna norma por sí solo. Sirve como evidencia documentada para el control de formación que vuestro auditor ya os pide, si la norma os aplica.
| Norma | Qué pide | Qué os dejo como evidencia |
|---|---|---|
| PCI DSS 4.0 · 6.2.2 | Formación al menos cada 12 meses para quien desarrolla software a medida: diseño seguro, codificación segura y herramientas de testing, documentada. | Temario mapeado a esos puntos, asistencia firmada y fecha. |
| ISO 27001:2022 · A.6.3 | Concienciación, educación y formación en seguridad adecuadas a la función de cada persona. | Certificado individual con fecha, horas y contenidos, y registro por persona. |
| ISO 27001:2022 · A.8.25 y A.8.28 | Ciclo de vida de desarrollo seguro y codificación segura, incluida la formación de quien desarrolla. | Temario mapeado y las comprobaciones de pipeline que quedan en vuestra rama. |
| SOC 2 · CC1.4 y CC2.2 | Programa de formación documentado, con registros de finalización por persona y profundidad según el rol. | Lista con nombre, fecha, contenido y rol. |
| DORA · art. 13(6) | Programas de formación en resiliencia operativa digital para el personal, proporcionados a su función (banca y seguros). | Registro de asistencia y temario del curso. |
| AI Act · art. 4 | Medidas para apoyar la alfabetización en IA del personal, adaptadas a su función. Es una obligación de medios y basta un registro interno. | Registro interno de la formación, con contenido sobre riesgos y uso de IA según la función. |
A quién va dirigido
Para organizaciones que han pasado de probar la IA a depender de ella
Encaja especialmente con
- Responsables de arquitectura de seguridad que necesitan convertir los riesgos de la IA en controles que desarrollo pueda aplicar.
- AppSec, DevSecOps y Platform Engineering, responsables de los gates del pull request, de los pipelines 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 Claude Code o GitHub Copilot y todavía deciden los 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 de vuestro código con informe de vulnerabilidades. En el último bloque trabajáis sobre vuestro repositorio, pero la revisión la hace el propio equipo.
Arquitectura del día
Entre 5 y 8 horas, según el equipo
La agenda alterna explicación, decisión y práctica, y acaba sobre vuestro código. No hay un bloque de teoría interminable seguido de un laboratorio hecho con prisa.
Trazar el sistema que ya usa el equipo
Modelo, orquestador, contexto y tools, con el mapa de riesgos de OWASP. Dibujamos las fronteras de confianza antes de hablar de controles.
Romper la confianza en el contexto
Poisoning, AGENTS.md, 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 y su autorización, identidad, autonomía, sandbox y secretos. Laboratorios 2, 3 y 5.
Bloquear un cambio inseguro antes del merge
Agentes en el pipeline, Definition of Done, revisión de pull requests generados y laboratorio 4.
Vuestro código
Cada participante abre su repositorio y su asistente. Inventario de instrucciones y capacidades, permisos en la herramienta real y Definition of Done en el proyecto. Todos salen con un primer control elegido.
Quién imparte el workshop
Seguridad y desarrollo contados por alguien que ha trabajado en los dos lados
Soy Daniel Alfocea y llevo veinte años en desarrollo y seguridad. En Banco Santander fui Principal Engineer del departamento de IA durante la puesta en marcha del área. En BBVA fui Tech Lead de ciberseguridad. En 42Crunch, en Reino Unido, fui responsable de uno de sus productos de seguridad de APIs.
He presentado investigación en RSA Conference y en OWASP AppSec EU, y he sido ponente habitual de RootedCON. El Instituto Nacional de Ciberseguridad (INCIBE) me ha llamado varias veces como juez de sus concursos. Fundé Navaja Negra y el capítulo de OWASP Madrid. Soy autor de herramientas de seguridad muy usadas, como GoLismero, Plecost y Dockerscan, y de LAPIS, una investigación publicada en arXiv sobre cómo describirle una API a un modelo con menos tokens. Con Alfonso Muñoz escribí MCP Seguro. Guía práctica para desarrolladores, arquitectos software y tech leads.
Este workshop junta dos cosas que casi siempre se enseñan por separado: cómo trabaja el asistente dentro del repositorio y cómo se construyen controles que un equipo de desarrollo pueda cumplir. Y acaba con esos controles aplicados sobre vuestro código.
Garantías
Dos compromisos por escrito y un límite
Si las configuraciones no funcionan, las arreglo
Si las configuraciones que dejo en vuestro repositorio no funcionan, hago una sesión remota gratuita para arreglarlas.
Si os atascáis en 30 días, una hora gratis
Si a los 30 días el equipo se ha atascado aplicando algo del curso, os dedico una hora en remoto sin coste.
Esto no es una auditoría ni una promesa de resultados: no garantizo porcentajes de mejora ni que no haya incidentes.
Formato
Un equipo, una sala y un sistema común para decidir
Incluye la preparación, entre cinco y ocho horas presenciales según el equipo, el bloque de trabajo sobre vuestro repositorio y todo el material. Con grupos pequeños puedo revisar los laboratorios mientras los hacéis y pasar por cada puesto en el último bloque. Con demasiada gente, la práctica se queda en demostración.
- Participantes del mismo equipo o de áreas que trabajan juntas.
- Lo imparto en español o en inglés.
- Sala, pantalla y wifi a cargo de la empresa.
- Cada participante trae su portátil, con su asistente y acceso a un repositorio del equipo.
- Desplazamiento fuera de Madrid acordado antes de cerrar la fecha.
- Incluye el paquete de evidencia, las configuraciones en vuestra rama y los dos compromisos de arriba.
- Si buscáis una auditoría, un certificado de cumplimiento o una charla para escuchar, esto no es. Es un día de trabajo para un equipo que va a aplicar lo aprendido.
Antes de reservar