Todo prompt enviado a un modelo alojado sale de tu entorno. Si contiene una clave de API, una contraseña o los datos personales de un cliente, esa información ya está en los sistemas de otro y posiblemente en los registros de ambas partes. La detección de información sensible es la práctica de encontrar ese contenido antes de enviar el prompt.
Cómo llegan los datos sensibles a los prompts
Rara vez a propósito. Las vías habituales:
- Registros y trazas de pila pegados que incluyen tokens, cadenas de conexión o cookies de sesión.
- Archivos de configuración compartidos para depurar:
.env, YAML, Terraform. - Código con una credencial incrustada.
- Registros de clientes en tickets de soporte, correos y transcripciones de chat.
- Documentos recuperados que contienen más de lo que necesita la pregunta.
- Archivos de prompts en un repositorio donde alguien probó con una clave real.
- Resultados de herramientas en un bucle de agente, reenviados al modelo sin filtrar.
Dos categorías, dos tipos de riesgo
Los secretos dan acceso: claves de API, tokens, contraseñas, claves privadas, cadenas de conexión. Un secreto filtrado se puede usar de inmediato. La respuesta es revocarlo y rotarlo.
Los datos personales (PII) identifican a personas: nombres, direcciones de correo, números de teléfono, direcciones postales, números de tarjeta de pago, números de documentos de identidad. Enviarlos puede incumplir tus compromisos de privacidad o la ley, y no se pueden rotar.
Cómo funciona la detección
Los detectores combinan varios métodos, porque cada uno tiene puntos ciegos.
Formatos conocidos. Muchos proveedores emiten claves con un prefijo y una longitud reconocibles. Se pueden detectar con gran confianza.
Patrones de contexto. Una asignación como password = "..." o api_key: ... marca el valor como una credencial, sea cual sea su formato.
Entropía. Las cadenas aleatorias tienen una entropía de Shannon alta. Un valor largo y de alta entropía junto a una palabra como «token» o «secret» es probablemente una credencial, incluso en un formato desconocido.
Identificadores estructurados. Las direcciones de correo, los teléfonos y los números de tarjeta siguen patrones. Los números de tarjeta pueden confirmarse con una suma de comprobación.
Reconocimiento de entidades nombradas. Los modelos estadísticos encuentran nombres, organizaciones y lugares que no tienen un patrón fijo. Más cobertura, más falsos positivos, y necesita un modelo.
El analizador de seguridad de prompts de PromptFlowEngine usa los cuatro primeros. Es determinista y se ejecuta en local, así que el texto que se comprueba en busca de secretos no se envía a ninguna parte para comprobarlo.
Informa de ubicaciones, nunca de valores
Un detector que imprime el secreto que encontró ha creado una segunda copia del secreto, en un registro o en un terminal. Un analizador bien diseñado devuelve solo la categoría y la posición:
{
"hasSensitiveData": true,
"countsByCategory": { "api_key": 1, "email": 1 },
"matches": [
{ "category": "api_key", "start": 118, "end": 164 },
{ "category": "email", "start": 176, "end": 196 }
]
}
Esta es la forma que PromptFlowEngine devuelve en todas sus interfaces. Consulta la regla de datos sensibles para ver un ejemplo práctico.
Censura
La censura sustituye cada valor detectado por un marcador que conserva el sentido del texto que lo rodea.
Before: Connect with postgres://admin:hunter2@db.internal:5432/app
After: Connect with [REDACTED_CONNECTION_STRING]
Los marcadores tipados como [REDACTED_API_KEY] son mejores que una fila de asteriscos, porque el modelo sigue sabiendo qué tipo de cosa había y puede razonar sobre ella («la cadena de conexión parece mal formada») sin verla.
Para los datos personales a los que la tarea necesita referirse, usa seudónimos coherentes dentro de una misma solicitud: cada aparición de un correo pasa a ser [EMAIL_1], la siguiente dirección [EMAIL_2]. Así el modelo puede distinguir a las personas y tu aplicación puede volver a asignar los marcadores después de la respuesta.
Dónde poner la comprobación
Detecta lo antes posible y en más de un lugar.
| Dónde | Qué detecta |
|---|---|
| En el editor o el cuadro de chat | Un pegado, antes de enviarlo |
| En el código de la aplicación, antes de la llamada a la API | Datos de usuarios, registros y recuperación |
| Entre los pasos del agente | Resultados de herramientas a punto de entrar en el contexto |
| En CI, sobre los archivos de prompts | Credenciales confirmadas en un repositorio |
| Antes de registrar | Contenido a punto de almacenarse |
La extensión de Chrome avisa mientras un borrador en ChatGPT, Claude o Gemini contiene un secreto, y puede censurarlo en tu dispositivo. La extensión de VS Code ejecuta una protección de privacidad antes de enviar un prompt al chat, con los modos estricto, censura y aviso. En CI, la puerta de comprobación falla por defecto ante cualquier hallazgo crítico, de modo que una clave confirmada detiene la compilación.
Opciones de política: bloquear, censurar o avisar
- Bloquear cuando un secreto no deba enviarse nunca. Lo más seguro y lo más disruptivo.
- Censurar como opción predeterminada. El prompt se envía sin los valores sensibles.
- Avisar cuando deba decidir una persona, por ejemplo ante un posible falso positivo en el código.
Elijas lo que elijas, aplica la detección de secretos en local. Una comprobación que envía el texto a un servicio remoto para averiguar si es seguro enviarlo anula su propósito.
Límites que debes conocer
- Falsos negativos. Un secreto en un formato inusual, o un dato personal sin patrón, como la descripción de una persona, puede pasar. La detección reduce el riesgo; no certifica que un prompt esté limpio.
- Falsos positivos. Los hashes, los UUID y los datos de prueba pueden parecer secretos. Pon en una lista de permitidos los valores seguros conocidos en lugar de desactivar la comprobación.
- Imágenes y archivos. Los analizadores de texto no leen capturas de pantalla ni PDF salvo que se conviertan antes.
- Contexto. Un nombre es público en un entorno y confidencial en otro. Solo tu política puede decidirlo.
Más allá de la detección: envía menos
El control más fiable es no incluir los datos en absoluto.
- Pasa un ID y deja que una herramienta busque el registro, de modo que el modelo nunca vea campos que no necesita.
- Elimina campos antes de construir el prompt.
- Mantén las credenciales en tu aplicación y dáselas a las herramientas directamente. Un modelo nunca necesita tu clave de API para pedirle a una herramienta que llame a una API.
- Usa datos de prueba en los ejemplos y en los archivos de prompts.
Si un secreto ya se ha enviado
- Revócalo y rótalo de inmediato. Trátalo como comprometido.
- Comprueba en los registros de acceso si se ha usado.
- Elimínalo del historial del repositorio y de los archivos de prompts.
- Añade una comprobación para que la misma vía se detecte la próxima vez.
Para el modelo de amenazas que lo rodea, consulta la seguridad de prompts. Para los ataques que intentan extraer datos una vez que están en el contexto, consulta la inyección de prompts.