Identidad, permisos y auditoría de agentes de IA: un registro útil

Empieza con un registro que se pueda revisar

Para revisar la identidad, los permisos y la auditoría de agentes de IA, necesitas reconstruir una acción concreta: quién la pidió, qué identidad actuó, con qué autoridad y qué ocurrió realmente. Una respuesta convincente del agente o una conexión autorizada no resuelven todas esas preguntas.

Ejemplo ilustrativo de cinco campos: Marta pide leer «Informe trimestral» y preparar una respuesta para revisarla, sin enviarla. La tabla muestra una plantilla manual que un equipo podría elaborar; no representa una exportación nativa de FoneClaw ni de Microsoft Entra.

La solicitud agrupa el objetivo; los identificadores de acción separan la lectura de la preparación del texto. Si ambas tienen resultados distintos, el registro no debe resumirlas como un único “completado”. Puedes anotar “lectura verificada; texto propuesto para revisión; envío no solicitado”.

El nombre en un chat identifica una petición, pero no autentica por sí mismo a quien ejecuta. La referencia de credencial permite localizar una conexión sin divulgar el secreto. El alcance limita lo que puede intentarse; la aprobación vincula una decisión con una persona y una acción particular.

En el último campo, conserva la operación intentada, su estado y la evidencia disponible. Una propuesta de respuesta en la conversación no demuestra que exista un borrador guardado en un buzón. Si solo se generó texto, registra precisamente eso. El objetivo es permitir la revisión sin copiar el documento completo ni acumular contenido privado innecesario.

Elige la identidad y el alcance empresarial

La documentación de autorización de agentes de Microsoft Entra distingue permisos delegados y permisos de aplicación. Con acceso delegado, el agente actúa en nombre de un usuario y dentro de los permisos aplicables. Con permisos de aplicación, la concesión administrativa permite actuar como aplicación sin depender de una sesión de usuario para cada operación.

Este es un ejemplo específico de Entra, no un comportamiento universal de todos los agentes. Sus restricciones sobre roles y permisos de API de alto privilegio también deben revisarse antes de diseñar el acceso. No elijas una identidad administradora amplia para evitar decidir qué permiso necesita cada tarea.

Volviendo al documento, leerlo para proponer texto no justifica escritura, envío ni acceso a todos los documentos de la organización. Delimita el recurso permitido y la operación, y comprueba quién puede ampliar ese alcance. El solicitante, la identidad técnica y quien concede el permiso pueden ser tres sujetos distintos.

También importa qué sistema protege el recurso. Un rol sobre recursos de Azure, un rol de directorio y un permiso de Microsoft Graph no son intercambiables. Que una identidad tenga autoridad en uno no demuestra acceso al otro. Registra dónde se concede el permiso y qué recurso cubre, para que la revisión no se limite al nombre del rol.

El consentimiento de una conexión no aprueba cada acción posterior. Si después se solicita enviar la respuesta, revisa remitente, destinatario y contenido como una nueva decisión. Una clave de API autentica el acceso a un servicio; no sustituye propietarios, alcances y controles de autorización.

Identifica al responsable de la conexión y revisa su vigencia cuando la política lo exija. Seguridad de agentes de IA empresariales: cómo evaluar un agente local en el teléfono desarrolla los requisitos corporativos más amplios sin confundirlos con la configuración de una herramienta móvil.

Reúne por separado la identidad y el resultado

En Microsoft Entra, los registros de agentes e inicios de sesión ayudan a relacionar una actividad con su identidad. Los eventos de auditoría incluyen agentType y blueprintId. Las actividades de blueprint aparecen como eventos de aplicación, las identidades de agente como eventos de entidad de servicio y las cuentas de usuario del agente como eventos de usuario.

Con al menos el rol Reports Reader, un revisor puede ir en Entra ID a Supervisión y estado > Registros de inicio de sesión y aplicar los filtros de agentes descritos por Microsoft. Las consultas de registros de agentes mediante Microsoft Graph que documenta esa guía usan /beta; revisa sus condiciones antes de incorporarlas a un proceso estable.

Un inicio de sesión correcto demuestra autenticación para ese acceso, no que el documento se haya leído, editado o enviado. Correlaciona la identidad y el recurso con la operación registrada por la aplicación de destino. Utiliza identificadores de solicitud o correlación cuando estén disponibles; si los sistemas no comparten uno, deja documentado cómo estableciste la relación.

• Identidad: quién actuó y a qué conexión corresponde.
• Recurso: documento, calendario o cuenta de destino.
• Tiempo: momento del intento y de la observación, con zona horaria.
• Operación: lectura, creación, preparación o envío concreto.
• Resultado: evidencia de éxito, denegación o estado todavía desconocido.

Una coincidencia horaria por sí sola puede ser insuficiente cuando hay tareas simultáneas. Conserva el identificador del objeto o la referencia de operación que permita distinguirlas. Si falta evidencia en el destino, registra qué comprobación está pendiente; no completes ese vacío con la afirmación del modelo.

Limita quién puede consultar las evidencias y define su conservación según la política real de la organización. Los registros de identidad no garantizan la cobertura de cada acción de negocio, y reunirlos no crea automáticamente un archivo inalterable ni una certificación de cumplimiento.

Registra éxito, denegación, aprobación pendiente y resultado incierto

Los siguientes registros son propuestas de revisión, no resultados de pruebas. Utilizan la misma separación entre autoridad concedida, aprobación de la acción, intento y efecto observado. En cada uno, mantén las referencias de actor y conexión sin copiar credenciales.

