Qué hacer si se filtran secretos en un agente de IA: revocación de accesos, auditoría y retorno al trabajo

Instrucciones verificadas con la documentación el 16 de septiembre de 2026.

Cuando un agente autónomo ejecuta comandos como git diff, lee archivos locales de configuración o incluye accidentalmente volcados de variables de entorno directamente en los prompts del modelo, los secretos abandonan el perímetro de confianza. En esta situación, es necesario detener los scripts en segundo plano, bloquear las credenciales comprometidas, auditar los registros teniendo en cuenta sus limitaciones y reiniciar el entorno según el principio de mínimo privilegio.

Diferenciación entre configuración normal y filtración de contexto

Antes de iniciar la respuesta al incidente, es fundamental distinguir entre el uso normal de la API y una vulneración real.

El funcionamiento normal implica transmitir la clave de API exclusivamente en los campos de autorización del proveedor de modelos previsto (por ejemplo, a través de las variables OPENAI_API_KEY o ANTHROPIC_API_KEY) para autenticar las solicitudes de la herramienta ante el modelo de lenguaje. Las variables como ANTHROPIC_BASE_URL o OPENAI_BASE_URL definen la dirección de red del punto de conexión (endpoint/base URL), no un secreto o token de autenticación.

Se considera una filtración a través del modelo a aquel suceso en el que secretos ajenos de infraestructura —como tokens de acceso personal de GitLab, claves de larga duración de AWS IAM, claves privadas de SSH, credenciales de bases de datos o tokens de redes corporativas— entran en el cuerpo de la solicitud del usuario, el contexto de la conversación, los archivos adjuntos o los flujos de salida de utilidades (stdout/stderr) y se transmiten efectivamente al exterior hacia un servicio externo. No se debe partir de la base de que todos los servidores proxy o pasarelas intermedias sean perjudiciales a priori; sin embargo, enviar un secreto fuera de un entorno aislado exige una contención inmediata.

Primeras acciones: detener procesos y documentar el incidente

La máxima prioridad es impedir que continúe la transmisión de datos:

1. Termine el proceso local del agente y deshabilite las tareas en segundo plano asociadas (tareas cron, scripts de automatización de CI/CD).
2. Registre los metadatos del incidente en un informe local sin duplicar el secreto en sí: tipo de credencial comprometida, marca de tiempo aproximada de la primera solicitud, identificador de la tarea/sesión y dirección de red del punto de conexión (endpoint) receptor.
3. No envíe el secreto expuesto en texto plano a canales de soporte técnico ni en consultas posteriores a redes neuronales para su verificación.

Todas las operaciones de revocación y sustitución de claves deben realizarse exclusivamente desde una estación de trabajo de confianza mediante las consolas oficiales de administración de los proveedores.

Revocación de accesos según el tipo de servicio

Las distintas plataformas implementan el aislamiento y la revocación de autorizaciones de acuerdo con diferentes reglas arquitectónicas.

Claves de acceso a modelos (OpenAI API)

De conformidad con las prácticas recomendadas oficiales de OpenAI para la seguridad de claves de API, la sospecha de una vulneración requiere la rotación de la clave y la revisión del consumo de recursos.

Ante la sospecha de una filtración, la clave comprometida debe revocarse en primer lugar:

1. Acceda de inmediato a la interfaz web de administración de claves de API de OpenAI y revoque (Revoke/Delete) la clave comprometida. Esto bloquea nuevas llamadas no autorizadas a costa de un tiempo de inactividad temporal y controlado para los servicios dependientes; no se debe posponer la revocación a la espera de una auditoría exhaustiva o de una prolongada actualización en todos los servicios dependientes.
2. Genere una nueva clave y actualice la configuración de los servicios.
3. Abra el panel Usage y analice la actividad dentro de la ventana de exposición delimitada, comparándola con las operaciones previstas.

Tokens de acceso personal de GitLab

Según la documentación de GitLab sobre Personal Access Tokens, revocar un token de acceso personal lo invalida de forma inmediata:

1. En la interfaz de GitLab, haga clic en su avatar en la esquina superior derecha > Edit profile > Access > Personal access tokens.
2. En la tabla de tokens activos, busque el identificador del token comprometido y haga clic en Revoke.

La función Rotate en GitLab invalida el token anterior, pero conserva los mismos ámbitos de permisos (scopes). Si el token comprometido tenía permisos excesivos, debe revocarse por completo y sustituirse por uno nuevo configurado con el alcance mínimo necesario. En la página de detalles del token se muestran la fecha del último uso y las cinco direcciones IP únicas más recientes. Tenga en cuenta que estas métricas se actualizan con retraso del sistema.

Claves de acceso de AWS (IAM Access Keys)

El procedimiento de neutralización para las claves de IAM se rige por la guía de AWS sobre protección de claves de acceso y la documentación sobre administración de claves de acceso para usuarios de IAM:

1. Inicie sesión en AWS Management Console, vaya a IAM > Users y abra la pestaña Security credentials.
2. En la sección Access keys, localice el identificador de la clave comprometida y cambie su estado a Deactivate.
3. Una vez restablecido el control, elimine la clave seleccionando Delete.

[!IMPORTANT] Cambiar el estado de una clave a Deactivate interrumpe la aceptación de nuevas solicitudes firmadas con esta credencial de larga duración, pero no invalida las credenciales temporales emitidas previamente (tokens de AWS STS) ni finaliza automáticamente las sesiones activas. La acción Revoke active sessions solo se aplica a las sesiones del rol de IAM correspondiente; las sesiones activas de IAM Identity Center y otros tipos de tokens STS requieren una revocación independiente según sus mecanismos específicos de autenticación. El administrador de seguridad también debe cotejar las llamadas a la API mediante AWS CloudTrail y la operación get-access-key-last-used. No ejecute comandos destructivos de eliminación masiva no probados a través de la CLI durante un incidente activo.

