¿Es seguro poner una clave de API en el prompt de sistema de un LLM si le ordenas al modelo que nunca la revele?

Es tentador tratar el prompt de sistema como configuración del servidor: invisible para los usuarios, por tanto seguro. Esta pregunta comprueba si entiendes que un LLM no es una frontera de confianza.

Qué dice OWASP

OWASP LLM07:2025 (System Prompt Leakage) afirma que el prompt de sistema no debe considerarse un secreto ni usarse como control de seguridad. El material sensible, como credenciales y cadenas de conexión, nunca debe incrustarse en él. Las mitigaciones: separar los datos sensibles (claves de API, nombres de bases de datos, estructuras de roles) del prompt, evitar depender de los prompts de sistema para controlar el comportamiento del modelo cuando sea posible, añadir barreras independientes fuera del LLM y aplicar la separación de privilegios y las comprobaciones de autorización de forma determinista fuera del modelo.

Por qué «nunca reveles esto» no funciona

El comportamiento del modelo se moldea con texto, y los atacantes también aportan texto. La inyección de prompt puede llevar al modelo a divulgar o ignorar sus instrucciones, así que una prohibición en lenguaje natural es una petición, no un control de acceso. OWASP también señala que la divulgación del prompt no es el riesgo principal: los fallos son los secretos expuestos, las barreras eludidas y la lógica de autorización delegada al LLM.

Por qué fallan los distractores

• «Los modelos obedecen de forma fiable» — nada lo garantiza; las instrucciones inyectadas compiten con las tuyas.
• «Oculto en la interfaz» — ocultar no es proteger si se puede inducir al modelo a mostrarlo.
• «Codificado en base64» — codificar no es cifrar, y el modelo puede decodificarlo o reproducirlo.

Qué quieren los entrevistadores

«Asume que el prompt puede filtrarse.» Después: secretos en una bóveda leídos por código de backend, credenciales de herramientas con mínimo privilegio y autorización aplicada en código, no en prosa.