Does AutoGen log the actual prompt and response content?

Structured logging events and OpenTelemetry spans carry whatever fields a developer defines or the runtime's default instrumentation emits, and neither is documented to guarantee full prompt and completion capture by default. Teams that need the literal request and response body have to instrument that explicitly at the model client boundary, at which point the identity gap described above still applies: capturing content is a separate problem from capturing who authorized sending it.

Can I just add a correlation ID to solve the identity gap?

A correlation ID threaded through application code helps you join AutoGen's logs to an upstream request, but it depends on every service in the chain propagating it correctly and on the application being trusted to generate it accurately. That is the same self-attestation problem that affects any application-controlled log: the system generating the identifier is the same system whose behavior you are trying to audit independently.

Is OpenTelemetry tracing enough for a SOC 2 or ISO 42001 audit?

Tracing gives an auditor operational evidence that agent runs happened and roughly how long they took. It does not, by itself, give a signed record tying a specific model call to a verified human or service identity and the policy that was in force. Auditors reviewing AI-specific controls under ISO/IEC 42001 or a SOC 2 examination scope typically ask for the latter, not just span data.

Does disabling tracing affect DeepInspect's audit record?

No. DeepInspect's audit record is produced at the HTTP proxy layer, outside the AutoGen process and independent of whatever tracer configuration the agent runtime uses. Turning off AUTOGEN_DISABLE_RUNTIME_TRACING removes AutoGen's own telemetry; it has no effect on a policy decision recorded at the request boundary.

How does this compare to Claude connector logging?

Anthropic's MCP connector audit trail has the same shape: solid records for the connector authorization and the remote tool action, no built-in binding to the human behind the session. The pattern repeats across agent frameworks because none of them were designed as the system of record for identity-bound authorization. That job sits one layer below, at the request itself.

AutoGen Audit Logs: What Microsoft''s Multi-Agent Framework Actually Records

Microsoft's AutoGen documentation splits logging into two paths on purpose. Trace logging is for a developer staring at a terminal: human-readable messages that the docs say "should not be depended on by other systems." Structured logging is the other path, dataclass-based events with fields another system can actually parse. A team building a compliance record on top of AutoGen has to pick the second path deliberately, because the first one was never meant to survive contact with an auditor.

I want to walk through what each path captures, what the framework's OpenTelemetry support adds on top, and where the identity gap sits once you have all three running at once.

TL;DR

AutoGen's trace logging is for developer debugging and carries no format guarantee across versions.
Structured logging emits dataclass events a downstream system can parse reliably.
OpenTelemetry spans (create_agent, invoke_agent, execute_tool) follow the GenAI semantic convention and can be disabled entirely with AUTOGEN_DISABLE_RUNTIME_TRACING.
None of the three paths attach the identity of the human or service on whose behalf a specific model call was made.

Two logging paths, one gap

AutoGen's TRACE_LOGGER_NAME and EVENT_LOGGER_NAME root loggers sit on top of Python's standard logging module, and the docs are explicit that child loggers should be scoped per module. Trace logging exists for the "why did my agent do that" question during development. Structured logging exists so a monitoring pipeline can subscribe to custom dataclass events with typed fields instead of parsing a formatted string.

Both paths run inside the same process as the agent runtime. Whatever the runtime decides to emit is what gets logged. Neither path defines a field for the authenticated caller, the tenant, or the business role behind the session that triggered the agent run. That is not a bug in AutoGen. The framework's job is orchestrating agents and tool calls, not producing a compliance record for a regulator.

OpenTelemetry spans and what they cover

AutoGen instruments three things natively: the runtime (SingleThreadedAgentRuntime and GrpcWorkerAgentRuntime), tools (BaseTool produces execute_tool spans), and agents (BaseChatAgent produces create_agent and invoke_agent spans), all following OpenTelemetry's GenAI semantic conventions. A team wires this up by installing the OpenTelemetry SDK, creating a TracerProvider with a service.name resource, attaching a BatchSpanProcessor with an OTLPSpanExporter, then passing the provider into the runtime constructor.

That gives an engineering team real span-level visibility: which tool ran, how long an agent invocation took, how the call tree branched across a multi-agent conversation. Tracing can also be switched off entirely, either by passing a NoOpTracerProvider or setting AUTOGEN_DISABLE_RUNTIME_TRACING, which means the audit surface an operator gets depends on a runtime flag nobody outside the deploying team controls.

Where the model call actually happens

Every span above wraps a call from an AutoGen model client, OpenAIChatCompletionClient, AzureOpenAIChatCompletionClient, or a comparable wrapper, out to the underlying LLM API over HTTPS. That HTTP call is where DeepInspect's enforcement boundary sits: it is standard AI request traffic between an authenticated caller and a model endpoint, regardless of which agent framework issued the call. The span tells you an agent invoked a model. It does not tell you which authenticated person or service the agent was acting for at that moment.

The identity gap in a multi-agent deployment

Most AutoGen deployments authenticate the model client with one shared API key or one Azure managed identity for the whole agent runtime. Every span, every structured log event, every trace line carries the same credential context no matter which end user, ticket, or workflow triggered the run. That is the post-authentication gap in a specific, concrete shape: the system knows an agent ran and knows a tool was called, but it cannot answer "which authenticated user's request caused this specific model call" without stitching together application-level correlation IDs that live outside AutoGen's own logging surface.

Compare that to what the NIST AI agent identity and authorization framework asks for: verified agent identity, delegated authority scoped per request, and action lineage that survives review. AutoGen's telemetry gives you the third pillar's shape (a record of what happened) without the first two (who the agent was acting for, under what scoped permission). A trace exporter that a platform team can reconfigure or disable is also not independent evidence in the way action lineage requires. It is operational telemetry the same team that runs the agents also controls.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline on the HTTP path between an AutoGen agent's model client and the LLM API it calls, regardless of whether that endpoint is OpenAI, Azure OpenAI, or a self-hosted model. It evaluates the identity context the calling application attaches to the request, applies per-role and per-route policy, and writes a signed, tamper-evident audit record before the response reaches the agent.

That record exists independent of AutoGen's tracer configuration. Nobody flips AUTOGEN_DISABLE_RUNTIME_TRACING and makes the audit trail disappear, because the audit trail was never inside the agent runtime's process to begin with. AutoGen's spans and structured events stay useful for debugging agent behavior. DeepInspect's audit record stays useful for proving, to someone outside the engineering team, which authenticated caller authorized which model call.

Book a demo today.