Microsoft Foundry Logging: Control Plane, Data Plane, and Application Insights

Microsoft Foundry deployments generate telemetry across four distinct layers: the Activity Log, Diagnostic Settings at both the resource and project level, Application Insights, and the Entra ID identity plane. The Activity Log is the only one that requires no configuration unless you want to ingest the data into Microsoft Sentinel. Every other source is opt-in, and the decisions about what to collect, where to route it, and who can access it are most consequential before a workload carries real traffic. Log gaps in production are possible to close retrospectively, but the data that was never collected cannot be recovered.

This is the first post in a series on Microsoft Foundry logging for Security Operations. Each layer is distinct in what it captures, where it routes, and what it takes to enable; conflating them leads to gaps that are invisible until an incident exposes them. Cloud operations visibility is a useful framing device for this first post, but the series from here focuses on what security operations teams need to configure, route, and monitor once Foundry is running.

Disclaimer: Diagrams and structural drafts were produced with AI assistance; the analysis, technical judgements, and text are my own unless stated otherwise.

What is Microsoft Foundry?

From the Microsoft Learn documentation:

Microsoft Foundry is a unified Azure platform-as-a-service offering for enterprise AI operations, model builders, and application development. This foundation combines production-grade infrastructure with friendly interfaces, enabling developers to focus on building applications rather than managing infrastructure.

Microsoft Foundry unifies agents, models, and tools under a single management grouping with built-in enterprise-readiness capabilities including tracing, monitoring, evaluations, and customizable enterprise setup configurations. The platform provides streamlined management through unified role-based access control (RBAC), networking, and policies under one Azure resource provider namespace.

The Foundry Resource and Project Model

Microsoft Foundry introduces a layered logging model that most organisations bolt onto after deployment, when the decisions that matter most (what to collect, where to send it, who can see it, and what to do with it) are already harder to change or get forgotten entirely. Getting those decisions right upfront requires understanding what each logging layer actually captures, how it behaves differently at the Resource and Project level, and which sources security operations teams need in place before the workload carries real traffic.

The diagram below shows the one-to-many relationship between a Foundry resource and its projects. One Foundry resource can contain many Foundry projects, and projects inherit the resource's configuration settings. This context carries through the rest of the post.

The Foundry resource (Microsoft.CognitiveServices/accounts) is the top-level Azure resource and governance boundary. This is where a team configures networking and private endpoints, RBAC, managed identities, customer-managed encryption keys, model deployments, and service connections to dependent resources. Management-plane and control-plane operations such as creating projects, registering deployments, rotating keys are all scoped here. Because of this, it is also where the most security-sensitive logging originates.

The Foundry project (Microsoft.CognitiveServices/accounts/projects) is a subresource and development boundary inside the Foundry resource. Projects are where individual teams or use cases are isolated: agent builds, evaluations, prompt flows, and Application Insights connections live at the project level. Projects inherit the networking and encryption configuration of their parent resource. RBAC assigned at the resource scope cascades to all projects under it, which means a single assignment can cover every project. Least-privilege access however, might require RBAC assignments to be made at the the project level. I will delve into resource vs project level RBAC assignments in an upcoming blog.

The Logging Stack

The previous diagram shows that a Microsoft Foundry resource can contain many Microsoft Foundry projects. The diagram below adds the logging layers that sit across both provider types, and the Entra ID identity plane that sits outside the resource boundary entirely.

The distinction between logging layers matters because it determines where data flows, who configures it, and what it can answer.

Control Plane Logging

The Azure Activity Log is the control plane logging layer for Microsoft Foundry. It is generated automatically by Azure Resource Manager (no opt-in or diagnostic setting is required) and captures every management operation performed against the Foundry resource and its projects. This includes resource creation and deletion, RBAC role assignment changes, encryption key rotation events, private endpoint and network configuration changes, and model deployment operations.

Entra ID diagnostic settings are a complementary control plane source the Activity Log alone cannot replace. For Foundry this matters more than it would for most Azure services: agents are Entra ID identities, and without Entra ID logs in place the entire agent authentication plane is a blind spot. Both sign-in and audit log categories require their own diagnostic setting on the Entra ID tenant and should route to the same Log Analytics Workspace used for Foundry resource logs. This topic will be covered in depth in the second blog of this series.

