Does Foundry tracing capture the full prompt and response text?

Tracing is built on OpenTelemetry spans covering LLM calls, tool invocations, and agent decisions; the specific fields captured depend on the instrumentation used by the framework generating the trace (LangChain, the OpenAI Agents SDK, or the Microsoft Agent Framework). Teams needing guaranteed full-content capture should verify the span attributes their specific framework integration emits rather than assuming complete capture by default.

Is Foundry observability free?

No. Observability features including risk and safety evaluations and evaluations run in the agent playground are billed on consumption, and playground evaluations are turned on by default for all Foundry projects unless a team disables them.

Can I restrict Foundry access to a private network?

Yes. Foundry supports network isolation through a managed virtual network and private endpoints, and a Foundry account can be configured to reject public network access entirely. That secures the network path to Foundry; it does not, on its own, add end-user identity binding to the requests that do arrive over that private path.

How is this different from Amazon Bedrock's identity handling?

The shape is the same even though the mechanics differ. Bedrock's model invocation log records the IAM ARN of the assumed role that called the API. Foundry authenticates the calling application through Microsoft Entra ID. Both platforms record the calling credential accurately. Neither one, by default, records the end user a multi-tenant application was acting for unless the application supplies and the platform is told to verify that context.

Do I need DeepInspect if I already use Foundry's evaluation and safety features?

Foundry's evaluators check output quality and safety, which is a model-behavior question. DeepInspect answers a different question at a different point in the request path: whether this specific authenticated caller is permitted to send this specific request to this specific model right now, and it records that decision independent of the AI platform's own configuration.

Azure AI Foundry Audit Logs: What Tracing and Monitoring Actually Record

Azure AI Foundry's observability stack is built on three capabilities: evaluation, monitoring, and distributed tracing. The tracing layer runs on OpenTelemetry and integrates with Azure Monitor Application Insights, and Microsoft documents support for LangChain, LangGraph, the OpenAI Agents SDK, and the Microsoft Agent Framework. That is a genuinely capable observability platform for debugging agent behavior. It was not built to answer a narrower, specific question a compliance reviewer asks: which authenticated end user caused this specific model call.

I want to walk through what Foundry's tracing and monitoring actually capture, then where that identity gap sits for a multi-tenant application built on top of it.

TL;DR

Foundry tracing captures LLM calls, tool invocations, agent decisions, and inter-service dependencies through OpenTelemetry, visible in Azure Monitor Application Insights.
Production monitoring adds real-time dashboards for token consumption, latency, error rates, and quality scores, plus continuous and scheduled evaluation of live traffic.
Access to a Foundry resource requires Microsoft Entra ID authentication (including managed identities) or a valid API key, and the identity captured is the calling application's identity, not necessarily its end users.
A multi-tenant application built on Foundry needs to propagate and verify end-user identity itself; the platform's own telemetry does not do this by default.

What tracing and monitoring actually capture

Foundry's distributed tracing "captures the execution flow of AI applications, providing visibility into LLM calls, tool invocations, agent decisions, and inter-service dependencies," per Microsoft's own observability documentation. That gives an engineering team a real debugging surface: which tool an agent called, how a multi-step reasoning chain branched, where latency accumulated across a request.

Monitoring sits on top of tracing and adds operational visibility once an application is live: token consumption, latency, error rates, and quality scores in real-time dashboards, plus alerts when outputs fail quality thresholds or produce harmful content. Foundry also runs continuous evaluation of production traffic at a sampled rate and scheduled evaluation against test datasets to catch drift. All of this is billed as consumption-based observability, and evaluations inside the agent playground are enabled by default unless a team turns them off.

The identity the platform actually authenticates

Any application reaching a Foundry resource authenticates through Microsoft Entra ID, using a workload identity, a managed identity, or a valid API key, and the request also has to originate from an allowed network path. That authentication establishes which application, service principal, or managed identity is calling Foundry. It does not, by itself, establish which end user of that application triggered the specific call, unless the application explicitly resolves and attaches that identity itself before the request reaches Foundry.

Where the identity gap sits

A typical enterprise pattern puts one application in front of Foundry, authenticated with one managed identity, serving many end users through its own sign-in flow. Every trace, every monitoring dashboard row, every evaluation record inherits that same managed identity as the calling context. The trace is accurate about what the application did. It is silent about which of the application's users the action was taken for, in the same way that a shared IAM role calling AWS Bedrock is silent about the end user behind the role.

This is the post-authentication gap in its Azure shape: Entra ID solves authentication of the calling application cleanly. It does not solve authorization of a specific request on behalf of a specific person, because that identity was never part of what Entra ID was asked to verify at the Foundry API boundary.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline on the HTTP path between an application and any model endpoint it calls, Azure AI Foundry included, and evaluates the identity context the calling application is required to supply for each request, not just the managed identity or API key behind it. Every request is checked against per-role, per-route policy before it reaches the model, and the decision is written to a signed, tamper-evident audit record independent of Foundry's own tracing configuration and independent of the calling application.

Foundry's tracing and evaluation stay valuable for what they were built for: debugging agent behavior and catching quality drift in production. DeepInspect adds the record a compliance review actually asks for, tied to the person behind the request rather than the service account that made the call.

Book a demo today.