🛡️ Beak AI Security – Notas de Versión

Registro de cambios para aplicación de políticas, escaneo y mecanismos de control.

Versión 6.0.0

Incorpore un agente en siete pasos y observe cómo llega el primer evento gobernado

Agent Registry → Onboard agent ahora guía a un operador desde el lugar donde se ejecuta el agente hasta el primer evento que Beak registra para él: seleccione la plataforma o el marco de trabajo, elija uno de los tres niveles de integración, registre el agente con un propietario responsable, obtenga las credenciales que el nivel requiere, copie el fragmento verificado para ese marco de trabajo y espere el primer evento gobernado. Consulte The onboarding wizard.

• Solo se pueden elegir los niveles accesibles. Un nivel que el protocolo propio del marco de trabajo no puede admitir aparece deshabilitado con la razón correspondiente; un nivel para el cual Beak no ha implementado la parte receptora aparece deshabilitado e indica la brecha. Ninguno se deja en blanco ni en gris sin una explicación.
• Es obligatorio indicar un propietario. Cada agente incorporado mediante el asistente nombra a la persona responsable. Los agentes registrados a través de la API pueden omitirlo en esta versión; la consola indica la ausencia ("no owner recorded") en lugar de mostrar un campo en blanco.
• Las credenciales se emiten durante el flujo y se muestran una sola vez: un token de inscripción para Full Gateway en un agente que Beak no aloja, o un token de intermediario para un nivel de middleware o webhook.
• "Incorporado" significa observado. El paso de verificación reporta el agente como integración pendiente hasta que Beak registra su primer evento, y muestra una escala de cobertura con cada peldaño ausente etiquetado.
• Las páginas de plataforma enlazan directamente al asistente con la plataforma ya seleccionada.

Nota: Ningún agente existente cambia. El selector de límites manual sigue disponible para fuentes que el catálogo no incluye. Una sonda sintética de "enviar evento de prueba" está planificada junto con el receptor genérico de tool-hook; actualmente el paso de verificación espera tráfico real.

Tres niveles de integración, un límite de tool-hook y concesiones que se registran solas

Un agente de cualquier plataforma ahora se integra en uno de tres niveles: Full Gateway, Inference hook o Tool hook, y GET /aisecurity/agents/onboarding-catalog indica, por marco de trabajo y plataforma, qué niveles puede alcanzar y cómo. Un nivel que el protocolo propio del marco de trabajo no puede admitir se reporta como inalcanzable con la razón; un nivel para el cual Beak no ha implementado la parte receptora se reporta como no disponible aún. Ninguno se deja en blanco. Consulte Governing an Agent from Any Platform.

• Nuevo límite tool.hook. La plataforma del agente consulta a Beak antes de ejecutar una herramienta — lo que la detección de amenazas externas de Copilot Studio siempre ha hecho — es ahora un límite propio, distinto de hub.tools, donde Beak procesa la llamada y ve su resultado. El nivel brokered de un agente de Copilot Studio es ahora una concesión registrada, y cualquier plataforma que registre a Beak como su tool hook obtiene el mismo nivel de la misma forma.
• Las concesiones se registran solas. Una clave virtual vinculada en Beak AI Gateway, una conexión MCP propiedad del agente creada en Beak AI Hub, y la primera llamada de herramienta de Copilot Studio inspeccionada registran automáticamente su límite en el perfil de gobernanza del agente. La advertencia anterior de que la concesión era una acción del operador ya no aplica.
• Las conexiones de Hub propiedad del agente se aplican, no solo se declaran. Cada tools/call en una conexión propiedad de una identidad de agente se autoriza contra los alcances de ese agente antes de que Beak AI Hub la reenvíe. Una denegación se devuelve al cliente MCP como un error JSON-RPC con el código de razón. La verificación falla de forma cerrada: si no se puede contactar con Beak AI Security, la llamada se rechaza en lugar de reenviarse.
• Los despachadores de herramientas externos necesitan un token de intermediario. Los llamantes fuera del clúster de Beak deben presentar un token bkr_ en /aisecurity/tools/authorize; el token fija el tenant y el encabezado tenantid se ignora. Los operadores acuñan y revocan tokens en /aisecurity/brokers/tokens con agents:keys. Los propios servicios de Beak no se ven afectados.

