Identidad del agente frente a identidad de la credencial: deja de ocultar a los actores

Un agente de IA que contiene una credencial de producción crea dos problemas de identidad a la vez. El agente puede actuar como la cuenta y, más tarde, el equipo tiene que fingir que el nombre de la cuenta explica quién actuó. No lo hace. Una solicitud de API autenticada como deploy-bot demuestra que alguien poseía la credencial de deploy-bot. No indica si quien llamó era el agente de programación aprobado, un script de shell copiado, una dependencia maliciosa o un proceso que siguió ejecutándose después de una prueba.

Los equipos deben identificar por separado el proceso que solicitó una acción y la cuenta autorizada para llevarla a cabo. Esto no es un detalle de presentación del registro de auditoría. Determina si puedes aprobar una ejecución concreta del agente, detenerla sin interrumpir el trabajo ajeno, investigar un despliegue incorrecto y contener una credencial filtrada sin tener que adivinar.

Una credencial identifica la autoridad, no a quien llama

Una credencial identifica la autoridad que un servicio concederá, mientras que la identidad del agente identifica el proceso que solicitó esa autoridad. Mezclarlas hace que todas las decisiones de seguridad posteriores sean demasiado generales.

Imagina una solicitud que elimina un objeto del almacenamiento en la nube. La API receptora puede ver un token bearer y asociarlo a una cuenta de servicio llamada release-publisher. Esa cuenta responde a una pregunta de autorización: ¿puede esta cuenta eliminar este objeto? No responde a una pregunta de atribución: ¿qué proceso local usó el token, quién lo inició, qué código ejecutó y alguien aprobó esa ejecución?

Estas preguntas parecen similares en periodos tranquilos porque el proceso esperado y la cuenta suelen tener el mismo responsable. Bajo presión, se separan. Un desarrollador copia el token en un entorno local. Un agente de programación hereda ese entorno. Un complemento iniciado por el agente lo lee. Todas las solicitudes siguen apareciendo como release-publisher. La capa de autorización funciona exactamente como se configuró, mientras la investigación pierde al actor.

La identidad de una credencial suele tener una vida larga y un propósito amplio. Puede ser un token de API, una credencial privada SSH, una cuenta de servicio en la nube o el sujeto de un certificado de cliente. La identidad del proceso debe describir algo mucho más concreto: este ejecutable, de este firmante o imagen, iniciado en este contexto durante esta ejecución.

La distinción tiene una consecuencia práctica:

• Revoca una sesión de proceso cuando una ejecución del agente deja de ser confiable.
• Deshabilita o rota una credencial cuando su secreto puede haberse escapado.
• Cambia los permisos de la cuenta cuando la autoridad en sí era excesiva.
• Investiga el registro del proceso cuando necesitas saber qué ocurrió realmente.

Si un solo campo tiene que cumplir las cuatro funciones, no hará bien ninguna. Llamar a una credencial agent-prod-42 no resuelve el problema. Una etiqueta mejor no convierte un token bearer en pruebas sobre quien lo porta.

En una solicitud de un agente aparecen cuatro identidades

Una acción de producción suele tener al menos cuatro identidades, y un registro de auditoría debería conservarlas todas en lugar de reducirlas al nombre de una cuenta.

Primero está la persona o el sistema responsable que inició el trabajo. Puede ser un desarrollador en un terminal, el activador de un trabajo de CI o una tarea programada. La propiedad responde a quién solicitó que se ejecutara el agente y quién debería recibir las alertas.

Segundo está el proceso del agente. Para un agente de programación local, las pruebas útiles pueden incluir su ruta de ejecutable, la autoridad de firma, el identificador del proceso, el proceso padre, la hora de inicio y un identificador aleatorio de sesión emitido al iniciar. En un entorno de contenedores, las pruebas equivalentes pueden incluir el resumen de una imagen, un documento de identidad de la carga de trabajo, el nombre de la carga de trabajo del orquestador y la instancia del pod o de la tarea. Esta identidad responde a qué programa en ejecución solicitó realizar una acción.

Tercero está la identidad de la credencial. Es la cuenta de servicio, entidad SSH, cliente OAuth o registro del token de API que acepta el destino. Responde a qué permitirá el destino.

Cuarto está la identidad del objetivo: el nombre de host, repositorio, proyecto en la nube, base de datos o audiencia de la API afectada por la solicitud. Los equipos suelen registrar un endpoint genérico y luego descubren que la acción cruzó un límite de entorno que nunca pretendieron conceder.

Un registro claro puede verse así:

{
  "event": "http.request",
  "session_id": "ses_7zQ2...",
  "process": {
    "pid": 8421,
    "signing_authority": "Example Developer ID",
    "parent_pid": 8190,
    "launch": "interactive-terminal"
  },
  "credential_ref": "cred_release_publisher",
  "credential_subject": "release-publisher",
  "target": "api.example.internal",
  "operation": "POST /releases",
  "decision": "approved",
  "result": 201
}

credential_ref apunta a un registro de la bóveda. No es el secreto. El bloque del proceso aporta las pruebas que el sujeto de la credencial no puede aportar. Ahora un revisor puede ver que una sesión aprobada usó release-publisher contra un objetivo concreto y distinguir esa ejecución de otra posterior que utilizó la misma cuenta desde otro proceso.

Tampoco sobrecargues el campo del responsable humano. La persona que pidió a un agente actualizar la documentación no es automáticamente la persona que aprobó un despliegue de producción que el agente intentó realizar después. Mantén separados el inicio, el proceso, la credencial y el destino. Las lagunas incómodas se vuelven visibles, y ese es el objetivo.

Los tokens bearer borran las pruebas que más necesitas

Un token bearer se acepta porque quien llama lo posee, así que no puede establecer qué proceso lo está presentando. Es una propiedad del mecanismo, no un defecto del registro de tu proveedor de API.

RFC 6750 define directamente el uso de tokens bearer: cualquier parte que posea el token puede utilizarlo. Esa portabilidad hizo que los tokens bearer fueran fáciles de desplegar, pero también significa que una API no puede distinguir al agente aprobado de un proceso copiado si no añades otro control. La respuesta habitual, «ponemos el token en un gestor de secretos», resuelve el almacenamiento en reposo. No resuelve lo que ocurre después de que un proceso recibe el valor.

OAuth 2.0 Security Best Current Practice, RFC 9700, avanza en la dirección correcta al recomendar, cuando corresponda, tokens de acceso vinculados al emisor, además de una duración corta y una audiencia restringida. Vincular el token al emisor puede reducir la reutilización porque el servidor de recursos comprueba una prueba del cliente previsto. No elimina la necesidad de identificar el proceso que controla esa prueba del cliente. Si un proceso de agente puede usar el material privado de la prueba, un atacante que controle ese proceso todavía puede actuar como el cliente.

Esta distinción importa especialmente en los agentes de IA porque su entorno de operación suele tener muchos puntos de entrada. Leen repositorios, ejecutan comandos, llaman a herramientas, inspeccionan variables de entorno y a veces actúan siguiendo instrucciones suministradas en archivos o comentarios de incidencias. Un token expuesto al agente no permanece dentro de un límite de confianza limpio solo porque el equipo lo destinara a una llamada de herramienta concreta.

Evita la recomendación popular de dar a cada agente un token propio de larga duración y considerar el problema resuelto. Es popular porque produce nombres de cuentas ordenados y paneles sencillos. Falla cuando el agente puede leer el token, cuando otro proceso puede leer el mismo entorno o cuando la cuenta permanece activa después de que termina la ejecución del agente. Las credenciales específicas mejoran el cálculo del alcance del impacto, pero no demuestran la procedencia del proceso.

Necesitas dos controles: impedir que el agente reciba material secreto reutilizable y conservar un registro separado del proceso del agente que solicitó cada acción. El primero limita el robo. El segundo hace que la aprobación, la revocación y la investigación sean lo bastante específicas para resultar útiles.

La identidad del proceso necesita pruebas que sobrevivan a un prompt

La identidad de un proceso debe proceder de hechos que el sistema operativo o el entorno de ejecución puedan informar, no de una cadena que el agente proporcione en una solicitud de herramienta. Si un agente declara name: trusted-release-agent, ha hecho una afirmación, no ha presentado pruebas de identidad.

En un Mac administrado, la autoridad de firma del código ofrece un punto de partida útil. El sistema operativo puede indicar a una aplicación supervisora qué ejecutable firmado se inició y qué autoridad lo firmó. Esto no significa que todo programa firmado merezca aprobación. Significa que una pantalla de aprobación puede mostrar un hecho más difícil de falsificar que una etiqueta proporcionada por el proceso.