If you want a deeper understanding of how agent identities work before tackling the logging side, Derk van der Woude has written an extensive series on agent identities worth reading first.

Data Plane Logging

Data plane logging for Microsoft Foundry is delivered through Azure Monitor Diagnostic Settings and must be explicitly enabled as nothing is collected by default. The Foundry resource (Microsoft.CognitiveServices/accounts) and Foundry projects (Microsoft.CognitiveServices/accounts/projects) are separate resources in the Azure Monitor model, which means each requires its own diagnostic setting configuration.

It can take up to two hours before logging data is available to query and analyze according to official Microsoft Learn documentation.

Category	Resource level	Project level	What it captures
Audit	✓	✓	Data plane access and control events: key retrievals, connection access, and administrative API calls. At project scope: agent operations such as runs, file uploads, and evaluations.
RequestResponse	✓	✗	Metadata for each inference call: model/deployment, operation type, status codes, latency, and request context. Does not include prompt or completion content.
AzureOpenAIRequestUsage	✓	✗	Per-request token usage and consumption by model/deployment. Primary source for cost attribution, quota tracking, and usage analysis.
Trace	✓	✓	Low-level diagnostic and debugging information for service operations and inference calls. May include internal processing details but not full prompt/response payloads.

Data Plane Sensitivity: What RequestResponse Actually Contains

The RequestResponse log category captures metadata about every inference call, not the full request or response payload. This includes;

Field	Description
Model and deployment name	The specific model and deployment handling the request
Operation type	Type of operation (e.g. chat completions, embeddings)
Status codes	Indicates success or failure of the request
Latency and duration	Time taken to process the request
Token usage indicators	Token consumption metrics (when available)
Caller and resource context	Information about the caller and target resource

Important to note, it does NOT include the prompt text or model-generated completion. Which is a deliberate design choice by Microsoft to reduce the risk of sensitive data exposure through platform-level logging. Prompts and completions may contain personally identifiable information (PII) secrets, or business data, and are therefore excluded from diagnostic logs by default.

Application Insights

Application Insights is the third and deepest logging layer, operating at the project level. Unlike the Activity Log and Diagnostic Settings, Application Insights telemetry is emitted through the OpenTelemetry SDK from within the application or agent code that runs inside a Foundry project. The connection between a project and an Application Insights resource is configured in the Foundry portal and can be enabled per project.

When application insights is connected to a Microsoft Sentinel enabled log analytics workspace, the following tables become available:

Table	What it captures in a Foundry context
AppDependencies	The main table for model inference calls. Each call to the model endpoint is recorded as an outgoing dependency: target endpoint, operation type, duration, success/failure status, and if content capture is enabled, prompt and completion data.
AppTraces	General trace messages emitted by the SDK and application code during agent execution. Tool call sequences and orchestration steps surface here.
AppExceptions	Exceptions thrown during inference calls, tool execution, or agent orchestration. Useful for detecting error spikes and failed agent runs.
AppRequests	Inbound requests to the application layer, if the agent is exposed via an HTTP endpoint. Less relevant for background agent workloads.
AppEvents	Custom events, if the application explicitly emits them via the SDK.

These tables capture what the application is doing at runtime: full request traces from start to finish, calls to external services, per-request token usage, model response time as measured inside the application, and any errors thrown during execution. Each span is linked, making it possible to reconstruct the complete path a single user interaction took across tool calls, agents, and data lookups. Neither the Activity Log nor Diagnostic Settings can provide this level of visibility.

Prompt and completion logging is available at this layer. The Azure AI Foundry SDK includes built-in OpenTelemetry instrumentation. Both the azure-ai-inference and azure-ai-projects SDKs support content capture, which is off by default in both and enabled via the AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED environment variable.

The tracking infrastructure is provided by the SDK. The question that remains is whether to enable content capture or not. Prompt and completion spans may contain PII, secrets, or business data. Enabling capture creates direct responsibility for storage, access controls, and retention. The SDK makes it easy to turn on. The governance obligations do not disappear once you do.

Content capture can be enabled with one SDK flag. Governance should be in place before you enable it.

What to Enable

