Tag not monitored by Microsoft.
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: