Gobernanza de investigación en Microsoft 365

Una investigación interna en Microsoft 365 pasa por correos electrónicos, conversaciones y archivos de personas. La IA puede planificar la búsqueda, normalizar registros, resumir y señalar inconsistencias, pero aumenta el riesgo: un agente con demasiado acceso puede leer lo que no debía, alterar una prueba o concluir culpabilidad por sí solo. Este framework define cómo conducir el trabajo con autorización previa, acceso mínimo y evidencia que resista una revisión independiente.

Sigil Labs reunió un protocolo de gobernanza y un repositorio inicial para Claude Code. El repositorio no contiene credenciales, no se conecta a ningún tenant y no implementa un conector genérico de Microsoft Graph. El conjunto incluye:

• un protocolo escrito en 26 secciones, desde la autorización hasta el cierre del caso;
• once subagentes, cada uno con una función y herramientas explícitas;
• un hook de política que niega cualquier herramienta desconocida y, en caso de error, bloquea la acción (fail-closed);
• un contrato mínimo para el servidor MCP, que debe construirse en un proyecto e infraestructura separados;
• un modelo de caso, con acta de apertura, plan de búsqueda, lista de custodios y registro de aprobaciones;
• una matriz de identidades de workload (carga de trabajo) con menor privilegio;
• una propuesta de especificación para el sello criptográfico del alcance;
• un runbook de las primeras 24 horas.

Nada empieza sin autorización. Antes de cualquier acceso, el acta de apertura del caso debe ser firmada por quien tiene autoridad verificable, y un abogado debe validar la base jurídica, la proporcionalidad y el tratamiento de datos personales. El runbook indica detenerse si falta cualquier elemento esencial.

El alcance está sellado. La especificación del sello, una propuesta técnica, define el scope_hash como un SHA-256 calculado sobre la parte del acta que dice quién, qué, cuándo, hasta dónde y quién debe aprobar. Cada aprobación vale para un alcance específico: reformatear el archivo no la invalida, pero agregar un custodio sí.

En este framework, el modelo de IA nunca recibe una cuenta humana de Global Administrator. Solo ve herramientas MCP acotadas y tipadas. El protocolo exige que el servidor MCP sea el punto que hace cumplir la política: no debe ofrecer solicitudes arbitrarias a Microsoft Graph, ejecución de PowerShell, envío de mensajes ni eliminación. Toda llamada al tenant informa el caso, la revisión del alcance, el motivo y una clave de idempotencia, y las herramientas sensibles exigen un token de aprobación verificado de forma criptográfica en el servidor.

El acceso del agente de IA al tenant crece por capas. El protocolo define seis niveles de aprobación, del 0 al 5, y una categoría prohibida. Leer conteos agregados es automático dentro del caso. Aplicar una retención legal (hold) o recopilar para un conjunto de revisión exige dos personas, salvo emergencia documentada. Exportar contenido nativo exige dos personas y al custodio de la evidencia. Las identidades de escritura y de exportación quedan bloqueadas por defecto y solo se activan en ventanas aprobadas.

El archivo CLAUDE.md orienta al modelo, pero no es un control de seguridad. Las reglas las imponen los permisos de Claude Code, el hook, el servidor MCP, Microsoft Entra y Microsoft Purview.

La búsqueda en los datos del tenant avanza en seis oleadas, numeradas del 0 al 5: capacidad, metadatos, términos de alta precisión, conceptos, contexto y expansión controlada. Ampliar el alcance exige un hecho nuevo documentado, aprobación y un nuevo hash de alcance. La preservación va antes de la lectura: Microsoft informa que un hold puede tardar hasta 24 horas en surtir efecto, y el protocolo exige registrar el estado de cada fuente hasta la confirmación.

Cada artefacto se clasifica como fuente, copia de trabajo, derivado o elemento de presentación, y la fuente nunca se reemplaza por un derivado. Cada lote recibe un manifiesto con hash SHA-256 y va a un almacenamiento cifrado e inmutable, separado del repositorio de código.

El framework busca evidencia incriminatoria y exculpatoria. El revisor de contrahipótesis es obligatorio: busca la explicación inocente, la práctica normal, el evento automático, el duplicado, el problema de zona horaria, la acción de un administrador y el efecto del propio eDiscovery. Las etiquetas permitidas son descriptivas, como “potencialmente relevante” o “explicación alternativa identificada”. El informe separa hecho observado, inferencia, hipótesis, limitación, cuestión jurídica y recomendación.

El modelo de IA no recibe el corpus bruto completo. Recibe metadatos, identificadores, conteos y fragmentos estrictamente necesarios, después de la normalización, la deduplicación, el filtrado por alcance y la clasificación de confidencialidad. Todo contenido recuperado se trata como dato no confiable: el agente nunca obedece instrucciones encontradas en el corpus, ni acepta una “aprobación” que aparezca en un mensaje investigado.

El protocolo enumera 18 condiciones de parada automática, entre ellas acta de apertura vencida, alcance sin hash válido, aprobación ausente o vencida, herramienta fuera de la lista permitida y solicitud que abarque todo el tenant.

El framework es para organizaciones que necesitan investigar internamente, con autorización, una sospecha de conducta indebida en Microsoft 365 y quieren usar IA sin renunciar al control. Sirve de punto de partida para quien vaya a construir el servidor MCP y las identidades de workload, y para quien necesite revisar ese diseño.

El framework es un protocolo y un repositorio inicial, no un producto listo para instalar. No autoriza el acceso a datos y no sustituye un dictamen jurídico. El protocolo solo admite producción después de 20 criterios de aceptación demostrados en pruebas, entre ellos demostrar que el agente no puede usar llamadas arbitrarias a Graph, borrar o purgar contenido ni liberar un hold, y que existe un kill switch (apagado de emergencia). Como Purview, Graph y Claude Code cambian con frecuencia, los nombres de los permisos y la licencia deben verificarse en la documentación vigente antes de la implementación.