Nota: Ningún agente existente cambia su gobernanza al actualizar. Los agentes de Copilot Studio obtienen una concesión tool.hook registrada en su próxima llamada inspeccionada, lo que mantiene su nivel donde estaba. La autorización de herramientas en Hub se aplica solo a conexiones propiedad del agente; las conexiones de usuario y equipo se comportan como antes. El reporte de concesiones de Hub está desactivado hasta que un operador configure SECURITY_SERVICE_URL, AGENT_GOV_ENVIRONMENT y AGENT_GOV_WORKLOAD_PRIVATE_KEY_PEM en Beak AI Hub y aprovisione su clave pública como ancla de confianza en Beak AI Security.

Encuentre los agentes en Bedrock, Agentforce, OpenAI y A2A — no solo los de Microsoft

Beak AI Security and Governance ahora puede enumerar los agentes que existen en Amazon Bedrock, Salesforce Agentforce, OpenAI Assistants y A2A, y colocarlos en el Agent Registry antes de que ninguno haya llamado a Beak. Anteriormente solo Copilot Studio (a través de Power Platform) y Agent 365 podían enumerarse, por lo que "qué agentes existen en mi organización" era una pregunta que podía responderse para el ecosistema de Microsoft y quedaba sin respuesta en cualquier otro lugar — un agente en Bedrock era invisible hasta que casualmente realizaba una llamada.

Cada plataforma es una nueva tarjeta en Integrations → Agent Platforms, configurada con sus propias credenciales, y Test connection enumera de verdad en lugar de solo verificar que la credencial se autentica. Consulte Integrations.

• Desactivado de forma predeterminada, y nada cambia al actualizar. No se crea ninguna credencial y no se ejecuta ningún descubrimiento hasta que un administrador configure una plataforma. Las integraciones, agentes y gobernanzas existentes no se modifican.
• Los agentes descubiertos son candidatos, no inventario gobernado. Cada agente encontrado llega como discovered en el nivel registered — solo inventario e identidad. No se aplica nada hasta que lo incorpore, y aparecer en el listado de un proveedor no es una decisión de gobernar al agente.
• Que un proveedor llame proxied a su agente no eleva su nivel. Las cuatro plataformas describen así a sus agentes de forma habitual. Beak lo ignora: el nivel se declara desde la fuente, nunca se infiere de cómo un proveedor se describe a sí mismo, porque un nivel afirmado en una sugerencia es una señal de cumplimiento sin respaldo.
• A2A es la única plataforma que no necesita secreto. Una tarjeta Agent2Agent puede publicarse sin autenticación, por lo que el token portador es opcional allí y obligatorio en los demás casos.

Requisitos: un principal de AWS con bedrock:ListAgents y bedrock:GetAgent; una aplicación conectada de Salesforce con el alcance api; una clave de API de OpenAI; o, para A2A, la URL base de cada agente cuya tarjeta debe leerse. Las credenciales se cifran en reposo con la misma clave por tenant que cualquier otra integración.

Nota: El descubrimiento lee el listado de un proveedor — no coloca a Beak en la ruta de llamadas de ningún agente, y no puede hacerlo. La autorización de herramientas, la inspección de prompts y completados, y la atribución de costos aún requieren que el agente enrute a través de Beak; consulte Governing an Agent from Any Platform.

Las sesiones de inicio de sesión unificado ya no expiran tras 15 minutos

Si accede a Beak AI Security mediante inicio de sesión unificado, su sesión ahora dura lo que permita su sesión de inicio de sesión único — hasta 8 horas en un tenant estándar — en lugar de redirigirle a la página de inicio de sesión aproximadamente cada 15 minutos. La solicitud de renovación era rechazada anteriormente por el navegador en direcciones con marca de tenant — su propio dominio corporativo, o una dirección <tenant>.beakops.com — por lo que solo los usuarios en la dirección de producto predeterminada no se veían afectados.

Activado de forma predeterminada; sin configuración, y sin cambios en los tiempos de sesión o inactividad de su tenant. El inicio de sesión con contraseña en la página de inicio de sesión propia de Beak AI Security no se ve afectado.

Consulte Platform Administration release notes.

Gobierne un agente construido sobre cualquier marco de trabajo y vea exactamente qué está cubierto

Un agente escrito en LangGraph, CrewAI, LangChain.js, Mastra, o sin ningún marco en particular, puede ahora incorporarse a su inventario gobernado con una sola llamada al inicio, usando los nuevos Beak agent SDKs — beakagentidlib para Python, @beak/agent-identity para Node. Luego aparece en Agent Governance junto a los agentes que construyó en Beak. Anteriormente las únicas formas de hacerlo eran un conector de tiempo de ejecución o que un operador inscribiera el agente manualmente, por lo que el equipo no tenía ninguna vía de autoservicio para su propio agente. Consulte Governing an Agent from Any Platform.

