Credenciales de agentes IA: 7 reglas de control de acceso

Brazo robótico impulsado por IA manejando documentos en una carpeta segura, con iconos de candado y llave que simbolizan la seguridad de agentes de IA y el control de acceso.

Los agentes de IA ahora poseen claves API y credenciales de bases de datos que antes pertenecían únicamente a personas o pipelines. También llevan tokens de servicio, a menudo con menos restricciones de las que jamás tendría un usuario humano. Una encuesta de Palo Alto Networks de 2026 a 2.930 responsables de ciberseguridad en 20 países encontró un promedio de 109 identidades de máquina por cada identidad humana en las organizaciones encuestadas, y 79 de esas 109 eran agentes de IA. La encuesta muestra lo rápido que la identidad no humana se ha convertido en un problema de gestión de acceso.

La mayoría de las organizaciones emiten credenciales para agentes de la misma manera que entregan un portátil a un nuevo empleado: crear una cuenta, otorgar acceso amplio para que nada falle, y seguir adelante. Ese enfoque funciona para las personas, porque un empleado humano normalmente se detendrá y verificará antes de tomar una acción que pueda causar daño. Funciona menos bien para un sistema que actúa según cualquier instrucción que parezca más convincente en el texto que acaba de leer.

Este artículo cubre el aspecto de credenciales de la seguridad de agentes: cómo emitir, delimitar y auditar los secretos que un agente autónomo o herramienta basada en LLM necesita, sin entregarle una llave maestra permanente. Se apoya en el modelo de secretos DevOps de Passwork, que ya responde la mayor parte de esta pregunta para pipelines de CI/CD. La huella de credenciales de un agente se asemeja mucho más a la de un pipeline que a la de una persona.

Puntos clave

Los agentes ya superan en número a los empleados. 109 identidades de máquina por humano, 79 de ellas agentes de IA (Palo Alto Networks, 2026).
Cada agente obtiene su propia cuenta de servicio. Las cuentas compartidas eliminan la atribución en el momento en que algo sale mal.
Delimitar permisos a la tarea. Un único permiso de API más el acceso más restringido a la bóveda determina si un compromiso cuesta una credencial o toda la flota.
Ajustar la vida útil del token al tiempo de ejecución. 15-60 minutos para agentes basados en tareas, hasta 4 horas para los que están siempre activos.
Los archivos de configuración estáticos son los que más filtran. GitGuardian encontró 24.008 secretos expuestos en archivos de configuración MCP públicos solo en 2025.
Mantener las credenciales sin procesar en una capa de ejecución de herramientas aislada. Un intermediario de credenciales puede implementar este límite, siempre que el agente orientado al modelo nunca reciba el secreto.
El filtrado y escaneo añaden fricción en lugar de autorización. Comment and Control eludió el filtrado, escaneo de secretos y lista de permitidos de red de Copilot Agent, mientras que CamoLeak usó el proxy Camo de GitHub como canal de exfiltración separado. Estos casos respaldan un límite de autorización intermediado, pero no demuestran que pueda detener la inyección de prompts por sí solo.
Una identidad por agente hace que la revocación sea quirúrgica. Desactivar una cuenta comprometida mientras todos los demás agentes siguen funcionando.
La rotación aún requiere un proceso que usted mismo ejecute. Passwork cubre cuentas, acceso, tokens y registros de auditoría como base.

Por qué las credenciales de agentes de IA necesitan controles diferentes

Un script sigue la misma ruta de código cada vez, por lo que puede delimitar su acceso antes de que se ejecute. Un agente de IA elige qué herramienta llamar basándose en el texto que lee en tiempo de ejecución, y parte de ese texto puede provenir de un atacante. OWASP (Open Worldwide Application Security Project) denomina este modo de fallo LLM06:2025, Agencia Excesiva: la salida inesperada, ambigua o manipulada del modelo puede desencadenar acciones dañinas cuando un agente tiene funcionalidad, permisos o autonomía excesivos.