En un servidor, busca pruebas equivalentes. Una identidad de carga de trabajo emitida por el entorno de ejecución, un resumen de imagen verificado, un canal con autenticación mutua o la atestación de un supervisor de procesos pueden vincular una acción a una instancia de carga de trabajo. SPIFFE documenta este modelo con SPIFFE Verifiable Identity Document y X.509 SVIDs: la carga de trabajo recibe una identidad de su entorno y después se la presenta a otra carga de trabajo. Este modelo es más sólido que una variable de entorno compartida porque la identidad está limitada a una carga de trabajo.

No confundas un resumen de imagen estático con una identidad de proceso completa. Identifica el contenido del código, pero una decisión útil sobre una acción también necesita la instancia en ejecución y el contexto de inicio. La misma imagen puede ejecutarse en el trabajo de producción previsto, en el entorno experimental de un desarrollador o en una tarea controlada por un atacante. El destino y la sesión siguen formando parte de la decisión.

Para el trabajo local con agentes, recopila las pruebas al crear la sesión y vincula las acciones posteriores a esa sesión. Un registro mínimo de sesión podría incluir:

session_id: ses_7zQ2...
executable: /Applications/Agent.app/Contents/MacOS/agent
signing_authority: Example Developer ID
parent_process: /Applications/Terminal.app
started_at: 2025-03-08T14:03:19Z
owner: [email protected]

Los campos exactos varían según el sistema operativo. La disciplina no: el componente que autoriza una acción debe recopilar por sí mismo los datos del proceso. No debe confiar en que el agente se describa con precisión después de haber recibido entradas que no son de confianza.

La identidad del proceso también tiene límites. La firma del código no demuestra que un agente firmado haya seguido instrucciones seguras. El resumen de una imagen no demuestra que su configuración sea segura. La identidad te indica qué actor aprobaste y te proporciona un mecanismo para revocarlo. Por sí sola no convierte en segura una acción solicitada que sea arriesgada.

La aprobación debe vincularse a una ejecución, no al nombre de una cuenta

Una aprobación humana debería autorizar una sesión concreta de proceso durante un periodo limitado, no bendecir para siempre a cualquier proceso que use una cuenta más adelante. De lo contrario, la aprobación se convierte en una concesión encubierta de acceso permanente.

La fatiga de aprobación suele empezar con una unidad de aprobación equivocada. Los equipos piden a una persona que apruebe cada solicitud inofensiva, lo que la acostumbra a hacer clic sin leer, o aprueban una cuenta de servicio una vez y dejan de mostrar avisos significativos. Ninguna de las dos opciones identifica el proceso activo.

Usa una aprobación de sesión cuando un agente comience una ejecución. Muestra las pruebas del proceso que un operador puede evaluar: ejecutable o nombre de la carga de trabajo, autoridad de firma o resumen de imagen, proceso padre o lanzador, canales previstos y un identificador de sesión. Una vez aprobada, permite acciones a través de esa sesión hasta que el proceso termine o el operador la revoque. Un proceso nuevo debe solicitar una sesión nueva, aunque pretenda usar la misma credencial.

Reserva la aprobación por acción para las credenciales cuyo impacto justifique una interrupción. Una credencial de administrador de una base de datos de producción, una identidad SSH con acceso a los hosts de una flota o una cuenta que pueda publicar artefactos públicos pueden necesitar una decisión humana cada vez. El acceso de lectura habitual no. El mecanismo de aprobación debe hacer explícita esa diferencia, en lugar de ocultarla en un archivo de políticas enorme que nadie revisa.

Esta estructura te da opciones de contención que el acceso compartido no puede ofrecer. Si un agente empieza a comportarse mal, revoca su sesión. La credencial sigue disponible para otro proceso de publicación aprobado. Si sospechas que un secreto se ha expuesto, deshabilita también la credencial e inspecciona todas las sesiones que la hayan utilizado.

Sallyport aplica directamente esta separación: un proceso nuevo de agente recibe por defecto una autorización por sesión, mientras las credenciales permanecen en su bóveda cifrada y las acciones se ejecutan fuera del proceso del agente. Su aviso de sesión muestra primero la autoridad de firma del código del proceso, que es la prueba que necesita un aprobador antes de permitir una ejecución.

El registro de aprobación debe incluir tanto la sesión del proceso como la referencia de la credencial utilizada después. No muestres el valor de la credencial en el aviso ni lo devuelvas en el resultado de una acción. Un sistema que oculta un token en la interfaz, pero lo incluye en la respuesta de una herramienta del agente, sigue habiendo entregado el token al agente.

La inyección de credenciales mantiene los secretos fuera del alcance del agente

El agente debe solicitar una acción indicando una referencia de credencial y un objetivo, mientras un ejecutor de confianza inyecta el secreto justo cuando realiza la llamada HTTP o SSH. El agente recibe el resultado, no la credencial reutilizable.