Junto con esto, Agent Governance ahora reporta qué planos de gobernanza se aplican realmente a cada agente, en lugar de una sola etiqueta. Se rastrean siete planos — inventario, identidad, autorización de herramientas, política de tiempo de ejecución, inspección de prompts, escaneo de completados y costos — y cada uno está presente solo por un límite que el tráfico del agente realmente cruza.

• Lo que Beak gobierna sigue la integración del agente, no su documentación. El escaneo de completados y la atribución de costos solo están disponibles cuando las llamadas al modelo se enrutan a través de Beak AI Gateway, porque no hay otro punto en el que Beak vea la respuesta o la factura. Registrar, adoptar o reconfigurar un agente no puede generarlos.
• Un agente puede solicitar, pero solo Beak puede conceder. Un agente declara los límites que pretende cruzar; estos aparecen como pending y no cambian nada hasta que Beak emite la credencial que los hace reales. Sin esa separación, un agente podría afirmar su propia gobernanza — nombrar un límite y que el panel reporte una cobertura que nada estaba ejecutando.
• Una combinación que no coincide con ningún perfil predefinido se reporta como custom, no se redondea. Un agente que posee seis de los siete planos se describe con honestidad en lugar de redondearse al nombre de nivel más cercano. Lea la matriz de capacidades; una insignia de nivel es un resumen y para un agente custom es uno que ninguna tabla de búsqueda puede expandir.
• Una fuente no reconocida se sitúa en el nivel base. Un agente cuyo origen Beak no puede identificar se reporta como registered — solo inventario e identidad. El valor predeterminado subestima intencionalmente.

Nota: Nada cambia para ningún agente existente al actualizar, y la gobernanza de ningún agente se reduce. Los planos que cada agente ya tenía son los que conserva; lo nuevo es que se declaran individualmente en lugar de estar implícitos en una etiqueta. El registro automático para agentes sincronizados por conector está desactivado hasta que un operador configure AGENT_GOVERNANCE_SECURITY_URL en Beak AI Agent Runtime.

Nota: Desde la entrada anterior, gateway.llm, hub.tools, inference.hook y tool.hook son registrados por el servicio que observa el cruce del límite; solo registry.only lo establece un operador. Un límite pending ahora significa que el agente aún no lo ha cruzado, no que alguien deba registrarlo — el paso de verificación del asistente de incorporación espera exactamente ese primer cruce.

El registro de auditoría ahora registra quién era un agente y cómo actuaba — y lo demuestra

Un veredicto de moderación solía registrar qué se decidió. Ahora también registra qué principal de agente fue el objeto de la decisión y si ese agente actuaba de forma autónoma o bajo autoridad delegada de una persona — y ambos están dentro de la cadena de hash resistente a manipulaciones, no meramente almacenados junto a ella. Reatribuir una decisión autónoma como interactiva, o reasignar un veredicto a un agente diferente, rompe la verificación de todos los eventos posteriores. Consulte Audit Log.

La columna Mode en el Execution Ledger muestra esto por fila, y un filtro de modo divide el libro de registros en decisiones autónomas y delegadas. La vista autónoma es la que una revisión de incidentes quiere primero: responde a "qué hicieron los agentes mientras nadie miraba", algo que el resto del registro no puede aislar.

• El modo se declara cuando se emite una credencial, nunca se infiere de la solicitud. Un modo adivinado podría derivarse de forma diferente más adelante; uno declarado es una afirmación que alguien hizo en su momento, lo que lo convierte en evidencia.
• El modo y el disparador son independientes. Un agente puede actuar de forma autónoma y con autoridad delegada de una persona — un trabajo programado que lleva la autoridad de un usuario es una forma real — por lo que una fila puede mostrar OBO y aun así nombrar un disparador.
• El libro de registros es de solo anexión en la base de datos. Editar las columnas atestiguadas, la cadena o la versión de esquema de una fila se rechaza directamente, al igual que eliminar una fila. Las anotaciones del revisor siguen siendo editables, porque nunca formaron parte de la afirmación atestiguada.
• Los veredictos simultáneos ya no colisionan. Las ráfagas de escaneos simultáneos en un tenant ocupan cada una una posición distinta en la cadena; anteriormente podían compartir una, lo que hacía que una cadena íntegra se reportara como rota.

