Respuesta directa
En pocas palabras
Un system prompt debe asumirse observable: no guardes ahí API keys, contraseñas, tokens, datos de clientes ni reglas cuya confidencialidad sea necesaria para la seguridad. Úsalo para orientar tarea, tono y formato, pero aplica identidad, autorización, límites, filtros y aprobación en componentes deterministas fuera del modelo. Ensambla solo el contexto mínimo, separa tenants, protege logs y evaluaciones, y prueba tanto extracción directa como inferencia por comportamiento. Si se expone el texto pero no contiene secretos ni concede autoridad, el incidente es acotado; si revela datos o credenciales, rota, contiene y corrige la arquitectura.
Asume que el system prompt puede observarse
OWASP LLM07:2025 advierte que un system prompt no debe considerarse secreto ni usarse como control de seguridad. Una persona puede pedir que el modelo lo repita, reconstruir fragmentos mediante transformaciones, comparar respuestas o inferir restricciones por prueba y error. El proveedor, las trazas, evaluaciones, capturas de soporte y herramientas internas también pueden ampliar la superficie de exposición.
La meta no es hacer imposible que alguien conozca el texto. La meta es que conocerlo no entregue una credencial, un dato de otra organización, una ruta privilegiada ni una forma de evitar controles externos. Trata el prompt como configuración recuperable y versionada. Si una frase necesita permanecer secreta para que el sistema sea seguro, esa frase está sustituyendo una frontera que debe implementarse fuera del modelo.
Clasifica qué pertenece y qué nunca debe entrar al prompt
Divide el contenido en cuatro clases. La orientación de tarea incluye rol, tono, pasos y formato esperado. El contexto operativo aporta solo hechos necesarios para la solicitud actual. La política de aplicación define decisiones que deben ejecutarse fuera del modelo. Los secretos y datos sensibles permanecen en almacenes y servicios autorizados. Esta clasificación evita mezclar instrucciones útiles con material cuya exposición tendría impacto real.
No insertes claves de API, contraseñas, tokens, connection strings, cookies, claves privadas, credenciales temporales, enlaces firmados ni valores de recuperación. Tampoco uses el prompt como base de datos de clientes, lista de usuarios, mapa de privilegios efectivo, tabla de descuentos secreta o repositorio de contratos. Una referencia opaca puede identificar una política o herramienta; el servicio resuelve y aplica el valor después de autenticar la operación.
| Criterio | Lugar correcto | Patrón peligroso |
|---|---|---|
| Tono y formato | System prompt versionado | Código disperso y no revisado |
| Credenciales | Secret manager y entrega al ejecutor | API key dentro del prompt |
| Permisos | Policy engine y servicio destino | El modelo decide por una frase |
| Datos del cliente | Recuperación autorizada y mínima | Contexto global entre tenants |
Inventa el prompt efectivo, no solo la plantilla base
El prompt efectivo puede combinar mensaje de sistema, plantilla, variables, perfil de organización, historial, memoria, resultados RAG, definiciones de herramientas, errores, ejemplos y mensajes de otros agentes. Documenta cada fuente, owner, clasificación, propósito, tenant, retención, proveedor y canal de observabilidad. Registra qué campos llegan al modelo en cada recorrido y con qué versión.
Revisa el texto después del ensamblaje. Un template limpio puede volverse sensible cuando una variable añade un token, una nota privada o datos de otra cuenta. Usa un constructor tipado que acepte campos permitidos, aplique límites y marque procedencia. Evita interpolación libre de objetos completos. La inspección de desarrollo debe mostrar valores redactados; producción conserva hashes, referencias y metadatos suficientes para reproducir sin copiar secretos.
Entrega secretos al ejecutor, nunca al modelo
Una herramienta puede operar con una credencial sin mostrarla al modelo. El modelo propone una intención estructurada; la aplicación valida identidad, organización, permiso, recurso, argumentos, destino y aprobación. Solo entonces el cliente autorizado obtiene una credencial de corta duración o usa una identidad de workload. El valor viaja directamente al servicio y no regresa en respuestas, errores o trazas del modelo.
Separa secretos por ambiente, organización, herramienta y finalidad. Aplica privilegio mínimo, expiración, rotación, revocación y límites de uso. Evita secretos compartidos entre producción, pruebas y evaluación. Los detectores de patrones ayudan a descubrir accidentes, pero no son la frontera principal: valores opacos, fragmentados o codificados pueden evadirlos. La arquitectura debe impedir que el modelo reciba el secreto desde el inicio.
Mantén permisos y reglas críticas fuera del lenguaje natural
Una instrucción como “solo administradores pueden exportar” no demuestra que la persona sea administradora. El servicio de identidad autentica; el policy enforcement point consulta roles y atributos vigentes; el recurso confirma tenant, estado y alcance. El modelo no crea permisos por mencionar un rol, reproducir una regla ni elegir un nombre de herramienta. Cada acción se reautoriza justo antes del efecto.
Las restricciones comerciales también necesitan código o configuración gobernada cuando el error tiene impacto: monedas, catálogo, descuento permitido, aprobación, destinatario, volumen, horario y separación de funciones. El prompt puede explicar la política al usuario y pedir datos faltantes. La aplicación decide, registra la versión aplicada y falla de forma segura. El texto filtrado puede describir el proceso, pero no debe ofrecer una ruta para omitirlo.
Construye contexto mínimo y separado por tenant
No cargues toda una cuenta, biblioteca o memoria “por si acaso”. Recupera solo campos necesarios para la tarea, después de aplicar identidad, organización, finalidad y permisos. Mantén namespaces, índices, cachés y memorias separados. Conserva procedencia y caducidad. Una referencia recuperada no hereda autoridad ni se transforma en instrucción por estar cerca del system prompt.
Usa vistas reducidas para cada caso: redactar seguimiento necesita menos datos que preparar una propuesta; resumir una oportunidad no requiere credenciales ni registros de otras cuentas. Protege también descripciones de herramientas y ejemplos, que pueden contener identificadores o rutas internas. Si dos fuentes discrepan o falta evidencia, crea un pendiente visible en lugar de completar el contexto con una inferencia.
Versiona plantillas como configuración de producción
Guarda templates en repositorio o registro con revisión, owner, fecha, propósito, checksum y dependencias. No permitas ediciones invisibles desde un panel sin historial. Diferencia base global, variante por mercado y configuración por organización; define qué campos puede modificar cada rol. Una personalización no puede desactivar autorización ni añadir secretos aunque el texto parezca una mejora de calidad.
Prueba cada cambio contra un conjunto estable: tarea esperada, refusals, formato, fuga de datos, extracción, prompt injection, herramientas y casos entre tenants. Despliega por canary, compara calidad y riesgo, y conserva rollback. Un cambio de modelo o proveedor también puede alterar cuánto texto reproduce o infiere; vuelve a evaluar aunque la plantilla no cambie.
Protege logs, trazas, evaluaciones y soporte
La exposición suele ocurrir fuera del chat. SDKs de observabilidad pueden registrar el prompt completo; un error puede copiar contexto; un dataset de evaluación puede conservar datos reales; una captura de soporte puede mostrar instrucciones y nombres internos. Define por campo qué se registra, quién accede, durante cuánto tiempo y en qué región. Redacta antes de enviar a terceros y separa telemetría de contenido.
En producción conserva identificadores de versión, hashes, conteos, latencia, decisiones, herramientas y códigos de resultado. Cuando se necesita contenido para investigar, usa acceso temporal, muestra mínima, propósito documentado y auditoría. Protege exportaciones, backups, búsquedas y restauraciones. Eliminar una conversación sin borrar trazas, feedback y datasets derivados no cierra el ciclo de vida.
Contrata y configura proveedores según el dato real enviado
Documenta endpoint, región, subprocesadores, cifrado, retención, abuso monitoring, entrenamiento, soporte, acceso humano y eliminación. Una opción “no training” no significa necesariamente ausencia de logs. Verifica qué ocurre con prompts, respuestas, archivos, caché, embeddings, feedback y trazas. Limita las claves del proveedor por ambiente y proyecto, y evita que los equipos usen cuentas personales para datos productivos.
Diseña salida: exportación de configuración, cambio de modelo, revocación, eliminación y evidencia. Evalúa incidentes y cambios de términos. La residencia técnica no decide por sí sola la licitud de un tratamiento ni sustituye contratos y análisis aplicables. Para datos personales en México, la organización conserva sus decisiones sobre finalidad, aviso, consentimiento o excepción, encargados, transferencias y derechos.
Prueba extracción directa, transformaciones e inferencia
Incluye intentos directos de repetir instrucciones, traducción, codificación, continuación, completado, resumen, juego de roles, preguntas parciales y comparación de respuestas. Agrega contenido indirecto desde correo, PDF, web, OCR, RAG, memoria y herramientas. Prueba sesiones nuevas, conversaciones largas, idiomas distintos y modelos alternativos. No conviertas el benchmark en una lista pública de cadenas mágicas; registra clases de ataque y resultados reproducibles.
Distingue tres resultados: reproducción literal, revelación de un dato sensible e inferencia razonable sobre el comportamiento. Una persona puede descubrir que el sistema rechaza cierto contenido sin haber obtenido el prompt. La severidad depende del activo y del efecto, no del porcentaje de palabras coincidentes. La prueba final confirma que no se filtraron secretos o datos y que conocer reglas no permite saltar autorización.
Valida respuestas sin depender de una prohibición dentro del prompt
Puedes pedir al modelo que no revele instrucciones, pero esa frase es una preferencia, no una garantía. Aplica validación de salida para secretos conocidos, datos de otros tenants, identificadores restringidos y fragmentos sensibles. Usa comparación con material clasificado, DLP donde corresponda y reglas específicas por audiencia. Rechaza o redacta antes de mostrar, guardar, indexar o enviar.
Evita bloquear por similitud cualquier explicación legítima del producto. El usuario puede necesitar conocer límites, fuentes y revisión humana. Mantén transparencia sobre comportamiento sin publicar credenciales, datos o detalles operativos innecesarios. Evalúa falsos positivos y rutas de fallback. La salida rechazada no debe aparecer completa en logs, alertas, tickets o mensajes de error.
Responde según el activo expuesto y el efecto real
Preserva evidencia mínima: versión, modelo, sesión, identidad, tenant, entrada, salida, herramientas, destino y tiempo. Determina si se expuso solo orientación, una regla interna, un dato personal, una credencial o un recurso. Si existe secreto, revócalo o rótalo y busca uso posterior. Si hay datos, delimita personas, organizaciones, copias y obligaciones. Si la autorización dependía del prompt, pausa el efecto hasta implementar el control externo.
Corrige la causa: elimina contenido sensible, reduce contexto, protege trazas, separa tenants, externaliza policy y vuelve a probar. Cambiar palabras o pedir al modelo que olvide no elimina copias ni invalida credenciales. Revisa caches, evaluaciones, backups y proveedores. Recupera gradualmente y cierra solo después de comprobar estado final, no cuando el bot deja de repetir el fragmento conocido.
Mide exposición, cobertura y tiempo de corrección
Usa denominadores claros: templates inventariados, recorridos evaluados, variables clasificadas, proveedores revisados y versiones activas. Mide prompts con secretos detectados, rutas con logging completo, fallos de aislamiento, hallazgos por clase, cobertura de pruebas, tiempo hasta contención, rotación y retest. Separa reproducción de texto, exposición sensible e impacto autorizado para no inflar ni minimizar el riesgo.
Conserva evidencia de revisión y excepciones con owner y vencimiento. Una tasa cero de extracción no certifica secreto perfecto; puede reflejar muestras pequeñas o técnicas insuficientes. Combina pruebas automáticas con revisión humana y eventos reales. Reabre cuando cambien modelo, template, tool schema, proveedor, política, fuente RAG, logging o audiencia.
Mantén el límite durante todo el ciclo de vida y en Cerravi
NIST define prompt extraction como un ataque para revelar el system prompt u otra información normalmente oculta en el contexto. Usa esa definición para probar, pero diseña el control sobre datos, identidad y efecto. MITRE CWE-201 ayuda a razonar sobre información sensible insertada en datos enviados: la corrección primaria es no incluirla o limpiarla antes de entregar. Ninguna referencia certifica por sí sola la implementación.
En Cerravi, Copilot organiza contexto y propone siguientes pasos para revisión humana. Los recorridos públicos no envían mensajes ni cambian etapas automáticamente. Las propuestas usan productos y precios conocidos; un importe faltante se marca para revisión y no se inventa. Las monedas permanecen separadas salvo conversión aprobada. Buyer Room aporta señales, no confirma identidad, aceptación, firma, pago ni intención. Forecast usa reglas transparentes del CRM y no garantiza cierres. Los permisos, precios y efectos deben seguir fuera del system prompt.
Preguntas frecuentes
Dudas comunes sobre este proceso
¿Un system prompt debe mantenerse secreto?
No debe dependerse de su confidencialidad para proteger el sistema. Puede evitarse su publicación innecesaria, pero debe asumirse observable. Nunca debe contener credenciales, datos sensibles ni reglas cuya exposición permita omitir controles.
¿Dónde se guardan API keys que necesita una herramienta de IA?
En un secret manager o servicio autorizado. La aplicación valida la operación y entrega una credencial mínima y temporal directamente al ejecutor. El modelo recibe el resultado permitido, no el valor secreto.
¿Se pueden poner roles y permisos dentro del prompt?
Puedes describir comportamiento esperado, pero los permisos efectivos deben resolverse con identidad, policy y autorización en el servicio destino. El modelo no debe conceder acceso por el texto del prompt o por un rol mencionado por el usuario.
¿Repetir parte del prompt siempre es una vulnerabilidad crítica?
No. La severidad depende de lo expuesto y del efecto. Reproducir orientación genérica es distinto de revelar un token, datos de otra empresa o una regla que sustituye autorización. Evalúa activo, audiencia, acceso y consecuencias.
¿Cómo se prueba una filtración de system prompt?
Prueba solicitudes directas, transformaciones, idiomas, conversaciones largas e inyección indirecta. Verifica reproducción, datos sensibles, secretos, aislamiento entre tenants y posibilidad de saltar controles. El resultado debe comprobarse en logs y sistemas destino.