Claude Code se convirtió en un término de búsqueda mucho más popular en el momento en que la frase filtración del código fuente comenzó a difundirse. Esa reacción tiene sentido. Cuando un agente de codificación de IA filtra sus componentes internos, la gente inmediatamente quiere saber qué se expuso, si el producto sigue siendo seguro de usar y qué revela la filtración sobre cómo funcionan realmente los sistemas de agentes modernos.
La respuesta útil no es publicar el system prompt exacto de otra persona ni convertir el código filtrado en una guía para replicarlo paso a paso. La respuesta útil es comprender la arquitectura de seguridad equivalente detrás de una herramienta como Claude Code: cómo una solicitud se convierte en contexto, cómo el bucle de herramientas se repara a sí mismo, cómo se aplican los permisos, cómo se comprime la memoria y por qué la inyección de prompts es mucho más importante que los rumores sobre un único archivo filtrado.
Los propios escritos recientes de Anthropic hacen que ese encuadre sea aún más relevante. En su artículo de marzo de 2026 sobre el modo automático de Claude Code, Anthropic dice que los usuarios aprueban el 93 % de las solicitudes de permisos y explica que el modo automático añade una sonda de inyección de prompts del lado del servidor para las salidas de las herramientas, además de un clasificador de acciones antes de la ejecución. En su investigación sobre agentes de navegador, Anthropic también afirma que la inyección de prompts sigue siendo uno de los problemas no resueltos más difíciles para los sistemas de IA que realizan acciones. En conjunto, esos dos puntos dicen más sobre el futuro de los agentes de codificación de IA que cualquier fragmento de prompt filtrado.
TL;DR
- La filtración del código fuente de Claude Code es importante porque expone decisiones de implementación, no porque ofrezca una receta fiable para recrear el producto.
- La forma más segura de hablar de Claude Code es a nivel de arquitectura: ensamblaje de prompts, bucles de herramientas, memoria, permisos y superficies de extensión.
- Un agente de codificación suele funcionar combinando una capa de instrucciones base, la solicitud del usuario, orientación específica del repositorio, esquemas de herramientas y contexto recuperado en un único estado de prompt de trabajo.
- La verdadera historia de seguridad es la inyección de prompts y herramientas, no solo el secreto del prompt.
- El mínimo privilegio, la redacción, el filtrado de salidas, el sandboxing y los registros de auditoría son más importantes que intentar ocultar cada cadena interna para siempre.
- Los flujos de trabajo multiagente, los comandos de barra, la memoria, MCP, LSP, los plugins y las habilidades aumentan la utilidad, pero cada uno añade otra superficie que debe ser delimitada y observada cuidadosamente.
Por qué es importante la filtración del código fuente de Claude Code y qué no demuestra
Una filtración del código fuente de Claude Code puede enseñarte algo real sobre la categoría del producto. Puede demostrar que los agentes de codificación no son magia. Son sistemas en capas con instrucciones, herramientas, políticas, gestión de contexto, atajos de interfaz de usuario y lógica de recuperación. Esa parte es útil.
Lo que no demuestra es que cualquiera que vea los componentes internos filtrados pueda reproducir de repente el producto completo. El comportamiento real de un agente depende de la pila que lo rodea: comportamiento del modelo, envolturas de seguridad, comprobaciones de permisos, contratos de herramientas, sondas del lado del servidor, aplicación del lado del cliente, gestión de estado y ajuste operativo. Un fragmento de código fuente filtrado es una instantánea. Un agente en producción es un sistema vivo.
Esa distinción es importante porque gran parte del debate en torno a una filtración de código fuente pierde seriedad rápidamente. La gente se obsesiona con el detalle más llamativo, normalmente la redacción de un prompt o el nombre de un comando interno, y pasa por alto la verdad más difícil: los agentes de IA modernos están moldeados menos por un único prompt maestro que por todo un bucle de control.
Si estás evaluando Claude Code después de la filtración, la pregunta correcta no es "¿Puedo ver el prompt oculto?". Es "¿Qué límites de seguridad se mantienen incluso si algunos componentes internos se hacen públicos?". Esa es la pregunta que los compradores serios, los líderes de ingeniería y los equipos de seguridad deberían hacerse.
Una visión de seguridad equivalente del flujo de ensamblaje del system prompt de Claude Code
A un alto nivel, una herramienta como Claude Code probablemente sigue el mismo patrón que la mayoría de los agentes de codificación serios utilizan actualmente.
Primero, hay una capa de instrucciones base. Este es el marco de rol y política persistente que le dice al modelo qué tipo de asistente es, qué reglas de seguridad son importantes y cómo comportarse con las herramientas, la intención del usuario y las acciones sensibles.
Segundo, hay una capa de tarea. Eso incluye la solicitud del usuario, el directorio de trabajo actual o el contexto del repositorio, y cualquier archivo de instrucciones local que explique las normas del proyecto. La documentación de Claude Code sobre CLAUDE.md y la memoria deja claro que la orientación a nivel de repositorio y las instrucciones persistentes son parte del entorno de trabajo, aunque no sean lo mismo que una aplicación estricta.
Tercero, hay una capa de capacidad. Aquí es donde los esquemas de herramientas, el estado de los permisos, las superficies de extensión y los comandos específicos del agente se vinculan a la sesión. Al modelo no solo se le pide que responda. Se le dice qué herramientas existen, para qué sirve cada una y qué restricciones se aplican.
Cuarto, hay una capa de contexto recuperado. Eso puede incluir archivos relevantes, resultados de pruebas, resultados de la shell, resúmenes anteriores, entradas de memoria o contenido obtenido de sistemas externos. Esta capa cambia continuamente durante la sesión.
El punto práctico es simple: el system prompt no es un único párrafo sagrado. Se entiende mejor como una canalización de ensamblaje dinámico. Eso es importante para la seguridad porque los defensores deben centrarse en qué entra en esa canalización, cómo se etiqueta y qué capas se aplican fuera del modelo.
Cómo se autorrepara el bucle de llamada a herramientas
Una de las cosas más reveladoras de un agente de codificación no es que pueda llamar a herramientas. Es que a menudo puede recuperarse cuando una llamada a una herramienta sale mal.
Un bucle normal se parece a algo así:
1. El usuario solicita un cambio.
2. El agente decide que necesita pruebas, por lo que lee archivos, busca o ejecuta un comando.
3. La herramienta devuelve un resultado.
4. El agente interpreta ese resultado, actualiza su plan y responde o intenta otra llamada a una herramienta.
La parte interesante es el comportamiento de reintento. Si un comando falla, la ruta de un archivo es incorrecta o el resultado de una prueba contradice el plan inicial, el agente puede acotar el alcance, cambiar el comando, abrir otro archivo o pedir aprobación antes de escalar. Eso es lo que hace que estos sistemas se sientan menos como un autocompletado y más como operadores.
Pero el mismo bucle es también donde la inyección de herramientas se vuelve peligrosa. El agente no solo lee archivos de confianza. Puede leer registros, salidas de la shell, comentarios, texto de incidencias, código generado o contenido extraído a través de integraciones. La guía de inyección de prompts de OWASP advierte explícitamente que los ataques indirectos pueden esconderse en comentarios de código, documentación, solicitudes de fusión, correos electrónicos y páginas web obtenidas. Una vez que entiendes el bucle, entiendes el riesgo: los resultados no confiables pueden intentar convertirse en nuevas instrucciones.
Por eso es notable el diseño del modo automático de Anthropic. Anthropic dice que utiliza dos capas de defensa: una para lo que Claude lee y otra para lo que Claude hace. En el lado de la entrada, una sonda del lado del servidor escanea los resultados de las herramientas, como lecturas de archivos, salidas de la shell, recuperaciones web y respuestas de herramientas externas antes de que entren en el contexto del agente. En el lado de la acción, un clasificador evalúa la acción propuesta antes de la ejecución. Ese es exactamente el tipo de arquitectura que se desea en un agente de codificación con privilegios elevados.
El pipeline de consultas: de la intención del usuario al contexto procesable
Si quieres un modelo mental más claro para Claude Code, piensa en él como un pipeline de consultas en lugar de un chatbot.
Un agente robusto generalmente tiene que hacer cinco trabajos en secuencia.
- Interpretar la intención: ¿qué está pidiendo realmente el usuario?
- Recopilar contexto: ¿qué archivos, comandos, documentos, memorias o herramientas son relevantes?
- Planificar la ejecución: ¿cuál es el siguiente paso de menor riesgo?
- Validar los resultados: ¿el resultado de la herramienta respaldó el plan o expuso un error o un ataque?
- Comprimir el estado: ¿qué se debe recordar, resumir o descartar para que la sesión siga siendo útil?
Este pipeline es importante porque explica por qué el texto exacto del prompt es menos importante de lo que piensan los operadores. Los pequeños cambios en la redacción importan, pero el mayor determinante de la calidad es si el pipeline aporta consistentemente las pruebas correctas y rechaza las incorrectas.
Ahí es también donde la compresión de contexto entra en la historia. Los repositorios grandes generan demasiado estado como para mantener cada token sin procesar en el contexto para siempre. Por lo tanto, los buenos agentes resumen, compactan y recargan selectivamente. Los documentos de memoria de Claude Code describen tanto CLAUDE.md como la memoria automática como mecanismos para gestionar la orientación duradera y el contexto recuperado. En la práctica, eso significa que el modelo a menudo trabaja con una mezcla de pruebas sin procesar y resúmenes. Útil para la usabilidad; arriesgado si la memoria está envenenada.
Compresión de contexto, memoria y el riesgo de envenenamiento de la memoria
La memoria es una de las partes más prácticas y más incomprendidas del diseño de agentes.
Sin memoria, un agente olvida preferencias útiles, decisiones previas y restricciones recurrentes del repositorio. Con memoria, se vuelve más rápido, más personalizado y más molesto de atacar porque puede mantener reglas operativas estables. Pero la memoria también puede convertirse en una capa de persistencia para datos maliciosos.
La guía de seguridad de agentes de IA de OWASP menciona directamente el envenenamiento de la memoria: el contenido malicioso puede almacenarse en la memoria del agente e influir en futuras sesiones. Esa advertencia es importante para cualquier discusión sobre la filtración del código fuente de Claude Code porque una vez que aceptas que los prompts se ensamblan dinámicamente, te das cuenta de que el contexto almacenado es parte de la superficie del prompt.
Una buena higiene de la memoria parece aburrida, y es exactamente por eso que funciona:
- mantener la memoria acotada por usuario, repositorio o sesión
- almacenar resúmenes cortos en lugar de transcripciones sin procesar cuando sea posible
- evitar persistir secretos, tokens o volcados de herramientas sin procesar
- permitir que los operadores inspeccionen y editen la memoria
- hacer que la memoria que podría estar obsoleta o controlada por un atacante caduque o se revalide
Por eso también es importante la redacción. Si los registros, prompts, diffs o resultados de comandos se copian en la memoria sin filtrarlos, el radio de la filtración crece. Una filtración de código fuente es mala. Una filtración de código fuente más la retención duradera de secretos es mucho peor.
Permisos, modo automático y por qué el mínimo privilegio supera al secreto del prompt
La filtración del código fuente de Claude Code llevó a mucha gente a una conclusión simplista: mantén el prompt en secreto y el producto estará seguro. Eso no es suficiente.
Una defensa más duradera es el mínimo privilegio. La hoja de referencia de seguridad de agentes de IA de OWASP dice que los agentes deben obtener las herramientas mínimas requeridas para la tarea, con operaciones acotadas y aprobación explícita para acciones sensibles. La documentación de Anthropic hace una distinción similar entre la orientación conductual y la aplicación técnica: la configuración puede bloquear herramientas, comandos, rutas o límites del sandbox incluso si el propio modelo hubiera elegido mal.
Esta es la forma correcta de pensar sobre los permisos en Claude Code.
Un agente seguro debería separar:
- lo que el modelo tiene *permiso para leer*
- lo que el modelo tiene *permiso para proponer*
- lo que el tiempo de ejecución tiene *permiso para ejecutar*
- lo que todavía requiere *aprobación humana*
Esa separación es aún más importante en el modo automático. El informe de Anthropic de marzo de 2026 dice que la aprobación manual funciona, pero también crea fatiga de aprobación porque los usuarios aprueban la mayoría de las instrucciones de todos modos. Así que Anthropic añadió una capa de decisión automatizada en lugar de dejar por defecto a los usuarios una ejecución totalmente sin restricciones. Esa es la medida madura: reducir la fricción, pero mantener un clasificador y una sonda entre el modelo y el radio de explosión.
En otras palabras, la mejor respuesta a una filtración de código fuente no es el pánico. Es tener mejores límites.
Comandos de barra, flujos de trabajo multiagente y superficies de extensión
Claude Code no es solo un envoltorio de shell de un único modelo. La experiencia del operador que lo rodea es importante.
Los comandos de barra (slash commands) ofrecen a los usuarios puntos de entrada cortos y reutilizables a los flujos de trabajo. Reducen la sobrecarga de escribir instrucciones y hacen que las operaciones comunes sean más consistentes. Eso es bueno para la productividad, pero también significa que los comandos pueden convertirse en atajos de ejecución privilegiados. Trátelos como interfaces adyacentes al código, no como macros inofensivas.
Los flujos de trabajo multiagente son importantes por una razón diferente. Cuando se divide el trabajo en roles de planificador, investigador, revisor o solucionador, se reduce la carga cognitiva y a veces se mejora la calidad. Pero también se crea más paso de mensajes, más resúmenes y más oportunidades para que un resultado intermedio envenenado se mueva entre agentes. OWASP advierte explícitamente sobre los fallos en cascada en los sistemas multiagente precisamente por esta razón.
Luego están los subsistemas de capacidades.
- MCP son las siglas de Model Context Protocol, un estándar abierto para conectar modelos a herramientas y fuentes de datos.
- LSP suele significar inteligencia de código al estilo de un servidor de lenguaje dentro de los flujos de un IDE.
- Los plugins y las habilidades (skills) empaquetan capacidades y flujos de trabajo reutilizables.
Estos son útiles porque mantienen el agente principal más pequeño y permiten a los operadores añadir poderes específicos. Son arriesgados porque cada extensión es otro límite de confianza. Un plugin puede excederse. Un servidor MCP puede exponer más de lo previsto. Una habilidad puede ampliar silenciosamente el acceso a las herramientas. Una integración de lenguaje puede hacer aflorar inteligencia de código sensible en lugares que no esperaba.
La regla de diseño segura es aburrida pero eficaz: cada extensión debe declarar qué puede leer, qué puede escribir, a qué red puede acceder y qué se registra.
Cómo identificar la inyección de instrucciones y la inyección de herramientas en la práctica
Si está leyendo sobre la filtración del código fuente de Claude Code porque ejecuta agentes de codificación en producción, este es el problema más urgente que debe resolver: ¿cómo se detecta un ataque antes de que se convierta en una acción?
Esté atento a patrones como estos:
- contenido externo que le dice al agente que ignore las instrucciones previas
- registros, texto de incidencias, documentos o comentarios que solicitan secretos, instrucciones del sistema o reglas ocultas
- salidas de herramientas que cambian repentinamente el alcance de la tarea de la solicitud del usuario al objetivo del atacante
- solicitudes para escalar permisos, habilitar el acceso a la red o exportar archivos sin una razón del usuario
- intentos de pasar de un análisis de solo lectura a un comportamiento de escritura, eliminación, envío o ejecución
- instrucciones ocultas u ofuscadas incrustadas en markdown, HTML, cadenas codificadas o capturas de pantalla
La hoja de trucos sobre inyección de instrucciones de OWASP es especialmente útil aquí porque no trata la inyección de instrucciones como una novedad. La trata como un problema de ingeniería: separar las instrucciones de los datos, sanear las entradas, filtrar las salidas y mantener la revisión humana para las operaciones de alto riesgo.
Esa es la mentalidad correcta para Claude Code después de una filtración de código fuente. Asuma que los atacantes saben más que antes. Luego, diseñe de tal manera que saber más no les permita hacer mucho.
Guía defensiva para equipos que utilizan Claude Code o agentes similares
Si su organización utiliza Claude Code, OpenClaw, Cursor, Copilot o cualquier otro flujo de trabajo de codificación agéntico, estos controles le ofrecen la mayor ventaja:
- Mínimo privilegio: dé al agente solo las herramientas y rutas que necesita para la tarea actual.
- Redacción: elimine secretos, tokens, URL internas y datos de clientes de los registros y la memoria antes de la persistencia.
- Filtrado de salida: inspeccione las respuestas y los argumentos de las llamadas a herramientas en busca de fugas de secretos o patrones de exfiltración sospechosos.
- Sandboxing: aísle la ejecución, el alcance de la red y el ámbito del sistema de archivos siempre que sea posible.
- Manejo de secretos: inyecte credenciales de corta duración por tarea en lugar de heredar todo el entorno del host.
- Registro de auditoría: registre las llamadas a herramientas, las aprobaciones, las coincidencias de políticas y las solicitudes salientes con la fidelidad suficiente para reconstruir incidentes.
- Puertas humanas: requiera revisión para acciones destructivas, comunicaciones externas, instalaciones de paquetes y escrituras de amplio alcance.
- Revisión de extensiones: trate los servidores MCP, los plugins y las habilidades como dependencias de la cadena de suministro.
Una buena lista de verificación de incidentes es igualmente concreta:
- pausar la ejecución autónoma
- rotar las credenciales expuestas y revocar los tokens obsoletos
- revisar las salidas de herramientas recientes y los registros de acciones en busca de instrucciones inyectadas
- limpiar o inspeccionar las entradas de memoria persistente que puedan haber sido envenenadas
- restringir los permisos y las reglas del sandbox antes de volver a habilitar la automatización
- preservar los artefactos para el análisis de la causa raíz y la presentación de informes al proveedor
Veredicto final
La lección más útil de la filtración del código fuente de Claude Code no es la emoción de ver sus componentes internos. Es el recordatorio de que los agentes de codificación modernos son en realidad sistemas de orquestación: prompts en capas, contexto recuperado, esquemas de herramientas, permisos, memoria y límites de aprobación que trabajan juntos bajo presión.
Por eso, una explicación segura es más valiosa que un prompt copiado. Si entiendes la arquitectura a un alto nivel, puedes evaluar cualquier agente de codificación de forma más inteligente. Puedes preguntar si se analizan las salidas de sus herramientas, si su memoria está aislada, si sus permisos están delimitados, si se revisan sus extensiones y si sus registros respaldan la respuesta a incidentes.
Y si estás pensando en el uso empresarial, esa misma lección se traslada limpiamente: los sistemas de IA ganadores no serán los que tengan los prompts más misteriosos. Serán los que tengan los límites más claros. Herramientas como OpenClaw vs Claude Code y guías para el uso de Claude Code en ordenadores son útiles porque te ayudan a comparar esas opciones de límites en lugar de perseguir el drama de las filtraciones.
Tu recepcionista IA, en vivo en minutos.
Escala tu recepción con una IA que nunca duerme. Solvea atiende consultas ilimitadas en múltiples canales, agenda citas automáticamente en tu calendario y evita oportunidades perdidas las 24 horas.
Preguntas frecuentes
¿Significa la filtración del código fuente de Claude Code que el producto no es seguro?
No por sí sola. Una filtración del código fuente plantea preocupaciones reales sobre la exposición de la arquitectura y la información que obtienen los atacantes, pero las protecciones en tiempo de ejecución siguen siendo más importantes. Si los permisos, el sandboxing, el filtrado de salidas y la aprobación humana permanecen intactos, una filtración es grave pero aún contenible.
¿Cuál es el mayor riesgo de seguridad después de una filtración del código fuente de Claude Code?
Normalmente no es la copia de prompts. El mayor riesgo es que los atacantes utilicen los nuevos conocimientos para elaborar mejores intentos de inyección de prompts, inyección de herramientas, abuso de extensiones o escalada de privilegios. Por eso, los equipos deben reforzar primero los ámbitos de las herramientas, los registros y las rutas de aprobación.
¿Cómo deberían responder los equipos si utilizan Claude Code o agentes similares hoy en día?
Trata el evento como un desencadenante para una revisión del diseño. Vuelve a comprobar los secretos, la retención de memoria, los permisos de MCP o de plugins, la configuración del sandbox y los registros de auditoría. Si puedes explicar exactamente lo que tu agente puede leer, escribir, llamar y persistir, estarás en una posición mucho mejor.