La inyección de prompts es texto diseñado para anular las instrucciones de un agente. Es una forma en que ocurre esta manipulación, no la única. Dos divulgaciones del último año muestran cómo se ve en la práctica: Comment and Control (abril de 2026) exfiltró tokens activos de tres agentes de codificación a través de un comentario oculto de GitHub, y CamoLeak (octubre de 2025) usó un pull request oculto para hacer que GitHub Copilot Chat filtrara datos de repositorios privados a través de un canal de proxy de imágenes. En ambos casos, un agente tenía acceso a herramientas, una credencial activa estaba al alcance, y texto no confiable hizo que el agente lo tratara como una instrucción. La Regla 6 cubre los mecanismos de ambos.

Las 7 reglas para asegurar las credenciales de agentes de IA

Estas reglas aplican la disciplina de acceso que los equipos DevOps ya usan para secretos de pipeline a un actor que decide su propio siguiente movimiento. La mayoría se ejecutan con controles que las plataformas maduras de secretos e identidad ya ofrecen. Lo que cambia es dónde trazar el límite entre lo que el agente puede solicitar y lo que tiene permitido poseer.

Regla 1: Dar a cada agente su propia cuenta de servicio

Una cuenta de servicio es un inicio de sesión creado para un sistema automatizado en lugar de una persona, con su propio rol y su propio par de tokens, independiente de cualquier empleado. Cada agente en producción necesita una. Compartir una sola cuenta entre múltiples agentes elimina la atribución. Cuando algo sale mal, el registro dice «el agente» en lugar de indicar qué ejecución, qué tarea o qué despliegue lo causó.

La guía de Passwork sobre cuentas de servicio y tokens API establece esto como la primera regla para cualquier automatización, incluidos los agentes: nunca autenticar un script o agente con una cuenta personal. Los permisos de una cuenta personal suelen ser más amplios de lo que el trabajo necesita. Sus acciones se registran bajo el nombre de un empleado en lugar del de la automatización, y revocar el acceso significa editar el perfil personal de alguien en lugar de eliminar una cuenta dedicada.

Cuenta	Propósito	Acceso
agent-support-triage-ro	Lee tickets de CRM, redacta respuestas	Solo lectura, bóveda de soporte
agent-deploy-approval	Revisa y aprueba despliegues	Solo lectura, bóveda de infraestructura
agent-cred-rotator	Rota secretos según programación	Leer y editar, ambos entornos

Nombrar las cuentas por función, no por número. agent-support-triage-ro le indica a un ingeniero de guardia qué hace la cuenta seis meses después. agent-3 no le dice nada.

El modelo de cuenta de servicio de Passwork emite un inicio de sesión, rol y par de tokens separados para cada agente, sin cuenta personal asociada. Vea cómo funcionan las cuentas de servicio DevOps en Passwork.

Regla 2: Delimitar permisos a la tarea

La guía de OWASP sobre Agencia Excesiva se reduce a dos acciones:

aplicar el mínimo privilegio limitando al agente a las herramientas y permisos mínimos requeridos y aplicando autorización de forma independiente en los sistemas posteriores;
requerir aprobación humana antes de acciones de alto impacto.

Leer más: Política de control de acceso: Cómo diseñar RBAC empresarial

En Passwork, construir el rol del agente alrededor de un único permiso llamado Use API, con gestión de usuarios, integración LDAP y administración SSO desactivados — el mismo modelo de acceso basado en API que los equipos DevOps ya usan para secretos. Otorgar acceso a bóvedas y carpetas por separado, en el nivel más restringido que la tarea requiera: solo lectura a menos que el trabajo del agente sea escribir, nivel de carpeta en lugar de nivel de bóveda cuando solo necesita un subconjunto.

Un bot de soporte que lee una credencial de helpdesk no tiene razón para compartir un rol con un agente de despliegue que toca credenciales de base de datos de producción, incluso si un rol compartido es más fácil de configurar. Si un agente se ve comprometido, esa decisión de delimitación separa un incidente de una credencial de uno que afecta a toda la flota.

Regla 3: Ajustar la vida útil del token a cuánto tiempo se ejecuta el agente

