Tag not monitored by Microsoft.
Does the Observability Agent button in the Logs blade (inside Senintel) work independently of the Azure Copilot tenant-level disablement?
Hi there!!, I'm a SIEM engineer working across multiple customer Sentinel environments at an MSSP. I've observed what appears to be an undocumented behavior regarding the Observability Agent and its relationship with the Azure Copilot tenant-level toggle, and I'd appreciate clarification from the product team.
Environment: A customer's Microsoft Sentinel workspace where Azure Copilot has been disabled at the tenant level by the Global Administrator. When clicking the main Copilot icon in the Azure portal header, the right-side panel displays: "You don't have access to Copilot — Azure Copilot has been disabled. To access Copilot, please contact your tenant's global administrator."
Observed behavior: In the same tenant/workspace where Azure Copilot is disabled, the "Observability Agent" button present in the Sentinel Logs blade (top bar, next to Save/Share) opens a dedicated full-page chat experience titled "Observability Agent" with a "Temporary chat" label. This experience is fully functional — I was able to submit a natural language query asking the agent to investigate CommonSecurityLog events. The agent reasoned for ~2 minutes and returned a structured response including a summary, a table with respective details and an assessment verdict.
Summary of the two behaviors in the same environment:
- Observability Agent button (Logs blade) → Opens dedicated full-page chat → Fully functional, returns analysis
- Copilot icon (portal header) → Opens right-side chat panel → Blocked with "Azure Copilot has been disabled" message
My questions:
- Is the Observability Agent button in the Logs blade intentionally designed to operate independently of the Azure Copilot tenant-level access enablement or disablement? Or is this unintended behavior?
- If it is intentional, is there separate documentation covering the access controls and prerequisites specifically for the Logs blade Observability Agent entry point, distinct from the Azure Copilot admin center settings?
- Does the Observability Agent accessed via the Logs blade button have the same data handling, retention (30-day internal retention for product improvement), and CMK limitations as the Azure Copilot observability agent described in the official docs?
- Is there a separate tenant-level setting or RBAC role that controls access to the Observability Agent button in the Logs blade specifically?
Documentation I've reviewed:
- Azure Copilot observability agent overview — describes the Logs blade entry point but does not mention whether Azure Copilot needs to be enabled
- Manage access to Azure Copilot — describes the tenant-level toggle but does not mention the Observability Agent button specifically
- Observability agent capabilities in Agents (preview) in Azure Copilot — states "only available for tenants that have access to Agents (preview) in Azure Copilot" but this appears to refer to the Copilot chat panel path, not the Logs blade button
- Azure Copilot observability agent blog post — describes the agent as "integrated with alerts, the Azure portal, and Azure Copilot (gated preview)" suggesting these are distinct integration surfaces
This distinction matters for MSSP environments where customer tenants may have Azure Copilot disabled for policy or compliance reasons, but the SOC team could still benefit from the Observability Agent for platform health troubleshooting. Clear documentation on the access model would help us advise customers accurately.
Thank you.
Community Center | Not monitored
1 answer
Sort by: Most helpful
-
AI answer
2026-04-20T11:57:03.96+00:00 The available documentation only supports a limited part of what is being asked, so only those points can be answered.
From the documentation:
- The Observability Agent is described as an Azure Copilot agent that is accessed from the Logs blade of an Application Insights or Log Analytics Workspace resource by selecting the Observability Agent button. This opens a chat experience where natural language can be used to explore logs and metrics, analyze anomalies, and run investigations.
- The Observability Agent is part of Agents (preview) in Azure Copilot, which are surfaced by Azure agent orchestration as part of the Azure Copilot experience. The observability agent is listed as one of the agents available in this preview alongside deployment, migration, optimization, resiliency, and troubleshooting agents.
- Data handling and retention: the Observability Agent’s investigation data may be retained internally for up to 30 days after an investigation is completed, for operational, quality, and product improvement purposes. The chat opened from the Logs blade is explicitly described as temporary and not saved for later access or use. The responsible-use FAQ further clarifies that:
- The observability agent analyzes data within the Azure environment and only accesses resources and performs actions within the user’s existing permissions (Azure RBAC, PIM, Azure Policy, resource locks).
- User prompts and agent responses are not used to train or improve the underlying AI models.
- User engagement data (for example, number of sessions, duration, selected skills, feedback) may be collected solely for product improvement and is governed by the Microsoft Privacy Statement and explicit user consent.
- Access control model: the responsible-use FAQ states that the Observability Agent operates strictly within the constraints of existing access management controls in the tenant (Azure RBAC, PIM, Azure Policy, resource locks). No separate RBAC role or tenant-level setting specific to the Logs-blade Observability Agent button is documented. The best-practices guidance focuses on telemetry enrichment (cloud role names, resource context, Kubernetes metadata) rather than additional access switches.
The documentation provided does not describe:
- Any behavior difference between the portal header Copilot icon and the Logs blade Observability Agent button when Azure Copilot is disabled at the tenant level.
- Any separate tenant-level toggle, policy, or RBAC role that specifically enables or disables the Observability Agent entry point in the Logs blade.
- Any CMK-specific behavior or limitations for the Observability Agent beyond the general data-handling and retention statements above.
Because these aspects are not covered in the available documentation, the behavior observed (Observability Agent working while the main Azure Copilot entry point is disabled) cannot be characterized here as either intentional or unintended, nor can any additional controls beyond standard Azure access management be described.
References:
- Azure Copilot observability agent (preview)
- Responsible AI FAQ for Azure Copilot observability agent (preview)
- Troubleshooting guide: Azure Copilot observability agent (preview)
- Best practices: Azure Copilot observability agent (preview)
- Agents (preview) in Azure Copilot
AI-generated content may be incorrect. Read our transparency notes for more information.