Nota: Nada sobre la aplicación de políticas cambia. Esto es lo que se registra sobre una decisión y cuán difícil resulta alterarlo posteriormente.

Vea cuántas decisiones nunca fueron inspeccionadas

La inspección de contenido falla de forma abierta intencionalmente: si el almacén de políticas no es accesible, las solicitudes continúan en lugar de detener a todos los agentes del tenant. Hasta ahora eso era invisible — tal decisión se reporta como permitida y conforme, indistinguible en el protocolo de una aprobación limpia y de un tenant sin políticas configuradas.

Agent Governance ahora muestra un recuento acumulado de decisiones que procedieron sin inspección de políticas, y un filtro Uninspected only en el Execution Ledger abre las decisiones detrás de ese número.

Advertencia: Una decisión no inspeccionada no es una decisión verificada. La solicitud no fue bloqueada, pero ningún mecanismo de control se aplicó a ese tráfico.

• El recuento muestra cero cuando corresponde. Si la inspección se ha mantenido, el panel lo indica claramente en lugar de mostrar un widget vacío.
• Un recuento fallido dice "unavailable", nunca cero. Reportar cero decisiones no inspeccionadas porque la propia consulta falló sería el mismo tipo de silencio que esto existe para corregir.
• Se combina con el filtro de modo, por lo que "autónoma y no inspeccionada" es una sola consulta.

Incorpore bajo la gobernanza de Beak un agente que Beak no construyó

Un agente de IA que se ejecuta en otro lugar — Amazon Bedrock, Microsoft Copilot Studio, Salesforce Agentforce, un par A2A, o un script que usted aloja — puede ahora convertirse en un principal gobernado en su tenant. Obtiene una identidad de Beak, aparece junto a sus propios agentes en Agent Governance, y está sujeto a las mismas políticas, concesiones de autonomía y registro de auditoría. Anteriormente un agente externo podía verse en el Agent Registry y gobernarse en el límite de herramientas, pero no podía tener una identidad de Beak en absoluto — por lo que no podía recibir una credencial, una concesión de autonomía, ni su propia línea en el registro de auditoría. Consulte Agent Governance.

Una nueva pestaña Enrolment es donde se hace esto. Acuña un token de un solo uso que nombra al agente, su propietario responsable, su techo de alcance y de dónde proviene; el agente presenta ese token con prueba de que posee su propia clave de firma. Beak almacena solo la mitad pública — ninguna parte de Beak guarda jamás la clave privada de un agente externo.

Advertencia: El token se muestra una sola vez. Beak almacena solo un hash, por lo que no puede recuperarse posteriormente — cópielo antes de cerrar el diálogo. Es de un solo uso, y acuñar o revocar uno requiere agents:authorize, el mismo permiso que conceder autonomía.

• Un agente inscrito tiene identidad, no autoridad — inmediatamente después de inscribirse puede demostrar quién es y nada más. Una solicitud de credencial se rechaza hasta que un humano le conceda autonomía desde la pestaña Identities. Esa es la misma regla bajo la que ya viven todos los agentes construidos en Beak: el origen de un agente se registra como procedencia, y no cambia cuánto se confía en él.
• Cada token se conserva, incluidos los usados y revocados — porque "qué persona autorizó la existencia de este agente, y cuándo" es una pregunta de auditoría. Un token consumido enlaza con la identidad que produjo. Revocar solo se ofrece para un token que nadie ha usado aún; si el agente ya se ha inscrito, revoque la identidad en su lugar.
• Procedencia en cada identidad — el detalle de identidad ahora muestra de dónde proviene un agente, si posee su propia clave de firma, su id en su propia plataforma, y la huella digital de su clave y la ventana de validez. Nada de esto era visible antes.
• Buscar, filtrar, ordenar y exportar en todo el tenant — no solo la página en pantalla, tanto en las pestañas Enrolment como en Identities.

Nota: Nada cambia para ningún agente existente al actualizar. Los agentes construidos en Beak siguen registrando su identidad automáticamente, y ningún agente externo se inscribe hasta que alguien acuña un token para él — no hay importación masiva, porque inscribir un agente es una decisión que una persona toma sobre un agente a la vez. Los agentes ya descubiertos a través de Power Platform o Agent 365 permanecen exactamente como están: aún gobernados, aún no son principales, hasta que los inscriba.