Un agente que se dispara una vez por tarea, para responder un ticket o revisar un pull request, se comporta como un trabajo corto de CI (integración continua). No se comporta como una persona iniciando sesión para el día, por lo que sus credenciales no deberían durar tanto como la sesión de una persona.

Passwork emite un par de tokens: un accessToken usado en cada solicitud API, y un refreshToken que solicita un nuevo par una vez que el token de acceso expira. Las vidas útiles recomendadas escalan con el trabajo:

Caso de uso	Token de acceso	Token de actualización
Agente basado en tareas (se dispara una vez por trabajo)	15-60 minutos	1 día
Agente siempre activo	1-4 horas	30 días
Script programado o activado manualmente	1 hora	7 días

Estos son los rangos recomendados por Passwork, no un estándar universal. Verifique la vida útil predeterminada del token de su plataforma antes de asumir que coincide con estos números. Los valores predeterminados generalmente se establecen por conveniencia, no para una tarea de agente de corta duración, por lo que acortarlos es un paso deliberado que usted toma, no uno que hereda.

En Passwork 7.6.0 y versiones posteriores, puede rotar el par completo de tokens, solo el token de acceso, o solo el token de actualización. Rotar el par completo invalida ambos tokens anteriores. Rotar solo el token de actualización invalida el token de actualización anterior pero deja el token de acceso actual válido hasta que expire por sí solo. Construya sus pruebas de revocación alrededor del modo que utilice. Almacene los tokens de actualización como secretos de alto valor y larga duración, usando un almacén de secretos seguro o almacenamiento seguro proporcionado por la plataforma; RFC 9700 proporciona principios de protección útiles, aunque Passwork documenta estos como tokens de sesión API en lugar de tokens OAuth.

Regla 4: Mantener las credenciales fuera de repositorios y archivos de configuración MCP

Las credenciales de agentes a menudo se filtran desde archivos de texto plano ubicados en el propio directorio de trabajo del agente. El informe State of Secrets Sprawl 2026 de GitGuardian encontró 24.008 secretos únicos expuestos en archivos de configuración MCP (Model Context Protocol) en GitHub público durante 2025. Los escáneres de GitGuardian confirmaron que 2.117 de ellos aún funcionaban en el momento de la detección. En todo GitHub público, 28,6 millones de secretos codificados aparecieron en commits durante 2025, un aumento del 34% respecto a 2024. Los secretos vinculados a servicios de IA crecieron un 81% hasta superar 1,27 millones, incluyendo más de 113.000 claves API de DeepSeek filtradas.

MCP es un estándar de código abierto que permite a las aplicaciones de IA conectarse a herramientas externas y fuentes de datos. La investigación de Trend Micro sobre configuraciones de servidores MCP encontró que aproximadamente el 48% de los servidores que revisó recomiendan pasar credenciales a través de un archivo .env. Codificar en un archivo de configuración JSON de texto plano es la alternativa común. Ambos enfoques ponen varios secretos en un archivo que el propio proceso del agente puede abrir.

Referenciar el nombre de la variable en la configuración, y obtener el valor real desde una plataforma de secretos al inicio del proceso en lugar de desde un archivo que el agente puede leer directamente:

{
  "mcpServers": {
    "internal-api": {
      "command": "node",
      "args": ["./server.js"],
      "env": { "API_TOKEN": "${API_TOKEN}" }
    }
  }
}

Esto soluciona el problema del archivo estático pero no decide quién obtiene el valor real o a dónde va ese valor una vez obtenido. La Regla 5 cubre esa parte.

Regla 5: Enrutar cada credencial a través de una capa de ejecución de herramientas aislada

Eliminar un secreto de un repositorio o archivo de configuración MCP importa, pero no es la solución completa si ese valor luego llega directamente al tiempo de ejecución del propio agente. Un desarrollador sabe que no debe pegar una clave API en una ventana de chat. Un agente no tiene un instinto equivalente. Una vez que un secreto entra en una respuesta de herramienta, una línea de depuración, o una traza de razonamiento que el modelo produce, puede reaparecer en cualquier lugar donde ese texto se registre, almacene en caché o reproduzca.

