CrewAI DLP: The Delegation Chain Moves Data That No Single Agent Ever Saw
A CrewAI crew with four agents and a hierarchical process produces far more model calls than the task list suggests, because delegation, shared memory and tool output all become context on the next call. Instrumenting the first call and treating the rest as internal traffic misses most of the content leaving the boundary. This piece walks the four data paths inside a crew, explains why the manager agent concentrates the risk, and sets out where classification and per-decision records belong.
A crew of four agents runs a single task: summarize this quarter's contract exceptions. The task list has one entry. The trace has 31 model calls.
That gap is where CrewAI DLP lives. A team instrumenting the entry point captured one request. The other 30 carried delegated sub-tasks, retrieved memory, tool results, and the full accumulated context of everything the crew had done so far, and each one crossed the same network boundary to the same provider.
I want to walk the four paths content takes inside a crew, and where each one leaves.
Four paths, four content profiles
The task path carries what the operator asked for, plus the agent's role, goal and backstory. This is the smallest and most deliberate slice, and it is the one every AI usage dashboard records.
The delegation path carries a sub-task written by one agent for another. In a hierarchical process, the manager agent composes these, and the composition includes whatever the manager knows at that point. A manager that has already read three contracts writes a delegation containing excerpts from those contracts. The receiving agent's model call now carries content the operator never routed to it.
The memory path carries retrieved entries from short-term, long-term and entity memory. CrewAI's memory writes summaries of completed steps and reads them back on later calls. Content classified as sensitive on Monday gets summarized into a memory entry, and that summary is retrieved and sent on Thursday as background context for an unrelated task. The classification decision made at write time governs nothing at read time unless something re-evaluates it.
The tool path carries whatever a tool returned. A database query tool returns rows. A file reader returns file contents. That output goes straight into the next model call as observation text, in full, because the agent needs it to reason. A tool that returns a 200-row customer table has just put 200 customer records into a prompt.
The tool path is reliably the largest by volume and the least represented in AI governance inventories, because it was built by whoever wired the integration rather than by whoever ran the AI review.
The manager agent concentrates everything
In a hierarchical crew, one agent sees all of it. The manager reads every worker's output, composes every delegation, and holds the accumulated state across the run.
That produces a single model call, usually late in the run, carrying a context window with content from every data source the crew touched. A crew that reads from a CRM, a contracts repository and an internal wiki produces a final manager call containing material from all three, concatenated, in one request.
A per-source access review says each agent had legitimate access to its own source. The manager call is the place where three separately-approved accesses become one combined disclosure, and no per-source review catches it. That combination is the finding worth going and looking for today.
Why sequential and hierarchical processes need different controls
A sequential process passes output forward in a chain. Content accumulates linearly, and the last agent in the chain carries the most. Instrumenting the final step gives a reasonable picture of total exposure.
A hierarchical process fans out and back in, with the manager as the hub. Content concentrates at the hub rather than at the end, and the number of model calls scales with delegation depth rather than with task count. A crew configured with allow_delegation=True on every agent can produce delegation chains several levels deep from one operator instruction, and the depth is decided at runtime by the model.
Setting a maximum delegation depth is a control most teams skip because the default behaviour looks fine in testing, where tasks are small. It stops looking fine when a production task fans out to 40 calls.
What CrewAI DLP has to classify
Classification runs on the assembled request rather than on the operator's original input, because the operator's input is the smallest part of what gets sent. The general practice is covered in prompt-level DLP.
For delegation payloads, the useful policy is about what a sub-agent is allowed to receive rather than what it is allowed to request. An agent whose role is public-facing summary writing has no reason to receive raw contract text in a delegation body, and that constraint is enforceable at the point the delegation becomes a model call.
For memory reads, classification runs at retrieval time. A memory entry summarizing sensitive content carries the sensitivity of the original, and the summary is what gets sent.
For tool output, classification runs before the observation is appended to context. This is the highest-value intervention point in the whole crew, because it is where bulk structured data enters an unstructured prompt. Truncating a 200-row result to the 5 rows the agent actually needs is a change any team can measure, and it usually costs nothing in answer quality.
The classification practice itself is covered in AI data classification.
The record
The unit of interest is the crew run, with each model call attributed inside it.
decision_id: d-c40b19, recorded at 2026-08-14T11:41:02Zcrew_run_id: run-2026-08-14-0093,call_index: 17 of 31originating_identity: s.adeyemi@example.com, the human who started the runacting_agent: contract-analyst,delegated_by: crew-manager,hop_depth: 2context_sources: tool:contracts-db, memory:long-term, delegation:crew-managerclassifications: contract-terms on 14 spans, customer-pii on 3policy: crew-egress-v1,outcome: redacted
The context_sources array is what makes a crew run reconstructable. Without it, an incident review of call 17 of 31 starts from a prompt blob with no provenance, and working out which of three data sources contributed the sensitive span takes a day. The originating_identity field carries the human who started the run, which is what attributes 31 model calls to a person rather than to a service account.
The observability side of this is covered in LLM observability, and the identity side in agent-to-agent authorization.
DeepInspect
This is the gap DeepInspect closes. DeepInspect sits as a stateless proxy on the HTTP path between your agents and the model endpoints they call, which in a CrewAI deployment means every one of the 31 calls rather than the one the application logged. Content is classified before the request is forwarded, policy is evaluated against the identity that originated the crew run, and a per-decision record is written into storage you control.
Because the proxy sits below the framework, delegation payloads, memory retrievals and tool observations are all inspected on the same terms, with no per-agent instrumentation to maintain as the crew definition changes. Enforcement is inline and fails closed.
DeepInspect does not design your crew topology, tune your memory configuration, or write your tools.
If your crew produces 30 model calls from one operator instruction and you have visibility into one of them, the other 29 are the exposure. Book a demo today.