Arquitectura de referencia de IAM del agente de IA: identidad y acceso

Separe los siete límites de control¶

Una conexión de red exitosa demuestra accesibilidad. La autenticación verifica una identidad. La autorización resuelve a qué puede acceder esa identidad. La política de tiempo de ejecución evalúa esta acción y contexto. La aprobación le da a la persona elegible una decisión limitada. La ejecución crea el efecto secundario. La evidencia registra la unidad completa para su revisión.

Mantenga cada límite explícito en la arquitectura y el modelo de eventos. Una credencial válida aún puede carecer de autoridad para el propósito, cantidad, datos, entorno o tiempo solicitados. Una evaluación de políticas exitosa aún puede requerir un revisor independiente. Una aprobación puede liberar solo la solicitud y el contexto exactos que cubre.

Contexto del sistema y clases de identidad.¶

Trate la identidad del agente como el objeto comercial duradero y la identidad de la carga de trabajo como la instancia de software en ejecución. Una identidad de servicio representa una dependencia o puerta de enlace no humana. La herramienta o servidor de recursos autentica a la persona que llama y aplica su propia autorización. Un revisor utiliza una identidad humana con autoridad de decisión actual.

Alternativa de texto. Un usuario humano delega un propósito limitado a un agente y una carga de trabajo. Los servicios de identidad y token autentican a las partes. Autorización y política evalúan la solicitud. Un revisor decide las acciones retenidas. La herramienta ejecuta una acción permitida. Cada etapa envía registros al almacén de pruebas dentro del límite de confianza del inquilino y la organización.

Desplácese horizontalmente para ver el gráfico.

Elija una identidad dedicada, delegada o híbrida¶

Una identidad dedicada le da al agente su propia autoridad empresarial. Una identidad delegada incorpora la autoridad actual de un usuario a la tarea. Un híbrido registra a ambas partes: el agente sigue siendo el actor y el humano sigue siendo el sujeto o patrocinador. Esta separación respalda políticas, revocaciones y auditorías precisas.

Las cuentas de servicios compartidos debilitan la atribución y, a menudo, ofrecen un amplio acceso permanente. Manténgalos detrás de una puerta de enlace mediada por servicios cuando un sistema de destino no pueda emitir credenciales de agente limitadas. Registre el agente de origen, el sujeto humano, la decisión de política y el recibo posterior de cada llamada mediada.

Solicitud y secuencia de autoridad delegada¶

Vincule al sujeto humano, el actor agente, la carga de trabajo, la delegación, el propósito, el objetivo y el vencimiento antes de la emisión del token. Utilice una credencial de corta duración vinculada a la audiencia para el recurso de destino. Resuelva la autoridad actual nuevamente en el límite de acción porque los roles, las asignaciones, los hechos de riesgo y la política pueden cambiar durante una sesión.

Alternativa de texto. El usuario asigna un propósito al agente. El agente inicia una carga de trabajo certificada. La carga de trabajo solicita un token. El servicio de token valida al actor y al sujeto delegado y luego emite una credencial de corta duración vinculada a la audiencia. La carga de trabajo envía el contexto completo a la política. La herramienta recibe solo una solicitud permitida o válidamente aprobada y devuelve un recibo de ejecución.

Desplácese horizontalmente para ver el gráfico.

Sea propietario de todas las dimensiones de derechos¶

El privilegio mínimo se vuelve comprobable cuando cada dimensión tiene un propietario, un punto de decisión, una ruta de revisión, una ruta de revocación y un campo de evidencia. Evalúe la tupla completa para cada solicitud consecuente. Un rol puede proporcionar una base, mientras que el propósito, el valor, los datos, el entorno y el tiempo mantienen limitada la subvención efectiva.

Combinar patrones de autorización deliberadamente¶

El control de acceso basado en roles proporciona una base de trabajo o servicio estable. El control de acceso basado en atributos evalúa hechos de sujetos, recursos, acciones y entorno. El control de acceso basado en relaciones resuelve relaciones de gráficos como asignación, propiedad o pertenencia a casos. El acceso basado en capacidades conlleva un objeto de autoridad transferible limitado que debe permanecer sujeto a objetivos, a plazos determinados y ser revocable.

