Agentes IA y credenciales: proteger secretos técnicamente en vez de confiar

Un desarrollador de software configura un agente de programación y confirma una pregunta con el cómodo clic. Una semana después, en su repositorio público de GitHub hay un archivo de configuración con una clave de API válida. No ha hecho nada malo que salte a la vista. Solo ha usado una función pensada precisamente para ahorrarle clics. Que de ahí haya salido un conjunto de credenciales accesible públicamente, nadie en su equipo lo ve.

En este artículo descubres cómo los agentes de IA han dado de qué hablar esta semana, por qué no es un error de principiante sino un patrón del sistema, por qué las reglas en el prompt no aguantan ante esos riesgos y con qué cinco piezas aseguras técnicamente las credenciales y los permisos de tus agentes.

---

Índice

1. El incidente: credenciales en un repositorio público
2. Por qué es un patrón, no un accidente
3. Los guardrails no bastan
4. Cinco piezas para secretos y permisos
5. Implementación en siete días
6. Conclusión

---

El incidente: credenciales en un repositorio público

heise online informó el 9 de noviembre de 2026 sobre un análisis de la empresa de seguridad informática Apiiro. Los investigadores examinaron más de 100.000 copias de un archivo de configuración de Claude Code depositadas públicamente en GitHub y encontraron secretos reales en 1.105 de ellas. En el cómputo global hallaron 2.539 credenciales reales en 1.994 repositorios públicos: contraseñas de bases de datos, claves de nube, tokens de API y accesos root por SSH. Otras 1.160 credenciales estaban escondidas en el historial de Git, en un archivo de ajustes que los equipos compartían a propósito y en transcripciones de chats con agentes que alguien había dejado ahí. En 539 de los repositorios afectados había un commit en el que el propio agente había modificado el archivo como coautor.

La causa es poco espectacular, y por eso mismo resulta ilustrativa. Un agente de programación pregunta, al acceder a una base de datos o a una API, si debe ejecutar el comando propuesto, y ofrece la opción de no volver a preguntar en adelante. El comando ejecutado contiene las credenciales. Si eliges la opción por comodidad, esas credenciales acaban en un archivo de ajustes local dentro de la carpeta del proyecto. En teoría ese archivo nunca debería salir del ordenador del desarrollador, y la herramienta además lo añade a la lista de exclusión de Git. Pero eso no funciona cuando una carpeta se convierte en repositorio solo más tarde, cuando se clonó desde otra máquina o cuando alguien ya ha hecho commit del archivo. Entonces la regla queda sin efecto y el archivo sin protección.

El consejo de Apiiro está formulado a propósito en este orden: busca en tu organización de GitHub y en el historial de Git esos dos nombres de archivo, sustituye primero las credenciales que encuentres y solo después limpia. Quien borra primero se queda con un secreto filtrado que sigue siendo válido. El responsable de Claude Code ya ha anunciado que su equipo está estudiando cómo atajar el caso técnicamente.

Por qué es un patrón, no un accidente

Sería tranquilizador despacharlo como un problema de la herramienta. No lo es. Un segundo informe de esta semana muestra la dirección contraria. GitGuardian catalogó el 9 de noviembre de 2026 unos 45 frameworks de código abierto que integran un modelo de lenguaje en un bucle que ejecuta herramientas y reacciona a su salida. Cuatro de ellos incorporan un escáner de secretos que busca específicamente credenciales en GitHub público. Según el análisis de Microsoft, con una de esas herramientas los atacantes podían usar credenciales filtradas en menos de cinco minutos para entrar en un entorno de Azure.

Esto no significa que tu pyme se convierta en objetivo de un ataque dirigido. Significa que las herramientas que buscan credenciales olvidadas se han vuelto automáticas y baratas. Un secreto que por descuido queda público ya no es secreto mucho tiempo. La catalogación para el buscador Shodan encontró, solo en la familia de herramientas en torno al framework ARTEX, ya desactivado, el 7 de noviembre de 2026 un total de 1.428 servicios accesibles en la red abierta. Parte de esas herramientas es accesible sin ningún tipo de autenticación si se operan sin pensar.

Para ti la lección es doble. Primero: un agente al que das credenciales puede pasarlas adelante, y además a un lugar que no controlas. Segundo: la otra parte busca con los mismos medios con los que trabajas tú.

Los guardrails no bastan