Este límite es mucho más claro que poner un token en el entorno de shell y pedir al agente que no lo imprima. Las variables de entorno se filtran a los procesos secundarios, la salida de depuración, los informes de errores, los envoltorios del historial de comandos y las llamadas a herramientas. La ocultación ayuda a evitar que se muestre accidentalmente después, pero no puede recuperar un secreto que un proceso ya ha leído.

Una solicitud de acción segura contiene suficientes detalles para autorizar y ejecutar la llamada sin incluir la credencial:

{
  "session_id": "ses_7zQ2...",
  "credential_ref": "cred_release_publisher",
  "channel": "http",
  "request": {
    "method": "POST",
    "url": "https://api.example.internal/releases",
    "headers": {"Content-Type": "application/json"},
    "body": {"version": "1.4.2"}
  }
}

El ejecutor comprueba que la sesión siga aprobada, confirma que la bóveda esté disponible, obtiene cred_release_publisher, lo inyecta en el encabezado de autorización requerido, realiza la solicitud y registra la decisión y el resultado. Debe devolver los datos de respuesta que el agente necesite para su tarea, después de aplicar el tratamiento habitual que corresponda al contenido sensible de la respuesta.

El mismo principio se aplica a SSH. El agente puede solicitar git fetch o un comando remoto a través de un canal SSH, pero no debe recibir la credencial privada como un bloque PEM ni un socket de agente que cualquier proceso secundario pueda usar sin supervisión. El ejecutor puede utilizar la credencial privada para la conexión y vincular el evento a la sesión del agente.

Sallyport admite actualmente la inyección de credenciales HTTP y acciones SSH mediante su helper incluido, de modo que un agente compatible con MCP puede solicitar el trabajo sin tener el secreto de API o SSH. Este diseño no hace segura cualquier acción. Conserva la separación necesaria para decidir si el proceso debe tener permiso para solicitarla.

Un token de despliegue compartido oculta el fallo hasta que importa

Una credencial compartida convierte un incidente sencillo en un ejercicio de reconstrucción porque el mismo nombre de cuenta aparece en todas las líneas de registro relevantes. El fallo suele comenzar con un atajo razonable.

Imagina un equipo que guarda PUBLISH_TOKEN en un almacén de secretos de CI. Su trabajo de despliegue lo lee, como es de esperar. Un desarrollador también lo exporta localmente para reproducir un problema de publicación. Más tarde inicia un agente de programación desde ese shell porque el agente necesita inspeccionar los scripts de despliegue. Ahora el agente puede llamar a la API de publicación a través de su entorno.

Una instrucción oculta en un archivo del repositorio indica al agente que ejecute un comando para subir una versión preliminar. El comando funciona. El registro de auditoría de la API dice release-publisher created release 1.4.2. El registro de CI no muestra ningún trabajo correspondiente. El desarrollador afirma que solo pidió al agente inspeccionar archivos. Todos pueden coincidir en esos hechos, pero ninguno identifica el proceso que realizó la llamada.

El equipo suele responder rotando PUBLISH_TOKEN. Eso detiene la reutilización si el token se filtró, pero también rompe el trabajo legítimo de CI y obliga a repararlo con prisa. Después, el equipo puede culpar al desarrollador, al agente o a la instrucción del repositorio sin pruebas. El nombre de la cuenta no les permite distinguir una invocación de CI de una acción de un agente local.

Ahora cambia el diseño. La credencial de publicación permanece en una bóveda controlada por un ejecutor de acciones. El agente inicia una sesión que registra su autoridad de firma y el terminal padre. Solicita la acción de subida a través de esa sesión. El ejecutor registra la decisión de aprobación, la referencia de la credencial, la API de destino, la ruta de la solicitud y el estado de la respuesta.

Cuando se produce la subida sospechosa, el registro del incidente responde de inmediato a las primeras preguntas útiles: procedió de una sesión local del agente, esa sesión comenzó desde un terminal concreto, recibió autorización a una hora específica y utilizó la credencial de publicación para una solicitud POST. El operador revoca esa sesión. CI continúa porque su proceso, identificado por separado, no ha sido revocado. Si la instrucción del repositorio pudo haber expuesto secretos más amplios, el equipo todavía puede rotar la credencial, pero lo hará porque las pruebas lo justifican y no porque carezca de cualquier otro control.