Utilice la combinación más pequeña que exprese la decisión real. Registre las entradas resueltas y la concesión efectiva final para que los revisores puedan reproducir el resultado después de que cambien los grupos, atributos, relaciones o estados de capacidad.

Flujo de decisiones de derechos y aprobación¶

Evalúe la identidad, el inquilino, la delegación, la audiencia y el vencimiento antes de resolver los derechos. Una autoridad no válida o faltante detiene la solicitud. Luego, la política de tiempo de ejecución selecciona permitir, advertir, requerir_aprobación o bloquear. Una aprobación requerida retiene la solicitud exacta y la libera solo después de que un revisor independiente elegible decida antes de que expire.

Alternativa de texto. El flujo verifica la identidad y el contexto del token, luego las nueve dimensiones de derechos. Bloques de contexto no válidos. La política selecciona uno de cuatro resultados. El bloque se detiene. Requerir aprobación envía la solicitud vinculada a un revisor independiente. Stops de rechazo o caducidad. Permitir, advertir o validar la aprobación se ejecuta una vez y registra el recibo y la evidencia.

Desplácese horizontalmente para ver el gráfico.

Emitir credenciales de corta duración y controlar la suplantación de identidad¶

Emita credenciales después de la autenticación de la carga de trabajo y la resolución de la autoridad actual. Vincule cada credencial a una audiencia, dominio de confianza, entorno, relación de sujeto o actor, propósito, alcance y vida corta. Mantenga los privilegios de actualización e intercambio más limitados que la autoridad original.

OAuth 2.0 Token Exchange define tokens de sujeto y actor separados para la delegación. El reclamo act puede expresar el actor actual. Los indicadores de recursos vinculan una solicitud de token al recurso de destino. Las solicitudes de autorización enriquecidas pueden incluir acciones estructuradas y detalles de recursos. Cada protocolo todavía depende del servidor de autorización y del servidor de recursos para hacer cumplir la política local y la revocación.

• Justo a tiempo: otorga acceso cuando comienza la tarea, después de la aprobación o asignación, y lo expira con la tarea.
• Rotación: automatice el reemplazo de claves y credenciales, retenga evidencia de generación y superposición, y pruebe la credencial anterior después de la transición.
• Límite de suplantación: reservar la suplantación para casos explícitos en los que el actor se vuelve indistinguible en el objetivo; preservar al actor original en un registro protegido separado.
• Límite de delegación: mantiene visibles tanto al sujeto como al actor y reduce la autoridad delegada para la tarea.
• Manejo de tokens: excluye los secretos sin procesar de los registros; retiene el emisor, el identificador del token o el resumen, la audiencia, los alcances, el tiempo de vigencia, el vencimiento y el resultado de la revocación.

Política de privilegios mínimos reutilizable¶

La siguiente política es un ejemplo de diseño neutral para un lector de documentos de revisión de crédito. Cubre las nueve dimensiones de derechos y vincula el contexto faltante o caducado a un bloque. Descarga el archivo JSON para talleres y pruebas. Reemplace cada identificador sintético y umbral con un contrato local aprobado.

