Does AutoGen's event logging satisfy an AI audit trail requirement?

It supplies application-level telemetry about model calls and responses through the standard Python logging module. An audit requirement generally asks for a record that survives the failure of the system under audit, names the authorising identity, and captures the policy state at the moment of the decision. Logging written by the calling process satisfies none of those three reliably, which is why regulated deployments pair it with an independent record.

How should experimental model clients be treated in a control description?

Name them as experimental with the date checked, and record which agents use them against production data. The AutoGen documentation marks the Anthropic, Ollama, Gemini and Llama API clients experimental, and separately notes that OpenAI-compatible endpoints are untested with the OpenAI client. Writing "supported by the framework" over any of those overstates what the maintainers have said, and an assessor who reads the source documentation will find the gap.

Where does the originating user's identity go in an AutoGen call?

Nowhere, unless the application puts it there. Model clients authenticate with a key or with Azure credentials held by the process. The provider sees that credential. Carrying the human or service identity that initiated the work is an application responsibility, and without it a per-decision record cannot name who authorised the request.

Where does DeepInspect fit in an AutoGen deployment?

DeepInspect evaluates HTTP traffic between authenticated users or agents and LLM endpoints that is routed through it, applying policy to application-supplied identity and content classification before forwarding, and recording the decision outside the calling process. Agent orchestration, tool selection, prompt construction, and local model execution through Ollama on the same host are outside that boundary.

AutoGen Compliance: Model Clients, Untested Endpoints, and Event Logging

AutoGen's model client documentation carries a sentence that decides how a compliance file should treat custom endpoints: you can use this client with models hosted on OpenAI-compatible endpoints, however, we have not tested this functionality. A framework telling you a configuration path is untested is giving you a risk register entry, and most AutoGen deployments I have looked at are using exactly that path.

The compliance work starts with an inventory of which client each agent actually holds.

TL;DR

AutoGen supports OpenAI, Azure OpenAI and Azure AI Foundry clients, with Anthropic, Ollama, Gemini and Llama API clients marked experimental in the documentation.
The documentation states that OpenAI-compatible endpoints are usable with the OpenAI client but have not been tested, which belongs in the risk register rather than in a control description.
Model clients read credentials from the process environment or from code, so credential custody is a per-agent question.
AutoGen logs model interactions through Python's standard logging module under autogen_core.EVENT_LOGGER_NAME, which is application-controlled telemetry.
A record written by the same process that made the call is self-attestation, and a regulated deployment needs a record outside that write path.

The model client inventory is the first artefact

The AutoGen model clients documentation sets out the supported surface. OpenAIChatCompletionClient covers OpenAI models. AzureOpenAIChatCompletionClient supports Azure OpenAI with Entra ID or API key authentication. AzureAIChatCompletionClient reaches models on Azure's platform. AnthropicChatCompletionClient, OllamaChatCompletionClient, the Gemini path through an OpenAI-compatible API, and the Llama API client are all marked experimental. A Semantic Kernel adapter bridges further providers including MistralAI, AWS and Hugging Face.

Experimental status is a compliance fact, not a footnote. A control description that says "model access is governed by the framework" is asserting stability the maintainers have not claimed. Record the client class per agent, the provider, the model identifier, and whether the documentation marks that client experimental on the date of review.

Then record which of those agents run against production data. The gap between the inventory and that subset is usually where the interesting findings live.

Credentials are held per client, which makes attribution hard

Model clients read a credential from the environment, for example OPENAI_API_KEY, or accept one explicitly in code. Either way the credential belongs to the process, not to the person whose work the agent is doing.

That produces the attribution problem regulated deployments keep hitting. When an agent calls a model, the provider sees the key. The provider does not see which employee's request started the chain, which role that employee holds, or what classification the content carried. A shared credential across several agents collapses the distinction further, and reconstruction after the fact becomes an exercise in correlating timestamps.

Our AI agent identity material covers the identity model this requires. The short version for an AutoGen file: the framework evaluates what it is given, and supplying an originating identity is the application's responsibility rather than a framework feature.

Event logging is application-controlled telemetry

AutoGen uses Python's standard logging module with the logger name autogen_core.EVENT_LOGGER_NAME to track model interactions, which lets a team monitor calls and responses. Enabling it takes three lines inside the agent process: import EVENT_LOGGER_NAME from autogen_core, fetch that logger with logging.getLogger, and set its level.

That is genuinely useful for debugging and for building a picture of agent behaviour. As compliance evidence it carries a structural weakness: the process that made the model call is also the process that writes the record of the call. If the agent fails after the model responds and before the handler flushes, the action happened and the evidence did not.

The same process can also be configured to log selectively. Nothing about that is malicious, and an auditor has no way to distinguish a deliberate filter from a crash-loss from a complete record, which is why the AI audit log schema work puts the write path outside the application.

Our AutoGen audit logs piece covers the retrieval mechanics, and AutoGen security patterns covers the configuration side.

What a regulated AutoGen deployment has to add

Three things sit outside the framework and have to be built or bought.

An originating identity carried with each outbound model call, so the record names a person or a scoped service principal rather than a process. Where an agent acts on behalf of a user, the delegation has to be explicit and recorded.

A content classification evaluated before the call rather than after. AutoGen assembles context from whatever the application supplies, and no client in the list inspects that content against a policy.

A decision record written by something other than the calling process, carrying identity, model destination, classification, policy version and outcome. That is the difference between telemetry and evidence, and it is the argument the post-authentication gap sets out at length.

What to sample this quarter

Take one production agent. Export its client class, provider, model identifier, credential source, and whether the documentation marks that client experimental today. Run one request and keep the full event log output alongside the outbound request as it left the host.

Then check whether the two agree. In the deployments where they disagree, the reason is almost always a retry or a tool call that the event logger recorded differently from what crossed the wire, and that discrepancy is worth more than any policy document in convincing an engineering lead to move the record out of the process.

Finish with a denied test against a classification that should never reach the configured provider. If nothing refuses it, the finding writes itself.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For AutoGen agents whose model clients are pointed at it, DeepInspect evaluates the supplied identity and role against organisational policy for content classification and model authorisation before the request reaches the provider.

Each decision produces a signed, tamper-evident record held outside the calling application's write path, which answers the reconstruction question the framework's own event logger cannot: which identity authorised which model call, under which policy version, with what outcome.

Book a technical deep dive at deepinspect.ai.