La diferencia no es una prevención perfecta. Un agente aprobado todavía puede solicitar una acción que una persona lamente haber aprobado después. La diferencia es que el sistema conserva un actor, una decisión de autorización y un mecanismo de detención específico. Eso basta para acortar un incidente en lugar de convertirlo en una discusión.

Los registros de auditoría deben relacionar identidades sin almacenar secretos

Un registro de auditoría debe permitir conectar una sesión de proceso, una referencia de credencial y una acción externa, manteniendo el material secreto fuera del registro. Si esos datos viven en productos separados sin un identificador común de evento, la respuesta a incidentes se convierte en una correlación manual bajo presión.

Escribe un evento para la decisión de la sesión y otro para cada acción. Asigna a ambos el mismo session_id y asigna a cada acción su propio identificador de evento. Guarda una referencia de credencial y el sujeto de la credencial si es seguro conservarlo, pero nunca guardes el token bearer, la credencial privada ni el encabezado de autorización sin procesar.

Un registro de acción útil incluye el objetivo normalizado, el método o comando remoto, un resumen de la solicitud cuando los cuerpos puedan contener datos sensibles, la decisión, el estado de la respuesta y las marcas de tiempo. Para SSH, registra el host, el usuario remoto, el comando solicitado y el resultado de salida. Para HTTP, registra el método, el host, la ruta y el estado. Conserva el cuerpo sin procesar solo cuando lo permitan tus reglas de retención y tratamiento de datos.

Las pruebas contra manipulaciones importan porque el proceso que realiza una acción podría ser acusado más tarde de ocultarla. Una cadena de hashes permite detectar la eliminación o reordenación cuando el investigador tiene la secuencia completa. No hace que un evento sea verdadero. Si tu recopilador acepta el nombre del proceso proporcionado por un agente, un registro perfectamente encadenado conservará esa afirmación falsa para siempre. Recopila primero las pruebas de identidad en el límite supervisor y protege después el registro.

Un proceso de verificación sencillo debe funcionar independientemente del contenido de la bóveda. El verificador lee cada bloque de evento cifrado, comprueba que el hash anterior almacenado coincide con el hash del evento previo, vuelve a calcular el hash actual e informa de la primera posición rota. La salida debe identificar la posición en la secuencia sin exponer secretos:

$ audit verify events.log
verified: 184 events
chain: valid
first_event: evt_01J...
last_event: evt_01K...

Si la verificación falla, conserva los archivos originales antes de intentar repararlos. Un registro ausente puede indicar corrupción, una escritura interrumpida, un problema al exportar o una alteración deliberada. La cadena identifica la inconsistencia; tus registros adicionales y controles de almacenamiento explican la causa.

Separa las identidades antes de añadir más automatización

Los equipos pueden adoptar este modelo sin reconstruir todas las integraciones de API. Empieza por las credenciales que pueden modificar el estado de producción, publicar artefactos, acceder a datos de clientes o conectarse mediante SSH. Son las cuentas que provocan los incidentes más difíciles cuando un proceso de agente las hereda.

Haz una primera revisión concreta:

1. Enumera cada sujeto de credencial, los servicios a los que puede llegar y todos los procesos que reciben actualmente su secreto.
2. Elimina los valores de secretos reutilizables de los prompts de los agentes, de su configuración y de sus entornos de proceso.
3. Define qué pruebas del proceso puedes recopilar en el punto donde se autorizan las acciones.
4. Emite un identificador de sesión para cada ejecución del agente y regístralo junto a la referencia de la credencial de cada acción.
5. Prueba la contención revocando una sesión mientras otra carga de trabajo aprobada continúa usando la misma cuenta.

La última prueba revela rápidamente el error habitual. Si solo puedes detener un agente deshabilitando la cuenta compartida, no has separado la identidad del agente de la identidad de la credencial. Has asignado un nombre amable a un riesgo compartido.

No empieces con un motor de reglas enorme. La mayoría de los equipos necesitan unas pocas decisiones claras: ¿está disponible la bóveda?, ¿esta sesión de proceso está aprobada? y ¿esta credencial requiere aprobación para esta acción? La parte más compleja es la disciplina operativa: deja de enviar secretos a los procesos de los agentes, recopila pruebas fiables del proceso y no trates el nombre de una cuenta de servicio como si fuera una persona o un programa.

Cuando aparezca la próxima acción cuestionable, exige una respuesta a dos preguntas separadas: ¿qué proceso la solicitó y qué autoridad la ejecutó? Si tus registros no pueden responder a ambas, corrígelo antes de conceder a otro agente acceso a producción.