Un segundo artículo de heise online, un texto de fondo sobre la arquitectura de agentes de IA en el back office, nombra el problema central con más precisión que cualquier debate sobre herramientas. Los autores describen un caso realista de fraude. Un agente vigila el buzón del departamento de contabilidad, recibe un correo de un remitente conocido con la petición de cambiar la cuenta bancaria, lo clasifica correctamente como un cambio de datos maestros, detecta la urgencia, llama a la herramienta de cambio y el siguiente pago va, en lugar de al proveedor, a un estafador en el extranjero. Cada paso individual era plausible por sí solo.

El reflejo obvio es un prompt más estricto, una regla adicional, una indicación mejor para el agente. Ahí está precisamente el error de razonamiento. Las reglas en el prompt, los guardrails en jerga técnica, dirigen el comportamiento, pero no lo imponen. El modelo interpreta la instrucción, no la obedece como un programa obedece una condición. Indicaciones contradictorias, malas interpretaciones o entradas manipuladas pueden anular su efecto. El artículo lo asocia a los cuatro riesgos que la OWASP incluye para los sistemas y agentes basados en LLM en sus listas Top 10 para 2026:

Prompt Injection. Instrucciones ocultas en correos, documentos o páginas web manipulan el comportamiento. Una solicitud de un proveedor puede contener en la letra pequeña la instrucción de usar otra cuenta.

Excessive Agency. El agente tiene más permisos de los que exige su tarea. Quien revisa facturas no necesita el permiso de ejecutar pagos.

Agent Goal Hijack. No se manipula una acción concreta, sino el objetivo superior. Una cadena de pasos plausibles hace que el agente actúe en interés del atacante sin que salte ninguna alarma, porque cada paso individual parece explicable.

Memory and Context Poisoning. Quien introduce de forma dirigida contenidos en la memoria a largo plazo de un agente influye de manera permanente en decisiones posteriores. Lo conocemos de la operación diaria: cuando los agentes recuerdan, también recuerdan lo falso.

La conclusión de los autores es la frase más importante de la semana para cualquiera que opere agentes en producción: un sistema que en principio permite acciones críticas compite en una carrera con atacantes creativos. Quien quiera evitarlo debe construir el sistema de modo que el error ni siquiera pueda producirse. Los guardrails son control del comportamiento. Los controles técnicos son límites. Hasta qué punto hay que ajustar los permisos y las autorizaciones lo desglosamos en Controlar agentes de IA con permisos y autorizaciones, aquí se trata de las credenciales y de su aplicación técnica.

Cinco piezas para secretos y permisos

Para esto no necesitas un departamento de seguridad. Necesitas cinco hábitos que se pueden implantar en una pyme normal.

Pieza 1: Ninguna credencial en el contexto. Un secreto nunca pertenece a un prompt, nunca a un archivo de configuración en la carpeta del proyecto y nunca a una transcripción de chat. Las herramientas leen las credenciales en tiempo de ejecución de un almacén de secretos o de una variable de entorno, jamás de lo que ve el propio agente. Si un agente debe ejecutar una consulta a una base de datos, el sistema le da el acceso, no el texto de su instrucción.

Pieza 2: Identidad propia por agente, tokens de vida corta. Cada agente recibe una identidad técnica propia en lugar de una cuenta compartida. Mejor aún son los tokens que caducan al cabo de una hora. Entonces un token filtrado deja de valer al poco tiempo, y en el registro queda qué agente ha actuado. Es el mismo principio que con los permisos, solo que aplicado de forma consecuente a las credenciales.

Pieza 3: Permisos tan estrechos como la tarea. Comprueba para cada agente qué necesita de verdad. Un revisor de facturas necesita permisos de lectura y quizá el derecho a marcar un registro, pero no el derecho de ejecutar pagos. Esta separación es la protección más eficaz contra el caso de fraude del artículo de heise, porque el agente no puede ejecutar el paso crítico aunque un correo manipulado quiera empujarlo a ello.

Pieza 4: Visibilidad hacia fuera. Un agente que accede con tus credenciales a sistemas ajenos debe registrarse. ¿Quién llamó a qué herramienta, con qué token y cuándo? En un agente con acceso a la red hay que añadir además un control de salida: una herramienta que de repente intenta enviar datos a una dirección desconocida es una señal de alarma, no un proceso normal. Las herramientas de ataque como las del informe de GitGuardian pasan precisamente cuando nadie vigila las salidas.