El enfoque más seguro es mantener los secretos en la capa de ejecución de herramientas, implementada aquí como un intermediario de credenciales o servicio de ejecución de herramientas, donde el modelo no puede verlos. El agente solicita a una herramienta dedicada que realice una tarea específica, como verificar el estado del despliegue u obtener un registro. La herramienta usa el secreto para completar la tarea y devuelve solo el resultado al agente.

Para proporcionar secretos cuando un proceso se inicia, sin almacenarlos en archivos de texto plano como mcp.json o .env, usar passwork-cli exec.

passwork-cli exec --folder-id "$PROD_SECRETS_FOLDER_ID" – ./start-agent.sh

La utilidad passwork-cli exec carga secretos en un proceso hijo solo mientras ese proceso está en ejecución. No los escribe en disco ni los incluye en la salida del comando. El principio clave es mantener las credenciales a nivel de herramienta, donde permanecen fuera del contexto del modelo y cualquier texto que el LLM pueda leer.

Mantener el secreto fuera del contexto del modelo cierra una ruta de divulgación. Un agente con inyección de prompt aún puede solicitar al intermediario que realice una operación para la que técnicamente está autorizado, solo en el momento equivocado o en el registro equivocado. El intermediario necesita sus propias verificaciones de política frente al almacén de secretos, y la Regla 6 cubre lo que sucede cuando una inyección aún llega tan lejos.

Esto también limita el daño del acceso al sistema de archivos por sí solo. Un proceso de agente que puede leer un archivo .env extrae la credencial directamente a su memoria de trabajo, y ningún permiso de archivo lo detiene una vez que es el propio agente quien hace la lectura. Enrutar a través de un intermediario que el agente puede llamar pero no inspeccionar refuerza el límite que la Regla 4 inicia.

Explore el modelo de control de acceso de Passwork para ver cómo los permisos granulares de bóvedas y carpetas limitan lo que un agente comprometido puede alcanzar.

Regla 6: Tratar el filtrado de salida como un respaldo, no como su defensa principal

El 15 de abril de 2026, el investigador Aonan Guan y los investigadores de Johns Hopkins Zhengyu Liu y Gavin Zhong publicaron Comment and Control: tres demostraciones de prueba de concepto contra Claude Code Security Review, Gemini CLI Action y GitHub Copilot Agent. Cada una usó una superficie de inyección diferente — un título de pull request, un comentario de issue, un comentario HTML oculto — para exponer secretos del runner como ANTHROPIC_API_KEY y GITHUB_TOKEN.

Anthropic calificó su propio hallazgo con 9.4 CVSS, por encima del umbral crítico. Ninguno de los tres proveedores asignó un CVE ni publicó un aviso de seguridad. No confíe en un feed de CVE para detectar el próximo: no devolvió nada para una filtración de credenciales crítica, confirmada y ejecutable remotamente en tres agentes ampliamente desplegados.

El caso de Copilot Agent muestra por qué el filtrado solo no es suficiente. El informe de Guan describe tres defensas frente a Copilot Agent: filtrado de variables, escaneo de secretos basado en diff y una lista de permitidos de red. La cadena demostrada eludió las tres, leyendo secretos a través de una ruta que el filtro no detectó, codificando valores para pasar el escáner, y exfiltrando a través de un endpoint de GitHub que la lista de permitidos ya permitía.

CamoLeak, una vulnerabilidad anterior de Copilot Chat, muestra que este riesgo no se limita a runners de agentes o secretos de CI. El investigador Omer Mayraz lo encontró en Copilot Chat en junio de 2025 y publicó detalles el 8 de octubre de 2025: contenido oculto de pull request hizo que Chat codificara datos de repositorios privados en solicitudes de imágenes enrutadas a través del proxy Camo de GitHub. Mayraz lo calificó con CVSS 9.6. GitHub mitigó el problema, registrado como CVE-2025-59145, para el 14 de agosto de 2025.

