Identidad y autenticación de agentes de IA para MVPs

Un agente de IA puede llamar a APIs, leer documentos, enviar mensajes o actualizar registros en nombre de un usuario. Si cada acción utiliza una clave de servicio compartida o las credenciales completas del usuario, el sistema no puede responder de forma fiable preguntas básicas: ¿Qué agente actuó? ¿Quién delegó la autoridad? ¿Qué tenía permitido hacer? ¿Se puede revocar esa autoridad sin interrumpir a todos los demás?

La identidad del agente es la base para responder esas preguntas. Debe diseñarse como seguridad de cargas de trabajo, no como una personalidad, un nombre visible o una instrucción del prompt.

Separa las identidades involucradas

Como mínimo, distingue al principal humano o del sistema, la carga de trabajo del agente y la herramienta o el recurso al que se accede. Conserva su relación en cada solicitud sensible.

Un usuario puede autorizar a un agente de revisión de gastos a leer facturas de una organización. La identidad del agente demuestra qué carga de trabajo realizó la llamada; el contexto delegado identifica al usuario y al tenant; la política de autorización limita los registros y acciones permitidos. La herramienta sigue autenticándose ante el agente o la pasarela.

Este modelo coincide con el trabajo conceptual de NIST de 2026 sobre identidad de agentes de software y de IA, que destaca la identificación, autenticación, autorización, delegación, auditoría y los problemas de inyección de prompts.

Trata la autenticación y la autorización por separado

La autenticación responde «¿quién o qué es esto?». La autorización responde «¿puede realizar esta acción ahora?». Una credencial válida de agente no debe implicar un acceso amplio.

Usa credenciales de carga de trabajo de corta duración y mantén los secretos fuera del prompt y del contexto de conversación del modelo. Evalúa la política en una pasarela de herramientas confiable o en el límite del servicio. Delimita las concesiones por tenant, recurso, acción, propósito y duración cuando sea práctico.

Control	Implementación para un MVP
Identidad	Identificador único del agente o de la carga de trabajo
Autenticación	Credencial firmada de corta duración o identidad de carga de trabajo consolidada
Delegación	Contexto del usuario y tenant con alcance explícito
Autorización	Decisión de permitir, denegar o retener aplicada en el servidor
Revocación	Deshabilitar el agente, la credencial o la concesión de forma independiente
Auditoría	Registrar actor, principal, herramienta, decisión, resultado y hora

Instrucciones del prompt como «nunca borres datos» son una guía de comportamiento útil, pero no constituyen un límite de control de acceso. La salida de un modelo comprometido o equivocado debe pasar por una comprobación de políticas independiente.

Aplica el mínimo privilegio a las herramientas

No entregues a un agente una clave API universal. Crea capacidades limitadas: leer registros aprobados, redactar un mensaje o enviar un cambio propuesto. Separa «preparar» de «ejecutar» cuando las consecuencias sean importantes.

Valida los argumentos de las herramientas contra un esquema y aplica los límites del tenant desde el contexto autenticado, no desde los IDs proporcionados por el modelo. Añade límites de frecuencia, gasto y volumen. Exige aprobación humana para acciones irreversibles, financieras, visibles externamente o inusualmente amplias.

La guía de protecciones para agentes de IA muestra cómo funcionan los permisos junto con la validación de entradas y la revisión humana.

Conserva la delegación y la responsabilidad

Cuando un agente actúa por una persona, el registro posterior no debe fusionar ambas identidades en una sola. Registra el principal responsable, la versión del agente, la concesión activa, la herramienta solicitada, la decisión de la política y el resultado. Evita registrar contenido sensible del prompt salvo que sea necesario y esté protegido.

La delegación debe reducir, no ampliar, la autoridad. Un subagente no puede heredar de forma segura todos los permisos de quien lo invoca. Pasa únicamente la capacidad necesaria para la subtarea, con una caducidad breve y una solicitud principal trazable.

El trabajo emergente del IETF describe a los agentes de IA como cargas de trabajo que pueden utilizar estándares de identidad consolidados mientras conservan el contexto delegado del usuario. Estos documentos aún son borradores, así que no presentes protocolos experimentales como estándares definitivos. Basa el sistema en primitivas maduras y mantén reemplazable la capa de identidad.

Decide si necesitas un registro o blockchain

Un registro puede ayudar a las organizaciones a descubrir claves, propietarios, estado y metadatos de los agentes. Un registro basado en blockchain o descentralizado puede ser relevante para partes que no comparten una autoridad de identidad, pero introduce preguntas sobre privacidad, revocación, gobernanza e integración.