Claves OpenSSH y autorización

Los procedimientos de autorización de OpenSSH están documentados en los manuales de referencia man sshd(8) y sshd_config(5):

1. Los administradores deben eliminar la clave pública comprometida del archivo de autorización en todos los servidores. La ruta del archivo está determinada por la directiva AuthorizedKeysFile (por defecto ~/.ssh/authorized_keys, aunque la infraestructura puede tener configurado un archivo centralizado o validación de certificados mediante una CA de SSH).
2. Antes de realizar modificaciones, asegúrese de contar con una vía de acceso de respaldo independiente (como la consola web del proveedor o administración fuera de banda / out-of-band management) para evitar perder el acceso.
3. Eliminar la clave pública impide que se establezcan nuevas conexiones, pero no interrumpe las sesiones que ya estén activas.

El comando who solo muestra a los usuarios con un pseudoterminal (TTY) asignado y no proporciona un inventario exhaustivo de sesiones: no revelará túneles, reenvíos de puertos ni comandos no interactivos. Finalizar a ciegas el proceso raíz sshd es inadmisible, ya que no garantiza la desconexión de las sesiones secundarias y puede dejar al administrador sin acceso al servidor. El administrador debe inspeccionar de manera puntual el árbol de procesos, las conexiones de red y los registros de autorización, finalizando individualmente las sesiones sospechosas. Eliminar localmente la clave privada o cambiar su frase de contraseña (passphrase) no tiene efecto alguno sobre una clave que ya haya sido copiada externamente.

Redes Tailscale y VPN corporativas

Según la documentación de Tailscale sobre Auth Keys, una clave de autenticación está destinada exclusivamente al registro de nodos:

1. En la consola de Tailscale, vaya a la sección Keys y revoque la auth key comprometida. Esto evitará que se registren nuevos dispositivos.
2. Revocar una auth key no desconecta los nodos ya registrados. El administrador debe dirigirse a la pestaña Machines, revisar el inventario de equipos y eliminar manualmente (Remove/Delete) cualquier dispositivo no autorizado.

En el caso de las VPN corporativas tradicionales (IPsec, OpenVPN, WireGuard y soluciones propietarias), no existe un procedimiento universal único de revocación mediante CRL: el mecanismo concreto depende del esquema de autorización utilizado (certificados x509, claves estáticas preshared keys, tokens RADIUS/IdP). En muchas pasarelas, cambiar la contraseña de una cuenta no interrumpe de forma inmediata un túnel activo. El procedimiento debe derivarse al administrador de red para revocar el certificado/cuenta y forzar la desconexión de las sesiones activas a través de la consola de administración de la pasarela VPN correspondiente.

Análisis de consecuencias: registros, ventanas de tiempo y riesgos irreversibles

Al correlacionar el incidente con los registros del sistema, tenga en cuenta las limitaciones técnicas de la telemetría:

• Ventana de exposición: determine el intervalo exacto de tiempo transcurrido desde la transmisión inicial del secreto al agente hasta la revocación confirmada de la clave y la finalización de las sesiones activas.
• Limitaciones de los registros: considere el retraso en la ingesta de eventos (ingestion delay), los períodos de retención de registros (retention period) y los puntos ciegos de la telemetría (como la falta de auditoría detallada de parámetros en ciertas API o la ausencia de registro para sesiones sin TTY).
• Principio de ausencia de evidencia: la ausencia de entradas anómalas en los registros o un consumo de tokens igual a cero dentro de la ventana de registro accesible no demuestra que el secreto no haya sido interceptado o almacenado por un tercero para un uso posterior.

La revocación de claves bloquea futuras solicitudes, pero no recupera los datos, el código fuente o las variables de entorno que ya hayan sido transmitidos a un servicio externo. La función para eliminar una conversación en la interfaz web del agente o de la plataforma oculta el historial, pero no constituye una garantía técnica de que los datos se hayan eliminado de los registros o cachés del proveedor receptor (downstream).

Reinicio seguro: mitigación de riesgos y verificación del aislamiento

El retorno del agente a la actividad operativa debe reducir el riesgo de que el incidente se repita:

1. Tokens de corta duración: utilice credenciales de sesión con límite de tiempo siempre que las plataformas y la infraestructura lo admitan.
2. Límites del espacio de trabajo: excluya archivos .env, claves privadas y directorios con secretos del espacio de trabajo del agente; trasladar los secretos fuera del espacio de trabajo no garantiza un aislamiento total ni reemplaza el control de accesos a nivel de sistema operativo.
3. Comprobación de límites sin señuelos de red (canary tokens): para comprobar los permisos, cree un directorio temporal aislado que esté completamente libre de secretos reales. Coloque en su interior un archivo simulado con contenido ficticio y compruebe si el agente bloquea el acceso al archivo, la ejecución de comandos del intérprete de comandos y la lectura de variables mediante env. No recurra a servicios externos de canary tokens en red para la validación básica de permisos.
4. Defensa en profundidad: interceptar con éxito las lecturas en una sola ruta no demuestra un aislamiento completo del proceso si el agente mantiene un acceso irrestricto a la terminal o a la red.

Los enfoques arquitectónicos detallados para restringir las llamadas al sistema y segregar permisos se abordan en la guía de administración de permisos y secretos en Claude Code. Minimizar los privilegios de las cuentas y prescindir de secretos estáticos reduce los riesgos al delegar tareas a herramientas autónomas de IA.