The problem: AI prompts in the wrong table
If you’ve been sending AI application telemetry to Application Insights, your users’ prompts and LLM responses have been sitting in the same traces and custom events tables as your infrastructure logs. That means anyone with access to your Application Insights instance — typically the whole monitoring team — can read whatever users type into your AI features. For enterprise applications handling PII, financial data, or internal business documents, that’s a compliance problem waiting to surface.
Azure Monitor now addresses this with the AppGenAIContent table (called GenAIContent in the Application Insights schema). All generative AI telemetry is routed to this dedicated table, which supports protected table access controls in Log Analytics. Monitoring team members who need to see CPU usage and error rates no longer automatically get access to raw prompt and response data.
How the new table structure works
Instead of storing AI prompts and responses spread across traces, customEvents, and customMetrics tables, the new model collects everything into one place. The AppGenAIContent table captures the full AI interaction: the prompt sent to the model, the response returned, token counts, latency, model name, and any content safety annotations.
The key change is that this table is flagged as a “protected table” in Log Analytics. Protected tables require separate RBAC permissions that you can set independently of the main Application Insights role. You can grant read access to your monitoring dashboard without exposing AI content, and restrict prompt/response visibility to a smaller security or compliance team.
Microsoft has also integrated this with Purview sensitivity labels. If your organization uses Purview to classify data, the labels applied at the source system (like “Confidential – PII” or “Internal – Financial”) flow through to the AppGenAIContent table. This means your data governance policies apply automatically to AI telemetry without additional configuration per application.
Setting it up
The change is in public preview as of July 20. To use it, you need to enable the new table structure in your Application Insights resource. This is done through the Azure portal under the “AI telemetry routing” setting, or via PowerShell/CLI.
Once enabled, all new AI telemetry from your connected applications flows to the AppGenAIContent table. Existing data in traces and customEvents tables is not migrated automatically. You have two options: leave the old data in place with existing access controls, or run a data migration script to move historical AI telemetry to the new table. Microsoft recommends treating the transition as a cutover — new data goes to the new table, old data stays where it is — and applying the protected table access controls to the new table while you audit and clean up the old one.
After the table is active, configure the RBAC permissions. The Application Insights Contributor role no longer grants read access to AppGenAIContent by default. You need to assign a separate “Application Insights AI Content Reader” role (or a custom role) to users who need to view prompts and responses. Everyone else sees the monitoring data they always saw, minus the AI content.
Practical considerations for developers
If you’re building AI features on Azure, here’s what this change means for your application code today. The Application Insights SDKs for .NET and Python have been updated to detect AI telemetry patterns and route them to the new table automatically. If you’re using one of the supported SDK versions and have enabled the new table, the routing happens without code changes.
If you send custom AI telemetry events using TrackTrace or TrackEvent calls, those won’t automatically go to the new table. You need to update your logging code to use the AI-specific telemetry channels, or configure your existing telemetry pipeline to identify and route AI-related events. Microsoft provides a telemetry processor sample that inspects event properties for known AI patterns and reroutes them.
The Defender for Cloud integration also changed. There’s a new recommendation that flags Application Insights instances feeding Foundry AI workloads that haven’t enabled the AppGenAIContent table. This recommendation shows up in your security posture score, so organizations with compliance requirements have an incentive to enable the feature promptly.
Why this matters for compliance
Data protection regulations like GDPR, HIPAA, and SOC 2 require that access to personal data is restricted to authorized personnel. Before this change, monitoring teams had a legitimate argument that they needed access to Application Insights for operational reasons, and the AI content was an unavoidable side effect. The AppGenAIContent table removes that ambiguity: monitoring can operate without seeing prompts, and compliance teams can audit AI interactions without needing monitoring dashboard access.
For organizations subject to PCI DSS or financial services regulations, this also matters for audit logging. The new table structure makes it straightforward to produce reports showing who accessed AI telemetry data and for what purpose, because the access controls are table-scoped rather than instance-scoped.
There is one catch worth noting. The old traces and customEvents tables still contain historical AI data. If your compliance requirements demand that no sensitive data be accessible to unauthorized users, you need to either purge the old data or apply restricted access controls to the entire Application Insights instance until you can clean it up.