Los filtros de salida, el escaneo y las listas de permitidos de egreso reducen la probabilidad de que una filtración tenga éxito, pero ninguno de ellos puede autorizar o bloquear una solicitud de herramienta por sí solo. Trátelos como respaldos. Combínelos con autorización independiente en sistemas posteriores, validación de argumentos, herramientas estrechas de propósito único y aprobación humana para acciones de alto impacto.

Regla 7: Registrar cada acción y mantener la revocación aislada a una identidad

El registro de actividad de Passwork registra eventos en CEF (Common Event Format), adecuado para reenviar a un SIEM (plataforma de gestión de información y eventos de seguridad) a través de syslog. Los campos documentados incluyen el código del evento (por ejemplo, item_created), una calificación de severidad, una descripción, el ID e inicio de sesión del usuario actuante, y la IP del cliente. La documentación de reenvío de eventos de Passwork cubre la lista completa de campos tanto para syslog de Linux como para el Visor de eventos de Windows.

Una cuenta de servicio dedicada atribuye cada operación registrada a una única identidad de automatización. Esa es una pieza confiable del panorama en un mal día. Reconstruir lo que realmente hizo una ejecución específica de agente aún significa correlacionar sus registros de intermediario, registros de servicios posteriores y registros de egreso en la misma ventana de tiempo.

El valor se muestra independientemente. Cuando un agente hace algo que nadie planeó, ya sea que siguió una instrucción inyectada o malinterpretó una tarea, una cuenta de servicio por agente le indica qué identidad, qué sesión y qué secretos tocó, sin cruzar referencias de un token compartido contra marcas de tiempo. La revocación también permanece aislada: desactivar los tokens de esa única cuenta, y todos los demás agentes siguen funcionando. Ese es un argumento más fuerte para cuentas separadas que cualquier panel de control.

Construyendo controles de credenciales de agentes con Passwork

Passwork proporciona los controles centrales para gestionar el acceso de agentes. Para agentes de IA, estos controles pueden organizarse en cinco áreas:

Dar a cada función de agente una cuenta de servicio dedicada. Las cuentas separadas mantienen el acceso del agente aislado y la actividad atribuible.
Aplicar mínimo privilegio a través de roles y ACLs granulares. Limitar cada cuenta a las bóvedas, carpetas y operaciones requeridas para su tarea. Las plantillas estandarizadas de roles y ACL pueden simplificar el aprovisionamiento a escala.
Tratar la rotación de credenciales como un flujo de trabajo de extremo a extremo. Reemplazar la credencial en el sistema de destino, actualizarla en Passwork, revocar la credencial antigua y verificar que el acceso antiguo ha terminado. GitGuardian encontró que más del 64% de las credenciales confirmadas como válidas en 2022 seguían siendo válidas en enero de 2026.
Usar credenciales dinámicas donde sea necesario. Las cargas de trabajo que necesitan credenciales de corta duración generadas bajo demanda pueden requerir un servicio de secretos dinámicos o arrendamiento de credenciales junto con la bóveda.
Conectar la actividad del agente a la pila de monitoreo más amplia. Verificar las capacidades de monitoreo de la edición y versión de Passwork en uso, y reenviar registros de actividad a un SIEM donde se requiera correlación de eventos o alertas en tiempo casi real.

Lista de verificación de credenciales de agentes de IA

Recorrer esta comprobación de ocho puntos antes de que un agente toque una credencial real en producción.

Identidad dedicada. ¿Este agente tiene su propia cuenta de servicio o identidad de carga de trabajo, separada de todos los demás agentes y de todos los humanos?
Mínimo privilegio. ¿Ha limitado su rol, acceso a bóvedas o carpetas, y alcance de recursos a lo que la tarea realmente necesita?
Solo lectura por defecto. ¿Ha deshabilitado escritura, eliminación y comunicación externa a menos que la tarea específicamente lo requiera?
Ciclo de vida del token. ¿Ha ajustado la vida útil del token de acceso a la duración de una ejecución, con tokens de actualización protegidos y revocables?
Sin exposición estática. ¿Ha confirmado que la credencial está ausente de repositorios, archivos .env, configuración MCP, y cualquier otro archivo en el árbol de trabajo del agente?
Límite del intermediario. ¿Un intermediario separado y aislado mantiene el secreto mientras el agente orientado al modelo recibe solo un resultado minimizado?
Controles de seguridad probados. ¿Ha probado el manejo de salida, validación de argumentos y restricciones de egreso contra entrada adversaria, en lugar de asumir que funcionan?
Contención verificable. ¿Puede correlacionar registros de agente, intermediario y sistemas posteriores, y revocar la identidad afectada sin interrumpir ningún otro agente?