{
  "schema_version": "1.0",
  "policy_id": "credit-review-document-reader",
  "status": "example",
  "subject": {
    "agent_id": "credit-review-agent",
    "workload_id": "spiffe://bank.example/prod/credit-review",
    "delegated_user_required": true
  },
  "entitlements": {
    "tools": [
      "credit_application.read",
      "credit_memo.draft",
      "credit_decision.propose"
    ],
    "resources": [
      "credit-application:{case_id}"
    ],
    "data": {
      "fields": [
        "declared_income",
        "verified_income",
        "existing_exposure",
        "requested_amount"
      ],
      "denied_fields": [
        "special_category_data",
        "unrelated_household_records"
      ]
    },
    "actions": [
      "read",
      "draft",
      "propose_credit_decision"
    ],
    "purposes": [
      "credit_application_review"
    ],
    "amount": {
      "currency": "EUR",
      "approval_threshold": 25000,
      "authorization_ceiling": 100000
    },
    "environments": [
      "production"
    ],
    "time": {
      "maximum_token_lifetime_seconds": 900,
      "access_window": "case_assignment"
    }
  },
  "decision": {
    "allow_when": [
      "case_id matches the assigned case",
      "delegated user remains assigned and active",
      "all requested fields are allowed",
      "purpose equals credit_application_review",
      "requested amount is at or below EUR 25000",
      "token audience matches the target resource"
    ],
    "require_approval_when": [
      "the agent proposes a credit decision",
      "the requested amount exceeds EUR 25000 and is at or below EUR 100000"
    ],
    "block_when": [
      "identity, delegation, tenant, purpose, or audience is missing",
      "the credential, assignment, entitlement, or policy is expired",
      "the request targets an unassigned case or forbidden field",
      "the requested amount exceeds EUR 100000",
      "the destination or purpose differs from the authorized values",
      "the policy decision service cannot produce the required verdict"
    ]
  },
  "evidence": [
    "principal_id",
    "agent_identity_id",
    "workload_identity_id",
    "delegation_id",
    "tenant_id",
    "tool_id",
    "resource_id",
    "data_boundary_ref",
    "action",
    "purpose",
    "amount",
    "environment",
    "requested_at",
    "expires_at",
    "policy_id",
    "policy_version",
    "authentication_event_id",
    "authorization_decision_id",
    "policy_decision_id",
    "approval_decision_id",
    "reason_codes",
    "approval_id",
    "reviewer_id",
    "execution_receipt"
  ]
}

Ejecute la revisión de derechos como control¶

Una revisión comienza con una identidad conciliada y una población de acceso, luego prueba la autoridad efectiva y el uso observado. Descargue el libro de arquitectura de IAM para obtener la lista de verificación completa, las tablas de decisiones y el registro de revisión.

• Concilie la población. Compare los agentes registrados y las cuentas de servicio con los emisores de tokens, los principales de la nube, los almacenes secretos, las puertas de enlace, el descubrimiento de MCP, las identidades de CI/CD, el gasto de paquetes y las llamadas de herramientas observadas.
• Resolver el acceso efectivo. Incluya concesiones directas, roles, atributos, relaciones, capacidades, grupos, delegaciones, acceso temporal, reglas de políticas y permisos posteriores.
• Buscar excepciones de control. Registre autoridad huérfana, compartida, inactiva, duplicada, vencida, no observada, entre inquilinos, autoaprobable y demasiado amplia.
• Aplicación de prueba. Ejercicio permitido, aprobación, bloqueado, caducado, falta de contexto, revocado y solicitudes de relación obsoletas.
• Conciliar resultados. Unir cada muestra al resultado de la política, la decisión del revisor, la recepción de la herramienta, el estado del negocio y el registro de evidencia.
• Certificar el resultado del alcance. Registrar criterios, población, período, revisor, excepciones, decisión, vencimiento, próxima revisión y referencias de evidencia.

Descubrir y auditar cuentas de servicio¶

Construya la población de identidad no humana a partir de varias fuentes independientes. Los directorios de identidad por sí solos omiten credenciales creadas en proyectos en la nube, sistemas CI/CD, almacenes secretos, clientes MCP locales, programadores, automatización de navegadores y aplicaciones posteriores. Las observaciones de puertas de enlace y redes revelan identidades que pasan por alto el catálogo esperado.

Para cada cuenta de servicio, registre el proceso propietario, la persona responsable, los agentes y las cargas de trabajo que pueden usarlo, la ubicación de las credenciales, los objetivos permitidos, las concesiones efectivas, el último uso, el vencimiento, la rotación, el método de revocación y la fuente de evidencia. Poner en cuarentena o revocar cuentas sin propietario actual o uso aprobado después de la revisión de seguridad definida.

Revocar, detener, revertir y recuperar¶

