Why does a multi-agent framework increase data loss risk over a single agent?

Because the conversation history is shared and cumulative. In a single-agent chat, sensitive content leaves once per turn in which it appears. In a group chat, it leaves once per turn per participating agent for the remainder of the workflow, since each agent's model call carries the accumulated history. Adding a specialist agent to improve output quality also multiplies the outbound volume of everything already in the conversation. The risk model changes from counting disclosures to counting disclosures times agents times remaining turns.

Does AutoGen's code execution need a different control from prompt traffic?

Yes, and they should be treated as separate programmes with separate owners. Generated code runs on an execution host through the operating system, so the applicable controls are container isolation, filesystem permissions, network egress rules on that host, and a decision about whether code execution is enabled for a given workflow. Prompt traffic crosses the network to a model endpoint, so the applicable controls are content classification and per-request authorization at that boundary. Neither substitutes for the other, and a security review that inspects only one has covered roughly half the surface.

How do we avoid duplicate alerts from cumulative history?

Fingerprint content at the message level rather than classifying the serialized blob afresh each turn. When a document is flagged on the turn it enters the conversation, subsequent turns carrying the same content match the existing fingerprint and extend the existing finding rather than opening a new one. The operator then sees one finding with an occurrence count and a turn range. Without fingerprinting, a fifteen-turn workflow with six agents generates enough repeat findings to train the operator to ignore them, which is worse than having no classification at all.

What identity should an agent's model call be evaluated against?

The human or system that initiated the workflow, propagated through the request as an explicit header. Evaluating against the shared service credential the agent runtime holds gives every workflow in the organization the same principal, which makes per-role policy impossible and makes audit records useless for attribution. Propagating originating identity is application work, since the framework cannot invent context it was never given. It is the single highest-value change most AutoGen deployments can make before adding any enforcement product at all.

Can we just disable retrieval so agents never see sensitive data?

That removes the capability the workflow exists to provide, so it rarely survives contact with the people who requested the automation. The more durable pattern is classification plus redaction at the boundary, so agents retrieve what they need and restricted values are tokenized before the content reaches the provider. Track the redaction rate per workflow. A workflow with a high rate is telling you it depends on data classes that should probably be handled by a self-hosted model rather than routed to a third party.

How does this compare with DLP for a single chat assistant?

The classifiers are the same and the accounting differs. A chat assistant produces one conversation per user with a predictable shape. An AutoGen deployment produces automated workflows that run without a human watching each turn, at whatever frequency a scheduler triggers them, across whatever systems the agents can reach. The volume is machine-paced rather than human-paced, which means a policy gap that would produce a handful of disclosures in a chat product produces thousands in an agent workflow before anyone reviews a dashboard. The general practice is covered in AI DLP.

← Blog

August 14, 2026

AutoGen DLP: Data Loss Prevention for Multi-Agent Conversations

AutoGen agents pass messages to each other, and a shared conversation history means one sensitive document read once is re-sent to the model on every subsequent turn by every participating agent. This piece walks the message-passing mechanism that multiplies disclosure, separates the local code-execution surface from the model-client surface an enforcement layer can reach, shows where a base URL points a deployment at a policy boundary, and sets out what the per-decision record needs to carry.

ByParminder Singh· Founder & CEO, DeepInspect Inc.

AI Security Solutionsai-securityllm-securitydata-loss-preventiondlpagentic-aipolicy-enforcement

AutoGen DLP: Data Loss Prevention for Multi-Agent Conversations

An AutoGen group chat does not make one model call per conversation carrying one document. Every turn an agent takes produces its own model call, and each call carries the accumulated conversation history, so a document retrieved once early in a five-agent workflow travels outward again on every subsequent turn.

That multiplication is the first thing I would put in front of a security team evaluating AutoGen, ahead of anything about agent design. A single retrieved file read once by one agent leaves the network boundary on every subsequent turn taken by every participating agent, because the shared message history is what gets serialized into each model call.