Las integraciones tienen su propio menú, agrupadas por lo que hacen

Los conectores ya no son una pestaña dentro de Settings. Administration → Integrations es ahora un catálogo de los nueve — hooks de inferencia de Anthropic, Microsoft Copilot Studio, Power Platform, Agent 365, Defender XDR, Sentinel, Defender for Cloud Apps, Purview y Teams — cada uno con el logotipo de su proveedor, una descripción de una línea de lo que hace y su estado de conexión actual en la tarjeta. Anteriormente estaban en un largo desplazamiento bajo Settings → Integrations, que solo podía usarse si ya sabía lo que contenía. Consulte Integrations.

• Agrupados de dos formas — By type agrupa por resultado (AI Platforms, Agent Platforms, Security Operations, Data Governance, Notifications), para que pueda encontrar el conector que reenvía bloqueos a un SIEM sin saber que se llama Sentinel. By vendor agrupa por proveedor, para ver todo lo que Beak hace con el ecosistema de un proveedor. Ambas muestran las mismas nueve integraciones.
• Búsqueda en el catálogo — Coincide con el nombre, proveedor, grupo y descripción de una integración, por lo que buscar audit encuentra Microsoft Sentinel.
• Estado de conexión en la tarjeta — Connected, Disabled o Not connected, leído en tiempo real por integración. Disabled significa que hay una credencial almacenada y la integración está desactivada — el estado a buscar cuando algo que antes despachaba se ha silenciado. Cuando el estado no puede leerse, la tarjeta no muestra nada en lugar de indicar Not connected.
• Una página por integración — Seleccionar una tarjeta abre la configuración de esa integración en su propia página, con un enlace a la pantalla a la que alimenta sus datos — el Agent Registry para Power Platform, Incidents para Defender XDR, el Registro de Auditoria para Sentinel.

Nota: Nada cambia en ninguna integración configurada al actualizar — las mismas credenciales, el mismo despacho, los mismos permisos (integrations:read para ver, integrations:update para guardar). Los enlaces existentes a Settings → Integrations redirigen a la nueva página, por lo que los marcadores y enlaces en otras pantallas siguen funcionando. El menú aparece para cualquiera que tenga integrations:read o settings:read, porque los conectores detrás de él se aplican con ambos — así ningún administrador que pudiera configurar una integración antes del cambio pierde su ruta hacia ella. Las tarjetas que no puede configurar están ocultas.

Encuentre e incorpore agentes desde Security, y vea qué aplica realmente para cada uno

Ahora puede descubrir agentes de Copilot Studio y adoptarlos sin salir de Beak AI Security, y cada agente en el registro indica qué está aplicando para él. Anteriormente el registro mostraba solo los agentes que alguien ya había adoptado, y no distinguía un agente cuyos prompts Beak inspecciona de uno donde Beak es llamado únicamente en el límite de herramientas.

La nueva columna Coverage nombra esa diferencia: Inference cuando las llamadas al modelo del agente viajan a través de Beak y sus prompts y completados son inspeccionados; Tool hook only cuando la seguridad externa de Copilot Studio llama a Beak para ejecuciones de herramientas y nada más — el agente se ejecuta en la nube de Microsoft y sus conversaciones nunca llegan a Beak; Observed only cuando el agente está en el inventario y nada aplica para él. Filtre por cobertura para encontrar el tercer grupo. Consulte Agent Registry.

Advertencia: Incorporar un agente no cambia su cobertura, y adoptar un agente Tool hook only no comienza a inspeccionar sus prompts. La cobertura sigue cómo el agente llega a Beak, por lo que alcanzar Inference es un cambio en cómo se despliega el agente y no una configuración. Beak marca la cobertura solo desde una ruta en la que realmente ha sido llamado, por lo que un agente listado en Power Platform muestra Observed only hasta que realiza una llamada.