La revocación cierra la autoridad para uso futuro. La parada de emergencia contiene trabajo activo y en cola. La reversión restaura una versión o configuración en buen estado. La recuperación de incidentes concilia los efectos posteriores, emite credenciales nuevas, prueba el estado seguro y utiliza una decisión de reinicio independiente.

Alternativa de texto. El propietario del incidente registra el alcance afectado y activa un estado de denegación. Los controles de flujo de trabajo cancelan el trabajo activo y en cola. Los controles de identidad desactivan el agente y la carga de trabajo, revocan tokens y rotan credenciales. Las puertas de enlace niegan nuevas solicitudes. Los propietarios de herramientas concilian los efectos aceptados y comprometidos. Acuses de recibos de registros de evidencia y acceso residual. La recuperación utiliza una versión en buen estado, credenciales nuevas, una lista de permitidos limitada y aprobación de reinicio.

Desplácese horizontalmente para ver el gráfico.

Hacer cumplir los límites de los inquilinos y las organizaciones¶

Trate al inquilino, la organización, el dominio fiduciario, el entorno y la región como datos de autorización con emisores autorizados. Valídelos en cada límite externo y utilícelos en consultas de almacenes de datos, audiencias de tokens, contexto de políticas, búsqueda de aprobaciones, enrutamiento de herramientas y selección de evidencia.

Mantenga las identidades de producción y no producción en dominios de confianza separados o espacios de nombres equivalentes. Calificar atributos y roles extranjeros por parte de su autoridad emisora. La federación establece qué credenciales se pueden autenticar en todos los dominios; La autorización local todavía decide qué acción y recurso puede utilizar cada identidad extranjera.

• Rechace un selector de inquilino u organización que entre en conflicto con el token autenticado.
• Vincule identificadores de recursos, límites de relaciones, capacidades y aprobaciones a un inquilino.
• Utilice audiencias de tokens específicas de destino y evite tokens al portador aceptados por varios recursos no relacionados.
• Pruebe lecturas, escrituras, aprobaciones, delegación, claves de caché, colas y exportaciones de evidencia entre inquilinos.
• Registre el inquilino autorizado y el dominio de confianza en cada evento de identidad, política, ejecución y evidencia.

Asignar responsabilidad a lo largo del ciclo de vida¶

Nombre un rol responsable para cada identidad, derecho, decisión, efecto y límite de evidencia. Los grupos asesores pueden revisar el diseño. La autoridad operativa permanece asignada a una persona o función con un delegado definido, un período de vigencia y una ruta de escalamiento.

Seleccione un patrón de implementación¶

Elija el patrón entre el propietario de la autoridad, la capacidad del sistema de destino, la consecuencia de la acción, el volumen de identidad y la atribución requerida. Una sola organización puede utilizar varios patrones en todos los Procesos y al mismo tiempo preservar un modelo de evidencia.

Ejemplo resuelto: revisión de crédito regulado¶

Un banco asigna un agente de revisión de crédito al caso CR-1842. El agente tiene una identidad dedicada y se ejecuta bajo una carga de trabajo de producción certificada. Un asegurador designado es el sujeto delegado para este caso. El servicio de token emite una credencial de 15 minutos cuya audiencia es el servicio de documentos.

La autorización permite cuatro campos aprobados, tres acciones y importes de hasta 100.000 EUR para el propósito credit_application_review mientras la asignación permanezca activa. La política permite leer esos campos y redactar una nota. Una decisión de crédito propuesta o una solicitud superior a 25 000 EUR crea una Solicitud de Decisión. Un nuevo propósito, un campo prohibido, una cantidad por encima del límite de autorización o falta de identidad, delegación, inquilino, audiencia o bloques de políticas actuales. La aprobación opera dentro del límite máximo de autorización.

El asegurador solicitante no puede decidir sobre la solicitud retenida. Un segundo revisor calificado ve la acción exacta, la fuente de evidencia, los motivos políticos, el requisito de autoridad, el vencimiento y el efecto esperado. La aprobación libera la misma solicitud vinculada una vez. El recibo posterior y el estado del caso se unen a los registros de identidad, delegación, derecho, política, revisor y ejecución.

Cómo se relaciona la arquitectura con los contratos actuales del KLA¶

