If you run AI powered applications on Azure, your Application Insights logs have been storing something you might not have thought about. Every prompt you send to an LLM and every response the model returns has been sitting in the same logs as your standard application telemetry, accessible to anyone with log read permissions. That changes with a new public preview from Azure Monitor.
Application Insights now stores generative AI content in a dedicated table called GenAIContent (AppGenAIContent in Log Analytics), making it possible to apply separate access controls to sensitive AI telemetry without affecting how you handle the rest of your application logs.
The problem with mixed telemetry
Generative AI applications send a lot of data through Application Insights. Prompts, responses, system instructions, tool call results, token usage metrics, latency breakdowns. That data is essential for debugging, monitoring, and cost tracking. But it also contains material that you probably do not want every developer on the team to see.
A prompt asking the LLM to summarize a customer support ticket contains PII by design. A system instruction that reveals your internal RAG chunking strategy is intellectual property. Putting all of that in the same bucket as your HTTP 200 counts and exception traces meant there was no clean way to restrict access to just the sensitive AI content without also blocking access to routine telemetry.
This is not a hypothetical problem. Companies building AI agents on Foundry have been asking for log level access controls since day one. The standard Application Insights RBAC model could not give it to them without also breaking their ops workflows, because the AI data was mixed in with everything else.
How the dedicated table changes things
The GenAIContent table separates AI specific telemetry into its own schema. Application Insights automatically routes prompts, responses, and tool interactions into this table instead of embedding them in custom events or traces. You can then apply Log Analytics RBAC to restrict the table to specific roles or users.
Your SRE team keeps full access to requests, dependencies, and exceptions for operational monitoring. Your compliance team gets read only access to GenAIContent for auditing. Your engineering team working on the AI features gets access only during active development. Everyone sees what they need and nothing they do not.
Compliance and governance angle
For organizations under GDPR, HIPAA, or SOC 2, this is a meaningful improvement. Storing customer prompts and model responses in the same unrestricted log stream as everything else was a gap that auditors would flag. The dedicated table gives you a clear boundary you can document and enforce.
It also simplifies data retention policies. You might want to keep standard application logs for 30 days but retain AI interaction logs for 90 days for model improvement analysis. With separate tables, you set different retention windows on each without complex query time filtering.
What to watch for in the first rollout
This is a public preview, so some things need attention. First, the routing is opt in. You have to enable the GenAIContent table from the Application Insights configuration blade or the Log Analytics workspace settings. Existing AI telemetry stays in its current location. Only new data written after you enable the table goes to the dedicated schema.
Second, any dashboards or alerts you built that reference AI telemetry from customEvents or traces will break. Grafana panels, Azure Workbooks, and Log Analytics queries that pull prompts and responses from the old locations need to switch to the new table. The schema is different, so expect to rewrite the queries. There is no automatic migration or backward compatibility layer.
Third, the table is empty until you enable it and start sending data. If you have a compliance audit coming up next month, this is not a retroactive fix. You need to plan for a transition period where some AI telemetry lives in the old location and some in the new one.
How it compares to other approaches
AWS CloudWatch does not have a dedicated GenAI table. You would need to build your own filtering with custom namespaces and IAM policies. Google Cloud has Log Analytics with a similar concept of log buckets, but you configure it manually rather than getting automatic routing.
Azure’s approach is the most turnkey of the three. You enable the feature, and the platform handles the routing. The downside is that you are tied to the Application Insights schema for the GenAIContent table. If you wanted a different schema or additional metadata fields, you would need to build your own custom logging pipeline on top of it.
Getting started
Enable the GenAIContent table from the Application Insights configuration blade. Update any custom queries that pull AI telemetry from customEvents or traces. Set up RBAC on the AppGenAIContent table before you start sending production AI traffic. Map out what roles in your organization need access to AI telemetry and grant the minimum permissions for each.
This is a small change in the Azure portal that has a disproportionate impact on your security posture. If you run AI workloads on Azure, it is worth enabling today.