Las claves, fuera del prompt

El verdadero riesgo de un prompt de programación rara vez es el algoritmo. Es lo que viaja con el código: una clave de API olvidada en un archivo de configuración, una cadena de conexión, datos de clientes en un conjunto de pruebas, un nombre de servidor interno. Proteger el código frente a los asistentes de IA empieza por mantener todo eso fuera del prompt, no por alejar a los desarrolladores del asistente.

Qué sale en realidad

Imagine a una desarrolladora que pide al asistente que arregle una función que falla. Para ayudar, el asistente necesita contexto y lee los archivos de alrededor. Esos archivos nunca se escribieron pensando en un lector externo. Contienen un token escrito a mano en un arreglo nocturno, un registro de ejemplo copiado de producción, un comentario con el nombre del servidor con el que habla el código.

Nadie decidió compartir nada de eso. La herramienta lo recogió porque así funciona. Un agente que puede leer un repositorio puede leer todo lo que hay en él, y puede hacerlo muchas veces por hora.

Por eso una norma escrita del tipo «no pegue secretos en las herramientas de IA» se queda corta. Nadie pegó nada. Lo recogió el agente.

Por qué prohibir los asistentes no funciona

Algunas organizaciones reaccionan prohibiendo por completo los asistentes de código. La prohibición es fácil de anunciar y difícil de mantener. Los desarrolladores son más rápidos con estas herramientas y lo saben. Cuando se cierra la vía aprobada, el trabajo pasa a una cuenta personal o a un equipo doméstico, y el mismo código llega a los mismos modelos sin que nadie lo vea.

Además, una prohibición deja sin responder la pregunta más importante: qué código importa. Un sitio de marketing y un servicio central de pagos no tienen el mismo riesgo, y tratarlos igual frena a todo el mundo o no protege nada.

Tres cosas que conviene controlar

Un enfoque práctico tiene tres partes.

Reconozca lo que lleva el prompt. El código fuente es una categoría propia de datos, y la política debe poder tratarlo de forma distinta a un documento de marketing. Los secretos necesitan su propia detección: las claves de API, los tokens y las cadenas de conexión no se parecen a nada más, y se pueden encontrar antes de que viajen. Los datos personales en los conjuntos de pruebas se detectan igual que en cualquier otro lugar.

Controle el camino. Los ganchos del agente pueden revisar un prompt en herramientas como Claude Code y Codex antes de enviarlo. Un gateway de IA da al tráfico hacia las API de Anthropic y OpenAI una sola salida, con un registro de auditoría detrás. También hay que cubrir Copilot y Cursor, porque los desarrolladores rara vez usan una sola herramienta.

Ordene sus repositorios. No todo el código merece la misma regla. Clasificar los repositorios como rojos, amarillos o verdes hace que la política se ajuste al riesgo. Un repositorio rojo contiene código crítico, así que el asistente no puede leerlo en absoluto. Un repositorio amarillo se puede usar con cuidado y dejando registro. Un repositorio verde queda abierto al uso normal.

Lo que el enmascaramiento no puede hacer aquí

El enmascaramiento funciona bien con los datos personales. Un nombre o un número de cuenta se puede sustituir por una etiqueta, enviarse al modelo y restaurarse en la respuesta. El código no funciona así. Una función con la lógica enmascarada ya no es una función, de modo que el asistente no puede ayudar con ella.

Eso simplifica la decisión. Enmascare los valores personales cuando pueda, detenga los secretos siempre y, en el código crítico, la decisión es bloquear. Si no se puede llegar al motor de decisiones, un repositorio rojo debe aplicar el cierre por fallo, para que una avería de red nunca se convierta sin avisar en una puerta abierta.

Una política con la que se pueda trabajar

La prueba de una política es si la gente la sigue un viernes con prisas. Algunos hábitos ayudan.

• Permita el asistente aprobado en la cuenta de la empresa y déjelo funcionar con normalidad en el código de cada día.
• Detenga un prompt solo cuando intervenga un secreto o un repositorio crítico, y explique el motivo en una línea.
• Ofrezca una salida: quitar la clave, usar la cuenta aprobada o llevar la tarea a un repositorio que lo permita.
• Registre el evento, para que después se pueda rotar la clave y aprender de lo ocurrido.

Un prompt detenido es útil por sí mismo. A menudo descubre una clave que nunca debió estar en el repositorio, mucho antes de que la encuentre alguien de fuera.

Por dónde empezar

Empiece por mirar. Averigüe qué asistentes se usan, con qué cuentas y sobre qué repositorios. Después clasifique los repositorios, empezando por los pocos que más daño harían si se filtraran. Active a continuación la detección de secretos, porque ahí es donde un solo error sale más caro.

Prohibir la IA en ingeniería no protege el código. Solo oculta cómo se está usando. El objetivo es mantener las claves fuera y dejar que los desarrolladores sigan trabajando. Lea cómo se cubren los asistentes de código IA en GuardStance.