La mayoría de los productos iniciales operan dentro de una organización o con un pequeño número de socios conocidos. Un proveedor de identidad convencional, credenciales de carga de trabajo, tokens firmados y un servicio de políticas suelen ser más sencillos. Añade verificación entre organizaciones solo cuando una interacción real lo exija.

Prueba los fallos de identidad antes del lanzamiento

Ensaya una credencial caducada, un agente revocado, un tenant incorrecto, una solicitud repetida, un argumento alterado, un gasto excesivo y un servicio de aprobación no disponible. Confirma que el comportamiento predeterminado sea seguro y que los operadores puedan entender la denegación.

Prueba también la inyección indirecta de prompts. El contenido no confiable de una página o un documento no debe poder conceder acceso a herramientas ni cambiar políticas. Limita lo que el contenido recuperado puede influir y mantén las credenciales inaccesibles para el modelo. Revisa el modelado de amenazas para agentes de IA antes de ampliar el acceso a herramientas.

Un MVP no necesita un protocolo de identidad universal. Necesita actores diferenciados, autoridad delimitada y revocable, aplicación independiente y un registro de auditoría que permita investigar. Estos controles permiten al equipo añadir autonomía gradualmente sin perder responsabilidad.

Crea un inventario de identidades de agentes

Mantén un registro pequeño aunque solo sea un almacén interno de configuración. Para cada agente desplegado, registra su propietario, propósito, entorno, versión, herramientas permitidas, emisor de credenciales, autoridad máxima, política de aprobación y estado actual. Separa las identidades de desarrollo y producción para que un agente de prueba no pueda acceder a recursos de clientes.

Define los eventos del ciclo de vida. Provisiona la identidad mediante un proceso revisado, rota las credenciales automáticamente y deshabilita un agente cuando su propietario se marche, su flujo de trabajo se retire o aparezca un comportamiento sospechoso. La revocación debe surtir efecto en el punto de aplicación; cambiar un prompt o eliminar una entrada visible no es suficiente.

Revisa el acceso efectivo, no solo el acceso previsto. Los permisos de herramientas, los alcances delegados del usuario, las rutas de red, los tokens almacenados en caché y las concesiones a subagentes pueden combinarse y producir una autoridad más amplia. Comprueba si un usuario con pocos privilegios puede inducir a un agente a leer o modificar datos de otro tenant. Registra los intentos denegados para que los equipos de seguridad puedan distinguir los errores de política de los patrones de ataque.

Por último, haz visible la identidad para los operadores y usuarios cuando facilite una aprobación informada. Una pantalla de aprobación debe indicar qué agente propone qué acción, para quién, sobre qué recurso y con qué consecuencia. Ese contexto convierte un botón de confirmación genérico en una decisión de autorización significativa y reduce la probabilidad de que las personas aprueben acciones arriesgadas por hábito.

Mantén deliberadamente pequeña la primera arquitectura de identidad: un emisor, un límite de aplicación, credenciales de corta duración y un almacén de auditoría claro pueden bastar para un flujo acotado. La complejidad debe seguir las necesidades reales de federación o delegación. Incluso este diseño pequeño necesita pruebas para la desviación del reloj, la rotación de claves, los servicios de identidad no disponibles y las solicitudes duplicadas. Una denegación segura no debe corromper la tarea del usuario; conserva un borrador o pon en cola el trabajo seguro para que una interrupción de autenticación no presione a los operadores a eludir los controles.

Preguntas Frecuentes

¿Un agente de IA necesita su propia identidad?

Un agente que utiliza herramientas o accede a datos debe poder distinguirse del ser humano, la aplicación y los demás agentes involucrados. Esto permite aplicar permisos delimitados, revocar accesos y conservar registros de auditoría útiles.

¿La autenticación de agentes es lo mismo que la autorización?

No. La autenticación establece qué carga de trabajo está actuando; la autorización decide qué recurso puede utilizar y qué acción puede realizar dentro del contexto delegado actual. Ambas son necesarias.

¿Debería un MVP usar blockchain para la identidad de agentes?

Solo si la verificación entre organizaciones requiere realmente un registro descentralizado y las compensaciones están justificadas. La mayoría de los MVP deberían comenzar con una identidad de carga de trabajo consolidada, delegación al estilo OAuth, credenciales de corta duración y aplicación de políticas en el servidor.