Qué significa esto para su equipo

Delimitar el rol de un agente a Use API y acceso mínimo a la bóveda es un cambio de configuración. La mayoría de las plataformas de secretos ya lo soportan. El trabajo de ingeniería está en la capa que lo rodea: un intermediario entre el agente y el almacén de secretos, filtrado de salida como respaldo contra filtraciones, y registros de auditoría que le permitan revocar una identidad sin tocar el resto.

Comience con el agente que tiene el acceso más amplio en su entorno hoy, y reduzca su rol a lo que el trabajo requiere.

Las cuentas de servicio de Passwork, las listas de control de acceso granulares y el registro de actividad CEF le brindan los bloques de construcción para la gestión de credenciales de agentes. Pruebe Passwork en su entorno.

Preguntas frecuentes

¿Debería un agente de IA reutilizar nuestra cuenta de servicio de CI/CD existente?

No. El acceso del pipeline fue delimitado para el despliegue, y un agente haciendo algo diferente hereda permisos que nunca necesitó. Compartir una cuenta también fusiona dos actores en una identidad de auditoría, que es la distinción que necesitará durante un incidente. Dé a cada función, por entorno, su propia cuenta.

¿Qué vida útil de token debería tener una credencial de agente?

Ajustarla a cómo se ejecuta el agente. Los agentes que se disparan una vez por tarea encajan en la misma ventana de token de acceso de 15 a 60 minutos que Passwork recomienda para trabajos cortos de CI. Los agentes siempre activos pueden justificar de 1 a 4 horas. Cualquier cosa más larga es una credencial permanente con etiqueta de corta duración.

¿Podemos mantener el token de la bóveda en el archivo de configuración MCP?

Esa es exactamente la clase de archivo donde GitGuardian encontró 24.008 secretos expuestos en GitHub público en 2025. Referenciar el nombre de la variable en el archivo de configuración, mantener el valor real fuera de él, y obtener el valor al inicio del proceso a través de un intermediario de credenciales, usando una herramienta como passwork-cli exec.

¿Una bóveda de contraseñas previene la inyección de prompts?

No. Un proveedor que afirme lo contrario está exagerando. Se mitiga la inyección de prompts a nivel de arquitectura del agente: herramientas estrechas, un límite entre instrucciones y contenido ingerido, autorización independiente en el sistema posterior, y aprobación humana en acciones de alto impacto. Una bóveda limita hasta dónde puede llegar una inyección exitosa, y le indica después exactamente qué credenciales fueron tocadas.

¿Cuántos agentes de IA ejecuta ya una empresa típica?

Una encuesta de Palo Alto Networks de 2026 a 2.930 responsables de ciberseguridad encontró un promedio de 109 identidades de máquina por identidad humana, incluyendo 79 identidades de agentes de IA por humano, en las organizaciones encuestadas. Ese es un promedio de encuesta, no una garantía de que cada empresa individualmente tenga más agentes que empleados, pero es una señal razonable de que la identidad de agentes ha superado la gestión ad hoc en la mayoría de los entornos.

¿Los incidentes de GitHub Copilot y CamoLeak significan que estos agentes no son seguros de usar?

No. Ambos fueron hallazgos de prueba de concepto divulgados por investigadores, y los proveedores involucrados respondieron a ellos. Muestran que el filtrado y escaneo son solo parte de la defensa: las cadenas de inyección pueden eludirlos o usar rutas de exfiltración separadas. Por eso el límite del intermediario en la Regla 5 importa independientemente del agente de qué proveedor ejecute.

Credenciales de agentes IA: 7 reglas para un control de acceso seguro