• Descubrir agentes — Una nueva acción en el registro enumera los agentes de Copilot Studio de sus entornos de Power Platform, para que aparezcan antes de que ninguno haya llamado a Beak. Todo lo encontrado llega como candidato: Discovered, Inactive, sin alcances. Un agente que no es Governed no puede autenticarse, por lo que el descubrimiento nunca autoriza nada por sí solo.
• Onboard y Exclude — Los candidatos ahora pueden adoptarse o excluirse del registro. Excluir es duradero — una sincronización posterior que aún reporte el agente no lo reincorporará. Incorporar requiere agents:create, el mismo permiso que adoptar un agente de Agent 365; excluir requiere agents:update.
• Integración con Power Platform — Una nueva integración en Integrations contiene la credencial que usa el descubrimiento. Es independiente de la detección de amenazas de Copilot Studio y ninguna reemplaza a la otra: la detección de amenazas es entrante y aplica políticas, Power Platform es saliente y encuentra agentes. Test connection lista bots en cada entorno que indique en lugar de solo intercambiar un token, porque una aplicación puede obtener un token y aun así ser rechazada por cada entorno.
• El filtro de Governance ahora funciona — El registro enviaba el filtro y el servidor lo ignoraba, por lo que los agentes Discovered no podían listarse en absoluto. Los candidatos solo eran accesibles a través de las páginas de Agent 365.

Nota: Desactivado de forma predeterminada en el sentido de que nada cambia hasta que configure Power Platform — el descubrimiento no tiene credencial hasta entonces. Los agentes existentes no se ven afectados al actualizar, y su cobertura se establece solo donde hay evidencia: los agentes que Beak ejecuta y las configuraciones de hook de Anthropic muestran Inference, los agentes de Copilot Studio que ya habían llamado a Beak muestran Tool hook only, y todo lo demás muestra Observed only hasta que se confirma una ruta. Nada se marca como cubierto basándose en lo que reporta una plataforma externa.

Los incidentes ahora cubren todas las fuentes, no solo los escaneos del navegador

La página Incidents listaba únicamente los escaneos de extensiones de navegador. Los impactos de políticas de Microsoft Copilot Studio, Anthropic y la API de moderación eran decididos por el mismo motor de reglas pero no podían mostrarse en la página. Las cuatro fuentes ahora aparecen juntas, separadas por una nueva dimensión Origin — Endpoint para una persona en un dispositivo administrado, Agent para un modelo o agente que llama — con un filtro Detected by para la integración específica. Consulte Incidents.

Nota: Los veredictos de Anthropic se vieron afectados de forma más grave. Un prompt denegado no podía escribirse en el registro de auditoría en absoluto, por lo que ninguna solicitud de Anthropic denegada aparece en los incidentes registrados antes de esta versión. Los veredictos permitidos se almacenaban normalmente. Las denegaciones a partir de esta versión se registran de forma completa; las anteriores no pueden recuperarse, porque nunca fueron escritas.

• Paginado y filtrable — La página ahora pagina a través del conjunto de resultados completo en lugar de mostrar las primeras cincuenta filas, y el recuento de elementos es el total del servidor para los filtros actuales. La búsqueda, Origin, Detected by, Action y el rango de tiempo se resuelven todos en el servidor, por lo que cubren todos los incidentes en el rango en lugar de las filas en pantalla. La búsqueda también alcanza el nombre de la política, la superficie, la identidad del agente y los argumentos de una llamada de herramienta de Copilot.
• Columnas legibles — Las fuentes se muestran como Microsoft Copilot Studio y Anthropic en lugar de identificadores internos, la política que se activó se nombra en lugar de numerarse, y un veredicto en modo sombra se muestra como Would block en ámbar en lugar de compartir el estilo neutro del tráfico permitido.
• Solo impactos de políticas de forma predeterminada — Las solicitudes sobre las que ninguna política actuó se excluyen, por lo que el recuento refleja lo que sus políticas detuvieron. Include allowed amplía la lista.
• Detalles de la solicitud en el panel lateral — Para un incidente de Copilot Studio el panel ahora muestra la herramienta que fue llamada y los argumentos con los que fue llamada; para un incidente de Anthropic, el modelo, el actor y la sesión. Este detalle se registraba anteriormente pero nunca se mostraba.
• Enlaces a incidentes externos — Una nueva sección External systems muestra dónde se replicó el incidente. Microsoft Defender XDR incluye un enlace directo a la alerta creada; Microsoft Sentinel muestra una consulta KQL lista para ejecutar que localiza el incidente en la tabla de Log Analytics, porque la ingesta por lotes no devuelve ningún identificador por incidente al que enlazar; Microsoft Teams muestra el estado de entrega. Los despachos fallidos muestran su error.

Nota: Las notificaciones de Teams y el reenvío a Sentinel no podían registrar su estado antes de esta versión — las tablas de las que dependen no existían — por lo que ninguna notificación de Teams fue entregada y ninguna fila de auditoría llegó a Log Analytics en ninguna vers