Lectura completada. Para REQ-042 y ACT-042-01, el alcance autoriza leer el documento elegido. La aprobación aplicable está resuelta y la aplicación documental aporta evidencia de esa lectura. Registra “lectura verificada” con su referencia y hora. Si ACT-042-02 solo generó una respuesta en la conversación, añade “texto propuesto, sin envío”. La lectura satisfactoria no amplía el permiso a modificar el archivo.

Escritura pendiente de aprobación. Para REQ-043 y ACT-043-01, hay una propuesta de creación con sus datos definidos, pero la política exige una decisión que todavía no existe. Registra “pendiente de aprobación; ejecución no confirmada”. La solicitud del usuario y la propuesta del agente no equivalen a la aprobación requerida. El siguiente paso es decidir sobre esa acción concreta o cancelarla, no informar que el objeto está creado.

Acción denegada. Para REQ-044, una herramienta deshabilitada o un permiso insuficiente bloquea el intento. Conserva la causa y el recurso afectado. Si además inspeccionaste el destino y no cambió, puedes registrar ambas observaciones. Si no lo revisaste, escribe “denegación observada; destino pendiente de comprobar”, sin transformar la denegación en prueba de todo el estado posterior.

Escritura con resultado incierto. Para REQ-045, el proceso se interrumpe después de iniciar una creación y antes de obtener confirmación. Registra “intento iniciado; resultado desconocido”, junto con el último paso observado. No repitas automáticamente. Busca el objeto en el destino y comprueba sus datos; si ya existe, continúa desde ese resultado. Si no puedes resolver la incertidumbre, conserva el bloqueo de la repetición hasta revisarlo.

Si una solicitud contiene varios pasos, conserva un estado por acción. Una creación completada y un envío pendiente no deben convertirse en “todo falló” ni “todo terminó”. Esta distinción permite recuperar trabajo sin duplicar efectos.

Aplica las mismas preguntas al teléfono

En FoneClaw puedes aplicar estas preguntas a una consulta sencilla: “¿Cuánta batería queda y está activo el ahorro de energía?”. Nuestra herramienta device_battery_status es de solo lectura y no cambia ajustes. Anota solicitante, referencia de configuración del proveedor, herramienta habilitada, política aplicable y datos devueltos por Android. Es una lista manual, no un formato nativo de exportación de auditoría.

Una escritura exige más datos. Como ejemplo propuesto, el usuario especifica: “Crea Revisión de presupuesto el 15 de octubre de 2026, de 10:00 a 10:30, con aviso diez minutos antes”. Antes de ejecutar calendar_create_event, confirma el calendario previsto y cualquier dato que falte. Si no se indicó el aviso, recábalo; no lo inventes. La zona horaria del dispositivo también importa.

Compara tres estados: los horarios solicitados, los horarios efectivos devueltos como actualStart y actualEnd, y el evento que puedes abrir en el calendario. Comprueba título, inicio, fin, aviso y destino. Una frase del modelo diciendo que terminó no sustituye el resultado de la herramienta ni esa inspección.

La herramienta de calendario está clasificada de forma predeterminada para requerir aprobación por su efecto externo, mientras la lectura de batería tiene aprobación automática predeterminada. El comportamiento efectivo depende de Tool Approval Mode y de los ajustes por herramienta. Las funciones de FoneClaw describen nuestras acciones Android y sus controles.

Separa el permiso Android, la habilitación de la herramienta y la credencial del proveedor del modelo. Este interpreta y planifica; las herramientas ejecutan los pasos compatibles. Si utilizas un proveedor en línea, puede procesar el contexto suministrado. La ejecución en el teléfono no demuestra procesamiento íntegramente local. Este ejemplo tampoco implica integración con Entra: aplica las preguntas de revisión a otro entorno.

Comprueba las denegaciones y retira accesos innecesarios

Como ejercicio propuesto de bajo riesgo, registra la configuración inicial, deshabilita una herramienta de lectura que puedas prescindir temporalmente y solicita esa misma consulta. Comprueba que no se ejecute por esa vía y que se informe el bloqueo. La respuesta esperada es una limitación observable, no un dato inventado que simule una lectura.

Para una consulta de batería, no esperes que el porcentaje quede congelado: puede variar con el uso normal. Lo que verificas es que la herramienta deshabilitada no haya ejecutado la consulta ni modificado ajustes. Anota el resultado real y restaura la habilitación únicamente si sigue siendo necesaria. No presentes este ejercicio como prueba de todos los permisos del dispositivo.

Revisa periódicamente identidades, conexiones y herramientas sin uso. Retira el acceso correspondiente en el sistema que lo gobierna y comprueba la respuesta de una nueva operación inocua. Deshabilitar una herramienta no revoca automáticamente una credencial del proveedor, y retirar un permiso Android no elimina una concesión empresarial. Documenta qué control cambiaste y quién lo hizo.

Revocar acceso futuro no deshace un evento creado ni retira un mensaje ya enviado. Si necesitas corregir un efecto anterior, inspecciona el destino y realiza una acción separada con autoridad suficiente. Antes de repetir una escritura incierta, comprueba si ya existe; conserva el identificador del objeto y evita duplicados.

Rota una credencial si quedó expuesta y revisa excepciones de aprobación que ya no correspondan. Si una habilidad añade capacidades, Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real ayuda a evaluar su autoridad. Si las instrucciones persistentes son el riesgo, Envenenamiento de memoria de agentes IA en móviles trata ese caso.

Cierra la revisión con una referencia al acceso retirado, la comprobación posterior y cualquier efecto pendiente. Mantén el registro accesible solo para quienes lo necesitan y aplica la política de conservación correspondiente.