El Plano de control KLA gobierna las acciones de los agentes instrumentados. La implementación actual proporciona una capa de política, aprobación, ejecución, linaje y evidencia en tiempo de ejecución. Los proveedores de identidades empresariales, los servidores de recursos y los sistemas de credenciales siguen siendo la autoridad para sus identidades y concesiones.

La siguiente asignación refleja el código presente en la fuente del repositorio en la confirmación a4e8087f. El comportamiento de implementación y producción aún no se ha verificado. Los enlaces de origen están anclados a esa confirmación. El estatus distingue un contrato vigente de un mapeo parcial o una abstracción conceptual.

Brechas actuales del KLA y abstracciones conceptuales¶

KLA evalúa y registra la autoridad en el límite de acción gobernado. Está fuera de varias responsabilidades empresariales de IAM en esta referencia. Trate los campos y flujos siguientes como requisitos de integración hasta que la brecha indicada tenga un contrato implementado vigente.

• Asunto delegado. La creación de la ejecución actualmente establece onBehalfOfSubject como el asunto iniciador y registra al cliente que llama. El contrato de ejecución pública completo actualmente carece de un sujeto de usuario final y una cadena de delegación certificados por separado.
• Ciclo de vida de la identidad. Los proveedores de identidades empresariales, las autoridades de certificación de cargas de trabajo, los directorios de recursos humanos y los sistemas de descubrimiento de cuentas de servicio universal siguen siendo dependencias externas.
• Ciclo de vida de las credenciales. Los conectores y los sistemas de destino poseen herramientas posteriores de emisión, rotación, revocación, intermediación y activación de incidentes de credenciales.
• Normalización de derechos. Los contratos actuales admiten principal, recurso, acción, atributos, argumentos de herramienta, entorno y contexto flexible. Cada ruta puede representar propósito, cantidad, datos y hechos de relación a través de campos flexibles; el contrato deja su normalización al productor.
• Modelos de autorización. Los patrones RBAC, ABAC, de relación y de capacidad en esta referencia son opciones de arquitectura. El contrato de póliza actual del KLA es independiente del modelo.
• Certificación. El producto actual registra controles y evidencias. La certificación universal de la identidad de un agente o de la población con derechos queda fuera del contrato actual.
• Distribución de revocaciones. Se implementa la cancelación del tiempo de ejecución. La desactivación de identidad de un extremo a otro, la revocación de tokens, el aislamiento de la red, la cancelación posterior y la compensación siguen siendo acciones externas coordinadas.
• Registro portátil. El Esquema de registro de auditoría del agente de IA normaliza varios productores de KLA en un evento neutral para el proveedor. Los productores actuales emiten sus registros nativos autorizados, que la referencia asigna al sobre público.

Fuentes primarias y frescura.¶

Esta arquitectura se verificó el 28 de julio de 2026. Los estándares de identidad, las especificaciones de protocolo, los borradores de directrices y los perfiles de implementación pueden cambiar. Vuelva a verificar la fuente en vivo y la implementación local antes de utilizar un estado en una decisión de auditoría, adquisición o seguridad.

• [Documento conceptual de autorización e identidad del agente de inteligencia artificial y software NCCoE del NIST] (https://www.nccoe.nist.gov/publications/other/accelerating-adoption-software-and-ai-agent-identity-and-authorization-concept) (borrador, publicado el 5 de febrero de 2026)
• NIST SP 800-162, Guía para el control de acceso basado en atributos
• Proyecto de control de acceso basado en roles del NIST y referencia estándar actual
• NIST SP 800-207, Arquitectura de confianza cero
• RFC 8693, Intercambio de tokens OAuth 2.0
• RFC 8707, Indicadores de recursos para OAuth 2.0
• RFC 9396, solicitudes de autorización enriquecidas de OAuth 2.0
• Estándar SPIFFE 1.15.2 y especificaciones de identidad de carga de trabajo
• Especificación de autorización del protocolo de contexto modelo, 25 de noviembre de 2025
• [Mejores prácticas de seguridad del protocolo de contexto modelo] (https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)