AutoGen DLP is the practice of classifying and controlling that outbound content at the model client boundary. I want to walk through where the boundary sits, what the framework moves across it, and what falls outside it.

The message-passing mechanism

AutoGen builds workflows from agents that exchange messages. An assistant agent reasons and replies. A user proxy agent represents a human or executes code on their behalf. A group chat coordinates several agents through a manager that decides who speaks next.

The mechanism that matters for data movement is that the conversation is shared. When one agent retrieves a document, that content enters the message history. The next agent to speak receives the history as input, and its model call carries the document. So does the one after it. Nothing in the framework prunes the history by sensitivity, because the history is what gives the agents continuity.

The consequence is arithmetic rather than architectural. Disclosure volume scales with agents multiplied by turns, and both numbers grow as teams add specialists to a workflow. A workflow that started with two agents and four turns and now runs six agents over fifteen turns increased its outbound exposure by more than an order of magnitude without anyone changing what data it touches.

Where the enforceable boundary sits

Two surfaces in an AutoGen deployment carry data, and only one of them is reachable by a network control.

The model client is the reachable one. Every agent holds a client configured against a model endpoint, and each turn produces an HTTPS request to that endpoint carrying the serialized message history. The request has a destination, a payload and, if the deployment is built that way, an identity, and each of those is a policy input.

Code execution is the other surface, and it sits outside. AutoGen's code executors run generated code, either as a local subprocess or inside a container, and a script that reads a file and writes it somewhere is doing so through the operating system rather than through the model client. Container isolation, filesystem permissions, egress rules on the execution host and whether code execution is enabled at all are the controls that apply. A proxy between agents and models has no view of a subprocess reading /etc/.

Anyone selling an AI gateway as a control on generated code execution is describing a sandbox they do not operate. The honest split: prompt content is governed at the model client boundary, while generated code belongs to the execution host and its operating-system controls. Both programmes are needed.

Pointing a deployment at a policy boundary

The practical mechanism is that AutoGen's model clients accept a base URL. Directing that at an enforcement layer rather than at the provider puts every agent's outbound traffic through one policy point without rewriting agent logic.

Constructing an OpenAIChatCompletionClient with base_url set to an internal gateway host instead of the provider is the whole change, and two additional default headers carry the context policy needs:

X-Originating-Identity, set to the email of the human who started the workflow
X-Workflow-Id, set to the identifier that ties every turn back to one run

Two things in that snippet matter more than the base URL itself. The originating identity header is what lets policy evaluate a call against the human who started the workflow rather than against a shared service credential, and without it every agent in every workflow looks like the same principal. The workflow identifier is what makes a per-decision record reconstructable as a conversation rather than as sixty disconnected requests.

Deployments that skip both end up with an enforcement layer that can classify content and cannot attribute it, which produces alerts nobody can action.

What AutoGen DLP has to classify

Classification runs on the serialized message history, which is a different shape from a single user prompt.

The history is cumulative, so a naive classifier re-flags the same content on every turn and buries the operator in duplicates. Content fingerprinting at the message level, so that a document flagged on turn three is recognized as the same document on turn eleven, is what keeps the signal usable. The classes themselves follow the organization's policy: customer PII, PHI where healthcare data is in play, source code with IP indicators, contract terms, credentials pasted into a message by an agent that read a configuration file.

The credential case deserves its own attention in multi-agent workflows. An agent that reads a configuration file to answer a question puts its contents into the shared history, and that history then travels to the model provider on every remaining turn. The general practice of classifying inside the context window rather than at the document level is covered in prompt-level DLP.

The record, and why the framework's own logs are the wrong source

AutoGen emits its own message logs, and they are genuinely useful for debugging a workflow. They are the wrong artifact for a compliance question, because the component that made the disclosure is the component writing the account of it.

An independent record at the request boundary carries the fields an investigation needs:

decision_id: d-77e0c4, recorded at 2026-08-13T11:07:33Z
originating_identity: j.mbeki@example.com, under workflow_id wf-4417
agent and turn: research_assistant, turn 11
classifications: customer-pii, contract-terms
content_fingerprints: cf-9a12 and cf-3b80
policy: agent-egress-v4
outcome: redact, before the call reached api.openai.com

The fingerprint field is what turns sixty records into a story: the same document appearing under cf-9a12 from turn three onward shows exactly when it entered the conversation and how many times it left the boundary afterwards.

DeepInspect

This is the gap DeepInspect closes for AutoGen deployments. DeepInspect sits at the AI request boundary as a stateless proxy between your agents and the model endpoints they call. Pointing an AutoGen model client's base URL at it puts every agent turn through one policy evaluation: the serialized history is classified, the call is evaluated against the identity that originated the workflow, and a signed record is written before the request proceeds, with enforcement failing closed.

The scope claim stays narrow. DeepInspect does not sandbox generated code, does not manage the execution host, and does not govern what a subprocess reads from disk. It covers the HTTP traffic between your agents and their models, which in an AutoGen deployment is where the accumulated conversation history actually leaves.

If you are running multi-agent workflows and cannot say how many times last month's contract draft left your network, the per-turn record above is what answers it. Book a demo today.

Frequently asked questions

Why does a multi-agent framework increase data loss risk over a single agent?: Because the conversation history is shared and cumulative. In a single-agent chat, sensitive content leaves once per turn in which it appears. In a group chat, it leaves once per turn per participating agent for the remainder of the workflow, since each agent's model call carries the accumulated history. Adding a specialist agent to improve output quality also multiplies the outbound volume of everything already in the conversation. The risk model changes from counting disclosures to counting disclosures times agents times remaining turns.
Does AutoGen's code execution need a different control from prompt traffic?: Yes, and they should be treated as separate programmes with separate owners. Generated code runs on an execution host through the operating system, so the applicable controls are container isolation, filesystem permissions, network egress rules on that host, and a decision about whether code execution is enabled for a given workflow. Prompt traffic crosses the network to a model endpoint, so the applicable controls are content classification and per-request authorization at that boundary. Neither substitutes for the other, and a security review that inspects only one has covered roughly half the surface.
How do we avoid duplicate alerts from cumulative history?: Fingerprint content at the message level rather than classifying the serialized blob afresh each turn. When a document is flagged on the turn it enters the conversation, subsequent turns carrying the same content match the existing fingerprint and extend the existing finding rather than opening a new one. The operator then sees one finding with an occurrence count and a turn range. Without fingerprinting, a fifteen-turn workflow with six agents generates enough repeat findings to train the operator to ignore them, which is worse than having no classification at all.
What identity should an agent's model call be evaluated against?: The human or system that initiated the workflow, propagated through the request as an explicit header. Evaluating against the shared service credential the agent runtime holds gives every workflow in the organization the same principal, which makes per-role policy impossible and makes audit records useless for attribution. Propagating originating identity is application work, since the framework cannot invent context it was never given. It is the single highest-value change most AutoGen deployments can make before adding any enforcement product at all.
Can we just disable retrieval so agents never see sensitive data?: That removes the capability the workflow exists to provide, so it rarely survives contact with the people who requested the automation. The more durable pattern is classification plus redaction at the boundary, so agents retrieve what they need and restricted values are tokenized before the content reaches the provider. Track the redaction rate per workflow. A workflow with a high rate is telling you it depends on data classes that should probably be handled by a self-hosted model rather than routed to a third party.
How does this compare with DLP for a single chat assistant?: The classifiers are the same and the accounting differs. A chat assistant produces one conversation per user with a predictable shape. An AutoGen deployment produces automated workflows that run without a human watching each turn, at whatever frequency a scheduler triggers them, across whatever systems the agents can reach. The volume is machine-paced rather than human-paced, which means a policy gap that would produce a handful of disclosures in a chat product produces thousands in an agent workflow before anyone reviews a dashboard. The general practice is covered in AI DLP.

← All posts