Identidad Agéntica: Seguridad, Delegación y Arquitectura Zero-Trust

1. El Problema Fundamental: Las Tres Preguntas de Toda Petición Agéntica

Cuando conectamos por primera vez un agente de IA a servicios externos (como GitHub, Slack, Jira, bases de datos SQL o herramientas expuestas mediante el Protocolo MCP), el impulso inicial de casi todo equipo de ingeniería es idéntico: crear un usuario de servicio o bot ("agent-bot"), generar un Personal Access Token (PAT) con permisos amplios, guardarlo en una variable de entorno o en el prompt del sistema, y permitir que el LLM ejecute herramientas.

Este enfoque —el llamado antipatrón del Shared Bot Token— funciona en demos locales, pero colapsa catastróficamente en entornos de producción empresariales.

Como expone Alejandro Saucedo en su análisis sobre seguridad agéntica, para que una interacción sea segura, el plano de control debe ser capaz de responder con certeza criptográfica a tres preguntas independientes antes de autorizar cualquier llamada:

• 1. ¿Quién es el usuario? (Identidad del Resource Owner humano que delega la intención).
• 2. ¿Quién es el agente? (Identidad de la carga de trabajo que ejecuta el modelo, versión de código y pod).
• 3. ¿A qué deberían tener derecho ambos de forma combinada? (Intersección estricta de permisos bajo el principio de mínimo privilegio).

2. La Base de Estándares: Sobre Hombros de Gigantes

La seguridad en agentes de IA no requiere reinventar la criptografía desde cero. La industria cuenta con décadas de experiencia en sistemas distribuidos y protocolos de identidad respaldados por el IETF (Internet Engineering Task Force). La clave reside en combinar y extender estos estándares para acomodar la autonomía y el no-determinismo de los LLMs:

3. El Estándar IETF WIMSE AIMS (draft-ietf-wimse-aims-00)

En septiembre de 2026, un consorcio de ingenieros de Defakto Security, AWS, Zscaler, Ping Identity, OpenAI y Okta presentó formalmente ante el grupo de trabajo WIMSE (Workload Identity in Multi-System Environments) del IETF el borrador draft-ietf-wimse-aims-00: AI Identity Management System (AIMS).

AIMS establece un modelo formal y agnóstico de proveedor para gobernar las interacciones de los agentes de IA con modelos, herramientas y servicios externos.

El sistema AIMS se articula en torno a cinco componentes esenciales:

1. Identificador de Agente (Agent Identifier): Un identificador universal e inmutable asignado a cada agente en el sistema (por ejemplo, un SPIFFE ID con formato spiffe://quijotech.internal/ns/agentes/sa/analista-codigo).
2. Credenciales del Agente (Agent Credentials): Vinculación criptográfica entre el identificador del agente y sus atributos operacionales mediante certificados X.509 (X509-SVID), JSON Web Tokens (JWT-SVID) o tokens de prueba específicos de WIMSE (WPTs).
3. Aprovisionamiento de Credenciales (Credential Provisioning): Mecanismo dinámico en tiempo de ejecución para inyectar credenciales temporales en el contenedor del agente (mediante volúmenes proyectados en Kubernetes o agentes de SPIRE), evitando el almacenamiento de secretos persistentes en disco.
4. Autenticación del Agente (Agent Authentication):
   • Capa de Transporte: TLS Mutuo (mTLS) respaldado por certificados efímeros, garantizando canal cifrado y autenticación de remitente entre agentes y servidores de herramientas.
   • Capa de Aplicación: Tokens de prueba WIMSE (WPT) y firmas de mensajes HTTP (RFC 9421) para preservar la procedencia del mensaje incluso a través de proxys o brokers intermedios.
5. Autorización del Agente (Agent Authorization): Evaluación contextual de la Misión del Agente (el límite semántico y temporal de su tarea) combinada con la delegación OAuth 2.0 del usuario para resolver peticiones en tiempo real.

Reducción del Radio de Explosión: Tokens de Transacción (Transaction Tokens)

Uno de los mayores aportes del borrador AIMS (Sección 10.5) junto con la especificación draft-ietf-oauth-transaction-tokens es la introducción de los Transaction Tokens en cadenas complejas de agentes y microservicios.

En arquitecturas multi-agente o invocaciones de herramientas encadenadas (ej. un orquestador que llama a un agente especialista, el cual a su vez consulta un servidor MCP), propagar el token de acceso inicial representa un riesgo severo de fuga o reutilización ilegítima.

Para resolverlo, cada servicio intermedio intercambia el Access Token por un Transaction Token efímero. Este token está criptográficamente ligado a los parámetros invariantes de esa invocación concreta (dirección IP de origen, identificador único de transacción, operación exacta y límites financieros u operacionales). Un Transaction Token carece de validez como Access Token global: no puede reutilizarse en llamadas posteriores ni transferirse a otra herramienta.

4. Arquitectura en la Práctica: El Patrón Agentic Identity Broker (AIB)

Trasladar los RFCs y el estándar AIMS a la infraestructura real requiere un componente mediador. En su serie sobre identidad agéntica, Alejandro Saucedo describe la implementación práctica sobre Kubernetes (utilizando KAOS y Keycloak) y el Agentic Identity Broker (AIB) de código abierto impulsado por Zalando.

Regla de Oro: La Seguridad Vive en el Gateway, Nunca en el Prompt

El principio arquitectónico más relevante es tajante: la decisión y aplicación de políticas de seguridad (Enforcement) debe residir en el API Gateway y el Broker de Identidad, jamás en el prompt del sistema ni en el código del agente. El agente es código no confiable que puede ser manipulado mediante lenguaje natural; por tanto, el agente únicamente transporta metadatos, pero la red y el proxy determinan qué pasa.

Ver en alta resolución (SVG vectorial)

El Ciclo de Consentimiento Just-in-Time (Human-in-the-Loop)

¿Qué ocurre cuando un agente necesita consultar un repositorio privado del usuario en GitHub pero el usuario nunca ha delegado ese acceso para ese agente específico?

1. El agente emite la llamada HTTP hacia el endpoint de la herramienta a través del Gateway.
2. El Agentic Identity Broker (AIB) intercepta la solicitud y verifica su base de concesiones (grants). Al no encontrar una autorización activa para la tupla (user_id, agent_id, github_service, scopes), el broker corta el flujo inmediatamente.
3. El broker responde con un código de estado HTTP 401 Unauthorized o 403 Forbidden con un cuerpo estructurado que incluye una consent_url de OAuth 3-legged.
4. El agente recibe el error, comprende la necesidad de escalado y responde amablemente en el chat: "Para completar tu consulta necesito acceso de lectura a tus repositorios en GitHub. Por favor, autoriza la petición aquí: [Enlace Seguro de Autorización]".
5. El usuario hace clic, autentica en GitHub en su navegador web y otorga su consentimiento explícito (cumpliendo con RFC 9470 Step-Up).
6. El Broker recibe el callback de OAuth, almacena de forma segura las credenciales de larga duración en su bóveda criptográfica interna y notifica la activación de la concesión.
7. El agente reintenta la llamada; esta vez el broker genera un token de acceso temporal de mínima vigencia y la petición prospera con éxito.

Contención del Daño Frente a Prompt Injection

Es crucial desmitificar una creencia extendida: la identidad agéntica no evita que un LLM sea engañado por una inyección de prompt. Si un documento malicioso convence al modelo de ejecutar delete_repository, el agente intentará llamar a esa herramienta.

Sin embargo, lo que la arquitectura de identidad agéntica logra es delimitar matemáticamente el radio de explosión (blast radius):

• El agente nunca tiene acceso al token de bot global; solo puede invocar acciones que el usuario humano tenga derecho a ejecutar.
• El token concedido solo incluye scopes de lectura si la tarea fue clasificada como tal.
• Cualquier mutación crítica exige un desafío de consentimiento humano fuera de banda que el atacante no puede eludir desde el contexto del LLM.

5. Tabla Comparativa: Evolución de la Seguridad en Agentes

Comparativa entre el enfoque artesanal inicial y las arquitecturas modernas estandarizadas:

6. Implementación Práctica: Manejo de Delegación y Consent URL

A continuación se presenta un patrón en Python para herramientas de agentes que interactúan con un API Gateway protegido por un Broker de Identidad. El agente intenta ejecutar la acción; si el broker exige consentimiento del usuario (RFC 9470), el agente captura el desafío y devuelve al usuario la URL para su resolución:

import requests
from typing import Dict, Any

class AgentToolExecutor:
    def __init__(self, gateway_url: str, agent_workload_token: str):
        self.gateway_url = gateway_url
        self.agent_token = agent_workload_token

    def execute_tool(self, user_access_token: str, tool_name: str, payload: Dict[str, Any]) -> Dict[str, Any]:
        """
        Ejecuta una herramienta en nombre del usuario presentando doble identidad.
        La red valida ambas credenciales y aplica la intersección de políticas.
        """
        headers = {
            # 1. Identidad de la carga de trabajo (Workload Identity del agente)
            "Authorization": f"Bearer {self.agent_token}",
            # 2. Identidad del usuario delegante (Resource Owner)
            "X-User-Authorization": f"Bearer {user_access_token}",
            "Content-Type": "application/json"
        }

        response = requests.post(
            f"{self.gateway_url}/tools/{tool_name}/invoke",
            json=payload,
            headers=headers,
            timeout=15
        )

        # Caso A: Éxito (la llamada fue autorizada y enriquecida con Transaction Token)
        if response.status_code == 200:
            return {
                "status": "success",
                "data": response.json()
            }

        # Caso B: Desafío de Consentimiento / Human-in-the-Loop requerido (AIB step-up)
        if response.status_code in (401, 403):
            error_data = response.json()
            if "consent_url" in error_data:
                # El agente no alucina ni fuerza la llamada: devuelve la compuerta al usuario
                return {
                    "status": "requires_consent",
                    "consent_url": error_data["consent_url"],
                    "service": error_data.get("service"),
                    "message": (
                        f"Se requiere consentimiento explícito para que el agente "
                        f"acceda a {error_data.get('service')}. Por favor autoriza la "
                        f"operación en: {error_data['consent_url']}"
                    )
                }

        # Caso C: Error de autorización denegado definitivamente
        response.raise_for_status()