The logging layers described above are not equally relevant to every team. Each carries different cost and compliance implications, requires different configuration ownership, and answers different operational questions. Enabling everything by default is neither free nor safe. The rest of this series focuses on security operations; the breakdown below reflects that, with a brief note on what cloud operations teams should consider separately.

CloudOps

CloudOps teams operating Microsoft Foundry workloads should prioritise the Activity Log, AzureOpenAIRequestUsage, and AllMetrics for configuration integrity, token consumption tracking, and service performance. Application Insights is the primary reliability layer at the project level. Entra ID logs and the Audit diagnostic category add no distinct operational value at steady state for CloudOps. This series does not cover the CloudOps arc in depth; the focus from the next post onward is security operations logging, routing, and detection.

Security Operations

Security operations visibility for Microsoft Foundry spans identity, access, and behaviour across both the management plane and the AI workload. The gaps here are the most consequential: absent Entra ID logs leave agent identities unobservable, and missing Audit at project scope leaves agent operations without an access trail in Sentinel. The rest of this series is structured around closing these gaps: what to enable, how to route it, and what to do with it once it lands.

Source	Enable	When to enable
Activity Log	✓	Primary source for detecting privilege escalation, lateral movement at the resource level, and misconfiguration.
Entra ID sign-in and audit logs	✓	Required to cover the agent authentication plane. Agents are Entra ID identities; without these logs, non-interactive sign-ins, service principal activity, and agent lifecycle events are a blind spot. Covered in depth in the next post in this series.
Diagnostic Settings Audit	✓	Highest priority at both resource and project scope as it records which identities accessed which capabilities and when.
Diagnostic Settings RequestResponse	✓	Enables detection of anomalous call patterns, unusual identity activity, and usage spikes that may indicate abuse or compromise.
Application Insights	✓	Surfaces agent-level behaviours absent from Foundry resource logs such as anomalous tool call chains, unexpected external dependencies, unusual exception patterns, and trace data.
Diagnostic Settings AzureOpenAIRequestUsage	✗	No distinct SecOps value.
Diagnostic Settings Trace	✗	Not a detection source under normal conditions.
Diagnostic Settings AllMetrics	✗	No distinct SecOps value.

Key Takeaways

• The Foundry resource and each Foundry project are separate resources in the Azure Monitor model. Diagnostic Settings configured at the resource level do not apply to projects. Configure them independently or accept the gaps.
• RBAC assigned at the Foundry resource scope cascades to all projects under it. Applying least-privilege access can require RBAC assignments at Foundry project scope.
• Diagnostic settings do not cascade from the Foundry resource to its projects. Per-project configuration is required every time a new project is created.
• RequestResponse does not contain prompt or completion content. If investigation requires content-level visibility, Application Insights with content capture enabled is the only source that provides it.
• Content capture is off by default in both the azure-ai-inference and azure-ai-projects SDKs. Enabling it via AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED creates direct responsibility for storage, access controls, and retention. Governance should be in place before it is turned on.
• Entra ID sign-in and audit logs are configured at the tenant level, not at the Foundry resource. Without them, agent identities have no observable authentication plane. They should route to the same Log Analytics Workspace as Foundry resource logs.
• For SecOps, Audit at both resource and project scope is the highest priority Diagnostic Settings category. It is the only source that records which identities accessed which Foundry capabilities and when. It is not enabled by default.
• Application Insights must be connected to a workspace-based resource linked to the same Log Analytics Workspace as Microsoft Sentinel for SecOps analytics rules to query it. A component-based Application Insights instance will not be visible from Sentinel.

Final Note

This is my first blog post, and I appreciate you reading it. Writing about security operations is something I have wanted to do for a while, and Microsoft Foundry felt like the right place to start given how much is changing in this space.

My plan is to publish roughly every two weeks. I want to give each topic the depth it deserves rather than push out volume, and frankly I am still finding my feet as a writer. The rest of this series follows the same concrete structure and is scoped to security operations: which logs to enable, how to route them into Sentinel, and how to turn them into detections and investigations.

If you are new to Microsoft Foundry and want to build a practical foundation before going deeper on logging and security, Microsoft Learn has an applied skills module worth working through: Secure AI solutions in the cloud