El control de acceso de agentes de IA otorga a un agente designado la autoridad actual mínima requerida para un propósito aprobado, evalúa cada acción propuesta contra esa autoridad, dirige las excepciones consiguientes a un ser humano elegible y registra el resultado. Un diseño completo cubre la creación de identidad a través de la revocación de emergencia. Resuelve derechos efectivos en tiempo de ejecución porque los roles, las asignaciones, la confidencialidad de los datos, los valores de las transacciones y las políticas pueden cambiar entre el inicio de sesión y la ejecución.
Este pilar responde a cómo diseñar y operar el sistema de control. La [guía de permisos de agentes de IA] (/blog/ai-agent-permissions) cubre la certificación y la auditoría de acceso periódica. La [arquitectura de referencia IAM del agente de IA] (/blog/ai-agent-identity-access-management-reference-architecture) proporciona el componente más profundo y el modelo de implementación. La guía aquí es neutral para el proveedor y se cotejó con fuentes primarias el 28 de julio de 2026.
Utilice un ciclo de vida desde la identidad hasta la revocación
Asigne a cada agente un propietario duradero, un propósito, una clase de riesgo, un entorno y un registro de identidad antes de otorgarle acceso. Vincule esa identidad empresarial a una carga de trabajo o cliente certificado. Otorgar derechos limitados con fecha de vencimiento y revisión. Evalúelos en cada acción. Registre la aprobación y ejecución bajo los mismos identificadores de correlación. Revocar la autoridad cuando cambie el propósito, propietario, asignación, riesgo o entorno.
Alternativa de texto. El ciclo de vida comienza con el registro y la vinculación de identidad, avanza a través de la concesión, la evaluación del tiempo de ejecución, la aprobación humana, la ejecución, las pruebas y la revisión periódica, y luego finaliza con la revocación, la conciliación y la recuperación. Un cambio de propósito, propiedad, riesgo o entorno hace que el agente vuelva a ser revisado antes de su posterior ejecución.
Desplácese horizontalmente para ver el gráfico.
Trate el acceso como un ciclo de vida gobernado con un propietario, vencimiento, revisión y ruta de revocación probada.
Abrir gráfico a tamaño completo| Escenario | Decisión | Dueño | Evidencia |
|---|---|---|---|
| Registro | Propósito del agente, riesgo, patrocinador, inquilino, entorno. | Dueño de negocio | Registro y aprobación del registro |
| Vincular identidad | Agente, carga de trabajo, servicio y sujeto delegado | IAM y propietarios de plataformas | Emisor, sujeto, actor, audiencia, certificación |
| Conceder | Límites eficaces de herramientas, recursos, datos, acciones y contexto | Propietarios de recursos y políticas | Concesión, póliza, vencimiento, excepción |
| Evaluar | Solicitud actual contra autoridad actual | Propietarios de autorizaciones y pólizas | Entradas, resultados, códigos de motivo, versiones |
| Aprobar | La persona elegible libera la solicitud retenida exacta | Propietario de la autoridad revisora | Resumen del rol, justificación, resumen, vencimiento |
| Ejecutar | La solicitud vinculada crea un efecto secundario | Propietarios de herramientas y procesos | Recibo, estado anterior y posterior, efecto posterior |
| Revisar | El acceso sigue siendo necesario y proporcionado | Propietario y revisor independiente | Población, excepciones, límite de certificación. |
| Revocar | Detener la autoridad y conciliar el acceso residual | Propietarios de incidentes, IAM y herramientas | Comandos, negaciones, sesiones residuales, recuperación. |
Elija el patrón de identidad antes de asignar derechos
Utilice una identidad de agente dedicada para una autoridad empresarial repetible. Agregue un sujeto humano delegado cuando la asignación actual de esa persona limite la acción. Vincule el agente a una identidad de carga de trabajo para que la instancia de software en ejecución sea atribuible. Reserve cuentas de servicios compartidos para objetivos heredados detrás de una puerta de enlace obligatoria que resuelve el agente y la solicitud antes de cada llamada.
| Patrón | Usar cuando | Control requerido | Riesgo primario |
|---|---|---|---|
| Agente dedicado | La organización posee autoridad operativa repetible. | Propietario designado, subvenciones limitadas, vinculación de carga de trabajo, ciclo de vida | Acceso permanente o huérfano |
| Usuario delegado | Una persona sigue siendo el propietario de la autoridad. | Vinculación actor-sujeto, alcance reducido, finalidad, caducidad | Privilegio de usuario ambiental |
| Híbrido | Tanto el agente actor como el sujeto humano afectan la decisión. | Intercambio de tokens o identidad dual equivalente, audiencia, evidencia | Confusión actor-sujeto |
| Cuenta de servicio intermediada | Un objetivo heredado acepta una credencial técnica | Puerta de enlace obligatoria, política por llamada, detección de omisión, recibo | Credencial compartida y atribución débil |
Combine RBAC, ABAC y capacidades deliberadamente
El control de acceso basado en roles (RBAC) proporciona tareas básicas comprensibles. El control de acceso basado en atributos (ABAC) limita una solicitud utilizando atributos de asunto, recurso, acción y entorno. Una capacidad otorga a un titular específico una autoridad limitada y transferible por regla sobre un recurso o acción. La mayoría de los sistemas de agentes de producción utilizan roles para la asignación de referencia, atributos para el contexto en vivo y capacidades o tokens de corta duración para la llamada final.
| Modelo | Mejor uso | Ejemplo | Requisito de control |
|---|---|---|---|
| RBAC | Líneas base de trabajo o servicio estables | claims_reader puede leer resúmenes de reclamos asignados | Pequeños roles, separación, revisión periódica. |
| ABAC | Decisiones sensibles al contexto | El inquilino, la asignación, la sensibilidad, el propósito, el monto, la ubicación y el tiempo coinciden | Atributos de confianza, actualidad, códigos de motivo |
| Capacidad | Autoridad de llamada limitada | Una subvención de corta duración para claim:1842 y settlement.propose | Audiencia, caducidad, atenuación, defensa de repetición, revocación |
| Conjunto | Acciones de producción consecuentes. | El rol otorga elegibilidad; los atributos limitan el contexto; capacidad vincula la llamada | Una regla de precedencia y un registro de evidencia |
Poseer los siete límites de privilegios mínimos
Una lista de herramientas permitidas es un límite. La política también debe restringir los registros, campos, operación, valor, propósito comercial, implementación y tiempo. Asigne una fuente de verdad, un punto de cumplimiento, un propietario de revisión y un campo de evidencia a cada límite.
| Límite | Pregunta de política | control de ejemplo | Evidencia |
|---|---|---|---|
| Herramienta | ¿Qué conector, API o servidor MCP puede recibir una llamada? | Identidad y destino de la herramienta incluida en la lista permitida | ID de herramienta, punto final, versión del servidor |
| Datos | ¿Qué inquilino, registro, campo, región y sensibilidad? | Caso asignado y campos aprobados | ID de recursos, conjunto de campos, clasificación |
| Acción | ¿Qué operación leer, redactar, proponer, aprobar o ejecutar? | Separe los permisos de propuesta y ejecución | Operación y parámetros |
| Cantidad | ¿Qué valor o umbral de riesgo se aplica? | Aprobación por 25.000 euros; límite máximo de 100.000 euros | Moneda, importe, umbrales |
| Objetivo | ¿Qué uso comercial declarado autoriza el acceso? | Propósito es igual a claim_settlement | Propósito, base legal o política, caso |
| Ambiente | ¿Qué inquilino, cuenta, región, red e implementación? | Identidad de producción aceptada solo en producción. | Inquilino, entorno, carga de trabajo. |
| Tiempo | ¿Cuándo y por cuánto tiempo? | Token de 15 minutos dentro de la tarea activa | Emitido, efectivo, vencimiento, tiempo de decisión. |
Devolver uno de los cuatro resultados de política
Defina la precedencia y el comportamiento de falla antes de la implementación. Una condición de bloque gana. Una entrada requerida faltante o una dependencia de política obligatoria no disponible ingresa al estado seguro documentado. La aprobación libera solo la misma solicitud, parámetros, evidencia, política y contexto que vio el revisor.
| Resultado | Significado | Comportamiento de ejecución | Evidencia |
|---|---|---|---|
| permitir | La solicitud está dentro de la autoridad y la política actuales. | Ejecutar la solicitud vinculada | Decisión, versiones, motivos, recibo. |
| advertir | La solicitud puede proceder con un aviso grabado | Advertencia de superficie y ejecución bajo política definida | Advertencia, regla de reconocimiento, recibo. |
| requerir_aprobación | Una persona cualificada debe decidir antes del vencimiento. | Sostener; aprobar, rechazar, solicitar cambios o escalar | Solicitud de decisión, autoridad revisora, justificación |
| bloquear | La solicitud excede la autoridad o viola la política | Deténgase antes del efecto secundario. | Motivo de denegación, solicitud de resumen, intento de destino |
Colocar la aprobación humana en límites consecuentes
Requerir aprobación para decisiones que afectan derechos, efectos irreversibles, excepciones de políticas, valores elevados, comunicaciones externas sensibles, expansión del acceso e incertidumbre inusual. Resolver el rol actual del revisor, el límite de valor, la delegación, la capacitación, los conflictos y la relación con el creador en el momento de la decisión.
La [guía de decisiones de supervisión humana] (/blog/human-oversight-ai-agents-approval-required) cubre el diseño de activación, la separación entre el fabricante y el verificador, la caducidad, la anulación, la apelación y el manejo de fallas. La [arquitectura de supervisión humana] (/platform/human-oversight) muestra las solicitudes de decisiones de KLA y el escritorio de decisiones en el producto.
- Muestre la acción propuesta exacta, el objetivo, los valores, la parte afectada y el efecto esperado.
- Muestre el resultado de la política, las reglas coincidentes, los códigos de motivo, los hechos fuente, la incertidumbre y los hechos faltantes.
- Vincule la aprobación al resumen de la solicitud, la versión de la política, la instantánea de la evidencia, el revisor y el vencimiento.
- Reevaluar la autoridad y la política inmediatamente antes de su publicación.
- Mantenga disponibles las rutas de rechazo, solicitud de cambios, escalamiento, tiempo de espera y apelación.
Ejecutar revisión de derechos como prueba de control
Comience con la población completa de agentes y cuentas de servicio. Compare la autoridad solicitada, aprobada, configurada y observada. Inspeccione concesiones directas, roles heredados, pertenencia a grupos, acceso delegado, servidores MCP, secretos de conectores, excepciones de emergencia, identidades inactivas, duración de los tokens y permisos del sistema de destino.
Descargue la [lista de verificación de revisión de derechos del agente de IA] (/downloads/ai-agent-entitlement-review-checklist.md) para la solicitud de evidencia, el descubrimiento de la cuenta de servicio, las pruebas de muestra, el registro de excepciones y la aprobación del revisor.
| Campo | Valor requerido | Prueba |
|---|---|---|
| Población | Cada agente de producción, carga de trabajo, identidad de servicio, puerta de enlace y ruta delegada | Concilie registro, proveedor de identidad, secretos, puertas de enlace, herramientas y registros de tiempo de ejecución |
| Autoridad | Herramienta eficaz, datos, acción, cantidad, propósito, entorno y tiempo. | Compare la política aprobada con el acceso configurado y observado |
| Dueño y necesidad | Propietario responsable designado y propósito comercial actual | Confirmar con un revisor independiente |
| Excepciones | Motivo, control compensatorio, aprobador, vencimiento. | Rechazar excepciones vencidas o sin propietario |
| Revocación | Actuadores, dependencias, última prueba, acceso residual | Ejercer una inhabilitación representativa |
| Conclusión | Alcance, criterios, periodo, muestras, hallazgos, limitaciones, próxima revisión | Registre el límite de certificación |
Descubra cuentas de servicio en todos los planos de control
Las cuentas de servicio a menudo se encuentran fuera del registro de agentes. Concilie IAM en la nube, aplicaciones de proveedores de identidades, identidades de cargas de trabajo, cuentas de servicio de Kubernetes, identidades de CI, entradas de administrador secreto y de bóveda, puertas de enlace API, registros de servidores MCP, instalaciones de conectores, registros de auditoría del sistema de destino y registros de salida de red.
- Marque credenciales sin propietario, sin señal de último uso, sin caducidad, alcances amplios comodín o uso desde varios entornos.
- Rastree cada credencial compartida a través de la puerta de enlace hasta el agente, el inquilino, la solicitud y el recibo posterior.
- Compare los destinos y operaciones observados con las herramientas y los límites de acción aprobados.
- Rotar o retirar las credenciales inactivas según el procedimiento de cambio y recuperación de la organización.
Hacer ejecutable la revocación de emergencia
Predefina quién puede declarar el incidente, qué alcance pueden detener y cómo los socorristas verifican la contención. Preservar la evidencia durante la respuesta. Conciliar los efectos posteriores antes de restaurar la autoridad.
| Paso | Acción | Prueba |
|---|---|---|
| 1. Alcance | Identifique inquilinos, agentes, cargas de trabajo, credenciales, sesiones, herramientas, solicitudes y trabajos posteriores. | Identificadores de incidentes y correlaciones |
| 2. Detener | Cancelar ejecuciones activas y retener trabajos en cola o sujetos a aprobación | Resultados de cancelación y transiciones denegadas |
| 3. Revocar | Desactivar identidad; revocar tokens, secretos, capacidades, sesiones y subvenciones delegadas | Respuestas del actuador y negaciones posteriores. |
| 4. Aislar | Bloquear rutas de red, conectores o cuentas de destino cuando la revocación de credenciales esté incompleta | Decisiones sobre la red y el sistema objetivo |
| 5. Reconciliar | Encuentre efectos secundarios completos y parciales; compensar cuando esté autorizado | Recibos, antes y después del estado, compensación. |
| 6. recuperar | Reparar la causa raíz, emitir nueva autoridad, probar el estado seguro, aprobar el reinicio | Cambio, prueba, revisor, tiempo de reinicio |
Capture evidencia en el límite de decisión
El registro de evidencia debe permitir al revisor reconstruir la cadena de identidad, la autoridad efectiva, el contexto evaluado, el resultado, la decisión humana, el efecto secundario y la posterior revocación. Utilice identificadores estables para unir registros nativos autorizados. El [Esquema de registro de auditoría del agente AI] público (/resources/ai-agent-audit-log-schema) proporciona un sobre de eventos portátil.
| Límite | Campos obligatorios |
|---|---|
| Identidad | inquilino, director, agente, carga de trabajo, asunto delegado, emisor, audiencia, evento de autenticación |
| Derecho | roles efectivos, atributos, capacidades, herramienta, recurso, datos, acción, cantidad, propósito, entorno, tiempo |
| Política | Versiones de políticas y reglas, campos evaluados, resultados, códigos de motivo, excepciones. |
| Aprobación | ID de solicitud y resumen, revisor elegible, resumen del rol, decisión, justificación, vencimiento |
| Ejecución | clave de idempotencia, llamada de herramienta, recepción, estado antes y después, efecto descendente |
| Ciclo vital | propietario, revisar, cambiar, revocar, denegar, acceso residual, compensación, recuperación |
Ejemplo resuelto: liquidación de seguros regulados
Una aseguradora asigna un agente de reclamos para reclamar CL-1842. Una identidad de agente dedicada se ejecuta bajo una carga de trabajo de producción certificada. La póliza permite la reclamación cedida, campos de reclamación aprobados, lectura de documentos, redacción de liquidación y propuestas de liquidación de hasta 100.000 EUR para claim_settlement durante la cesión activa.
Una propuesta de 32 000 EUR devuelve require_approval porque supera el umbral de aprobación de 25 000 EUR. Un administrador de reclamos calificado, independiente del solicitante, revisa los hechos originales, los motivos de la política, el beneficiario propuesto, el monto y el efecto contable esperado. La aprobación vincula esos valores durante diez minutos. El sistema reevalúa la política, la ejecuta una vez y une el recibo posterior a la solicitud y la decisión.
Un beneficiario diferente, un campo médico prohibido, una asignación vencida, un nuevo propósito, evidencia modificada, una cantidad superior a EUR 100 000 o un resultado de póliza obligatorio faltante devuelve block. La revocación de emergencia cancela el trabajo activo, deshabilita el agente y las credenciales de la carga de trabajo, bloquea el conector, concilia efectos parciales y registra la aprobación de la recuperación.
| Escenario | Resultado | Evidencia |
|---|---|---|
| Identidad | Agente, carga de trabajo, inquilino, asignación de reclamo y propósito válido | Emisor, sujetos, atestación, cesión, vencimiento |
| Derecho | Reclamo, campos, herramientas, acción, límite de valor, entorno y coincidencia de tiempo | Subvenciones y atributos efectivos |
| Política | require_approval a 32.000 euros | Versión de política, umbral, motivos, resumen de solicitud |
| Aprobación | Gerente independiente aprueba solicitud exacta durante diez minutos | Elegibilidad, función, justificación, vencimiento |
| Ejecución | Política revisada nuevamente; instrucción de transferencia aprobada emitida una vez | Recibo, clave de idempotencia, efecto libro mayor |
| Revisar | El revisor muestra la preparación para la solicitud, la decisión, la ejecución y la revocación | Papel de trabajo, excepción, conclusión. |
Trate la autorización de MCP como un límite de integración
El protocolo de contexto modelo (MCP) define interacciones de autorización para transportes HTTP y señala las implementaciones para las prácticas de seguridad de OAuth. El control de acceso empresarial aún posee la identidad del agente, la vinculación de los inquilinos, las concesiones del sistema de destino, las listas de herramientas permitidas, los límites de datos y acciones, la aprobación, la evidencia y la revocación de incidentes.
Revise la [guía de seguridad y auditoría de MCP] (/blog/mcp-audit-security-governance) para conocer los riesgos de transporte y servidor. Registre la identidad del servidor, las herramientas anunciadas, el servidor de autorización, las audiencias, los alcances, el consentimiento o aprobación, la vida útil del token, los argumentos de la herramienta, el resultado y el efecto posterior.
Asigne el modelo a los contratos actuales de KLA con precisión
El Plano de control KLA gobierna las acciones instrumentadas en tiempo de ejecución. Esta asignación refleja el código presente en la confirmación 8fd582a6. El comportamiento de implementación y producción aún no se ha verificado. Los proveedores de identidades empresariales, los emisores de credenciales, los directorios, los autorizadores de herramientas y los inventarios de derechos del sistema fuente siguen siendo autoridades externas.
| Función | Mapeo actual del ELK | Fuente | Estado |
|---|---|---|---|
| Autenticación y vinculación de inquilinos | La API de ejecución verifica el emisor y la audiencia de JWT permitidos y deriva el enlace del inquilino. | middleware de autenticación y ruta de ejecución | Código presente |
| Contexto de acción y cuatro resultados | Las solicitudes de políticas incluyen principal, recurso, acción, actor, entorno, herramienta, destino, sensibilidad de los datos y contexto empresarial. Los resultados son permitir, advertir, requerir_aprobación o bloquear. | contratos de póliza | Código presente; campos específicos del productor |
| Autorización del plano de control | permissionProcedure autentica a la persona que llama y no se cierra cuando el permiso con nombre está ausente. protectedProcedure solo se autentica; integrations.list, llmProviders.list y usage.getQuotaStatus lo usan sin una verificación de permiso explícita. La cobertura de la autorización es específica del procedimiento. | definiciones de procedimientos, integraciones, proveedores y uso | Código presente; verificar cada procedimiento |
| Aislamiento de datos de inquilinos | Solicitudes de ámbitos de contexto de inquilino. Las tablas API propiedad de los inquilinos utilizan seguridad forzada a nivel de fila según el contrato de migración; la cobertura sigue siendo específica de la mesa y del servicio. | middleware de inquilino y migración de RLS | Código presente; verificar cada servicio y mesa |
| Puerta de flujo de trabajo cerrada por error | La puerta de transición bloquea el contexto del elemento de trabajo faltante, los contratos de paquete no resueltos, la validación de salida fallida, los errores de evaluación y bloquea los resultados antes de avanzar. | puerta de transición | Código presente |
| Aprobación humana | Decision Desk verifica el permiso de decisión, el rol requerido, el estado pendiente, la identidad del creador y el tiempo de vencimiento para las solicitudes de decisión. | enrutador de aprobaciones | Código presente; campos dependientes del productor |
| Cancelación de tiempo de ejecución | Una ruta con ámbito de inquilino indica flujos de trabajo activos o cerrados. El proveedor de identidad y la revocación de tokens posteriores siguen siendo actuadores externos. | cancelación de ejecución | Código presente; distribución de revocación parcial |
| Auditoría y evidencia | Los registros de los trabajadores contienen identidad, política, aprobación, ejecución, hashes y correlación de seguimiento. Evidence Room agrupa registros seleccionados bajo un manifiesto y pruebas de integridad. | eventos de auditoría y contrato de evidencia | Código presente en registros autorizados |
Mantenga explícito el límite del alcance del KLA
KLA evalúa y registra las rutas de acción gobernadas integradas con el Plano de Control KLA. La visibilidad universal de cada identidad, credencial, cuenta de servicio, conector y permiso del sistema de destino permanece fuera de ese alcance.
- Ciclo de vida de la identidad. Los proveedores de identidades empresariales, los directorios de recursos humanos, las autoridades de certificación de cargas de trabajo y los inventarios de cuentas de servicio poseen la creación, el estado y el descubrimiento de identidades.
- Ciclo de vida de las credenciales. Los emisores, las bóvedas, los conectores y los sistemas de destino son propietarios de la emisión, rotación, intermediación y revocación de credenciales posteriores.
- Normalización de derechos. Los contratos KLA aceptan acciones y contextos comerciales flexibles. Los productores siguen siendo responsables del propósito, la cantidad, los datos, las relaciones y los hechos de tiempo normalizados.
- Modelo de autorización. RBAC, ABAC y los patrones de capacidad son opciones de arquitectura. El contrato de póliza del KLA es independiente del modelo.
- Certificación. KLA registra controles y evidencias. La organización define los criterios de revisión, la población completa, las muestras, las conclusiones y cualquier límite de certificación.
- Distribución de revocación. Existe cancelación en tiempo de ejecución. La desactivación de identidades de un extremo a otro, la revocación de tokens, el aislamiento de la red, la cancelación posterior, la compensación y la recuperación requieren acciones externas coordinadas.
Referencias técnicas
Utilice estos contratos públicos para inspeccionar la solicitud gobernada, la decisión, la aprobación, el evento de auditoría terminal y el registro de ejecución conjunta descrito en esta guía.
Fuentes primarias y frescura.
Esta guía fue revisada el 28 de julio de 2026. Los estándares, especificaciones, borradores de directrices e implementaciones locales cambian. Vuelva a verificar la fuente principal y el comportamiento implementado antes de una auditoría, adquisición, decisión legal o de seguridad.
- NIST SP 800-53 Rev. 5, privilegio mínimo AC-6
- NIST SP 800-162, Guía para el control de acceso basado en atributos
- [Referencia estándar y proyecto de control de acceso basado en roles del NIST] (https://csrc.nist.gov/Projects/Role-Based-Access-Control)
- [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)
- 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
- Especificación de autorización del Protocolo de contexto modelo, 25 de noviembre de 2025 (última versión publicada disponible durante esta revisión)
- [Candidato de lanzamiento del Protocolo de contexto modelo 2026-07-28] (https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) (bloqueado el 21 de mayo de 2026; la publicación final estaba programada para el 28 de julio y aún no estaba disponible durante esta revisión)
Preguntas frecuentes
¿Qué es el control de acceso de agentes de IA?
El control de acceso del agente de IA identifica el agente y la carga de trabajo, resuelve los derechos actuales, evalúa la acción y el contexto propuestos, dirige las solicitudes consiguientes a un ser humano elegible y registra la decisión y el efecto.
¿Cómo se aplica el privilegio mínimo a los agentes de IA?
Otorgue únicamente la herramienta, los datos, la acción, la cantidad, el propósito, el entorno y el tiempo necesarios para la tarea aprobada. Vuelva a evaluar esos límites antes de cada acción importante.
¿Debería un agente de IA utilizar RBAC o ABAC?
Utilice RBAC para tareas básicas comprensibles y ABAC para contextos específicos de solicitudes. Una capacidad o token de corta duración puede vincular el recurso final, la acción, la audiencia y el vencimiento.
¿Cuándo debería un agente de IA requerir la aprobación humana?
Requerir aprobación para decisiones que afectan derechos, efectos irreversibles, excepciones de políticas, valores elevados, comunicaciones sensibles, expansión del acceso e incertidumbre inusual. Vincular la decisión a la solicitud exacta y al vencimiento.
¿Con qué frecuencia se deben revisar los derechos de los agentes de IA?
Establezca una cadencia basada en riesgos y active una revisión cuando cambie el propietario, el propósito, el riesgo, las herramientas, los datos, la política, el entorno o el sistema de destino. El acceso a la producción permanente y de alto impacto necesita intervalos más cortos.
¿Cómo encuentro cuentas de servicio de agentes de IA?
Concilie el registro del agente con IAM en la nube, aplicaciones de proveedores de identidad, plataformas de carga de trabajo, CI, bóvedas, secretos, puertas de enlace API, servidores MCP, conectores, registros del sistema de destino y salida de red.
¿Qué debería detener la revocación de emergencia?
Detenga el trabajo activo y en cola, revoque identidades, tokens, secretos, sesiones, subvenciones delegadas y capacidades, aísle las rutas restantes, concilie los efectos secundarios, repare la causa y apruebe la recuperación.
¿Qué evidencia demuestra que el control de acceso de los agentes de IA funcionó?
Une identidad y autenticación, derechos efectivos, entradas y resultados de políticas, decisión humana, recibo de ejecución, cambios en el ciclo de vida, revocación, verificaciones de acceso residual y recuperación bajo identificadores estables.
Conclusiones clave
El control de acceso eficaz de los agentes de IA comienza con una población de identidades completa, derechos limitados y revisables, cuatro resultados de tiempo de ejecución explícitos, aprobación humana elegible, revocación de emergencia probada y evidencia unida. Utilice la [lista de verificación de revisión de derechos] (/downloads/ai-agent-entitlement-review-checklist.md), profundice la arquitectura con la [referencia de IAM] (/blog/ai-agent-identity-access-management-reference-architecture), audite los derechos con la [guía de permisos] (/blog/ai-agent-permissions) e implemente los campos de eventos portátiles en el [Esquema de registro de auditoría del agente AI] (/resources/ai-agent-audit-log-schema).