Pieza 5: Detectar y rotar. Busca en tus repositorios y en su historial de forma sistemática nombres de archivo y patrones de claves conocidos, por ejemplo con un escáner de secretos. Si encuentras algo, se aplica el orden del informe de Apiiro: primero invalidar y sustituir el conjunto de credenciales, después eliminar el archivo del repositorio y del historial. Y como un agente también puede escribir un secreto en un registro durante la operación, las credenciales en los logs van enmascaradas, nunca en texto plano. Quien rota una credencial filtrada solo después de limpiar, ha escondido la brecha, no la ha cerrado.

Implementación en siete días

Esto se puede montar en una semana, sin detener la operación.

Día 1: Inventario. Enumera todos los agentes y automatizaciones que trabajan con credenciales. Para cada entrada anotas dos cosas: dónde están las credenciales y qué permisos tienen.

Día 2: Revisar repositorios. Pasa un escáner de secretos por tu organización de GitHub, incluido el historial. Comprueba además específicamente los archivos de ajustes que crean los agentes. Cada hallazgo lo tratas según la pieza 5.

Día 3: Sacar las credenciales del contexto. Todo lo que esté en texto plano en un prompt, un archivo de configuración o un nodo de workflow pasa a un almacén de secretos o a una variable de entorno. Tras la reforma, comprueba que cada ejecución siga funcionando.

Día 4: Reducir permisos. Toma el agente con los permisos más amplios y quítale todo lo que no necesita de forma imprescindible para su tarea. Empieza por el permiso de modificar pagos o datos maestros. Un workflow de n8n es aquí tu ventaja: los permisos se pueden ligar a un único nodo de autorización que activas de forma centralizada.

Día 5: Tokens de vida corta y registro. Donde tu sistema de destino lo permita, cambia a tokens con caducidad. Añade a cada llamada de herramienta una línea de registro con el nombre del agente, la herramienta y el momento. Impón además el enmascaramiento de las credenciales en los logs.

Día 6: Control de salida. Para los agentes con acceso a la red defines una lista de destinos permitidos. Todo lo que no esté en ella se bloquea y se notifica. Es la misma pieza que en una emergencia evita lo peor, ver Interruptor de emergencia para agentes de IA.

Día 7: Ensayo y entrada en el calendario. Prueba una vez cuánto se tarda en encontrar un conjunto de credenciales, rotarlo y verificarlo. Después fija una cita recurrente cada trimestre. Y no olvides el canal invisible: dos agentes con acceso al mismo sistema pueden comunicarse de forma indirecta a través de ese sistema, sin que tú lo hayas previsto. Por qué eso es un riesgo propio lo contamos en Colusión entre agentes de IA por canales laterales.

Consejo práctico: Rota las credenciales de inmediato y de forma automática en cuanto salte un escáner, y trata cada hallazgo como si ya se hubiera explotado. El minuto de retraso al pensar es más barato que la semana de limpieza posterior.

Conclusión

Esta semana ha mostrado dos caras del mismo problema. Por un lado, los agentes filtran credenciales hacia donde no deberían, sin que nadie note un error. Por otro, hay herramientas automáticas listas que buscan precisamente esos secretos y los explotan en cuestión de minutos. En medio está la tentación de querer resolver el problema con un prompt más estricto. Eso no funciona, porque un prompt guía el comportamiento, pero no pone un límite.

El camino eficaz es poco espectacular: secretos nunca en el contexto, identidad propia por agente, permisos tan estrechos como la tarea, visibilidad hacia fuera y rotación inmediata ante cualquier hallazgo. Quien tiene estos cinco puntos puede rechazar un intento de fraude como el de la cuenta bancaria manipulada, porque el agente no puede ejecutar la acción crítica técnicamente. Quien no los tiene, se fía de un modelo de lenguaje en un punto donde debería haber un programa.

El primer paso es factible hoy y no dura ni una hora: un escáner de secretos sobre tus repositorios. Esta semana ha demostrado cuánto suele salir a la luz con ello. Cómo operamos los agentes con su propio almacén de secretos, puntos de autorización y control de salida lo contamos en la página del sistema de IA B.R.A.I.N..

Sobre MadeByBrain: Construimos automatización con IA para las pymes: agentes de IA propios, workflows de n8n y estrategias GEO, en uso real. Desde la primera idea hasta la automatización productiva.

Reserva ahora tu sesión de estrategia gratuita →