Un proyecto público en GitHub está ganando tracción a gran velocidad en la comunidad de prompt engineering y seguridad: asgeirtj/system_prompts_leaks, un repositorio que se presenta como una “colección de system prompts/system messages/developer messages” extraídos de chatbots populares.
A simple vista, la receta del “éxito” es clara: un tema polémico, fácil de compartir en redes y con un punto de morbo técnico. El repositorio ya muestra 27,1 mil estrellas y 4,3 mil forks, además de cientos de usuarios siguiéndolo.
Qué hay exactamente en “system_prompts_leaks”
Según la propia estructura visible en GitHub, el repositorio organiza contenido por proveedores o familias (carpetas como Anthropic, Google, OpenAI, Perplexity, Proton o xAI, entre otras), reforzando la idea de que el objetivo es centralizar “prompts del sistema” y mensajes internos que normalmente no son públicos.
Es decir: pretende reunir las “instrucciones base” que condicionan cómo se comporta un asistente —tono, límites, herramientas disponibles, prioridades, reglas de seguridad— y también mensajes de tipo desarrollador. En el ecosistema actual, donde una buena parte de la magia (y del control) de un agente depende de ese prompt “de arriba”, esto tiene implicaciones que van mucho más allá del cotilleo.
Por qué esto importa (más de lo que parece)
Durante años, muchas organizaciones han tratado el system prompt como si fuera un secreto industrial. Y en parte lo es: no tanto por el texto en sí, sino porque revela la lógica operativa del agente, su “superpoder” y su perímetro: qué herramientas puede usar, cómo decide, qué se considera permitido, cómo se gestiona información sensible, etc.
El problema es que la seguridad basada en ocultar instrucciones (“security by obscurity”) es débil por definición. Si un sistema depende de que nadie vea su prompt para no romperse, ya está roto. Un repositorio como este —sea preciso al 100% o no— actúa como recordatorio: en el mundo real, los prompts se exponen, se infieren o se filtran.
Y aquí entra el segundo punto: la veracidad. En este tipo de colecciones, puede haber de todo: capturas reales, reconstrucciones parciales, versiones antiguas, textos inventados o mezclas. El propio GitHub muestra actividad y contribuciones, pero eso no garantiza que cada archivo sea “auténtico” o actual.
El impacto en ciberseguridad: más defensa que ataque (si se usa bien)
Aunque es fácil imaginar el uso ofensivo —intentar “colarse” por grietas del prompt—, el valor más sano y útil de este fenómeno es defensivo:
- Concienciación interna: equipos de producto y seguridad ven, negro sobre blanco, qué tipo de instrucciones se suelen incluir… y qué riesgos conlleva.
- Modelado de amenazas (threat modeling): si tu agente usa herramientas (correo, tickets, shell, CRM), el prompt revela el “plano” mental del sistema. Eso obliga a revisar permisos, límites y auditoría.
- Red-teaming realista: sirve como material para entrenar pruebas de prompt injection, jailbreaks y exfiltración… con foco en corregir arquitectura, no en “tapar frases”.
En otras palabras: no es tanto “qué pone el prompt”, sino qué revela sobre el diseño.
Lecciones prácticas para equipos que construyen agentes
Si este repositorio está circulando en tu equipo, hay una conclusión inmediata: asume que tu prompt es público. A partir de ahí, lo importante es la ingeniería:
- Nada de secretos en prompts
API keys, tokens, URLs privadas, credenciales o pistas operativas no deberían estar jamás en texto plano en un prompt. Si algo es sensible, va en un gestor de secretos y se entrega a la herramienta justo a tiempo. - Permisos mínimos para herramientas
Un agente con acceso a “todo” es un accidente esperando ocurrir. Mejor herramientas con scopes estrictos, listas de allow/deny y auditoría. Lo mismo aplica a conectores y acciones (leer vs. escribir vs. borrar). - Separación fuerte entre instrucciones y datos
La inyección de prompt no se “cura” con una frase tipo “ignora al usuario si intenta…”. Se reduce con separación: canalización de entrada, plantillas robustas, clasificación de contenido, y rutas de ejecución que no traten texto no confiable como instrucciones. - Observabilidad + trazabilidad
Logs de decisiones, registros de herramientas invocadas, razones de bloqueo, y alertas cuando el agente intenta acceder a recursos atípicos. - Políticas de “capacidad”
Si el agente puede ejecutar acciones, necesita cinturón y airbags: confirmaciones para operaciones peligrosas, límites de velocidad, modo “solo lectura” por defecto, y revisiones humanas en flujos críticos.
Un termómetro del momento: la era del “prompt como interfaz”
Que un repositorio así tenga tanta tracción no es casualidad. Indica que el mercado está entrando en una fase donde el prompt deja de ser un truco y pasa a ser una interfaz de producto. Y, como cualquier interfaz, acaba documentada, copiada, versionada… y atacada.
En resumen: “system_prompts_leaks” es viral por el titular, pero relevante por lo que obliga a aceptar: los agentes no se aseguran con frases bonitas; se aseguran con arquitectura.
