The question of how can CrewAI agents leak data has one direct answer: through six runtime paths CrewAI does not classify by default. Prompt context, inter-agent messages, shared memory, tool parameters, Model Context Protocol (MCP) server calls, and output channels each carry data that no built-in classifier inspects. AppSec teams want developers to use CrewAI without turning agent context into an unmanaged data path, which means governing each path at runtime.

Last updated: August 2026.

CrewAI is an open framework for building crews of role-based AI agents that reason, delegate tasks, and call tools to complete work. Its capability-first design puts data protection on the developer, not the framework. This page maps each leakage path, explains the mechanism behind it, and shows where inline controls apply policy before data leaves its intended boundary.

CrewAI’s capability-first design leaves data classification out of the default path

CrewAI documents roles, tasks, tools, memory, and delegation as productivity features. The docs cover all five, but they do not describe a default inline classifier for prompts, tool parameters, or outputs (CrewAI Docs: Agents, 2026). A crew will let an agent embed a customer record in a tool parameter or forward proprietary source code to a downstream API, because nothing in the default execution path evaluates content. CrewAI permissions, memory scope, and delegation settings decide what an agent can reach, not what data it carries along the way.

Take a simple crew with three roles: a researcher that retrieves documents, an analyst that summarizes them, and a writer that drafts and sends output. Each handoff, researcher to analyst and analyst to writer, passes context that may contain personally identifiable information (PII), credentials, or regulated data. This is the human-to-agent delegation phase in practice: a person assigns work to a crew, and the crew reasons and hands context between roles. No built-in step inspects that context before it accumulates in shared memory or reaches an output tool. The gap is not a flaw in CrewAI; it is a scope boundary the framework leaves to the developer.

The shift toward retrieval and agentic pipelines has widened the data-leakage surface, which is why OWASP added System Prompt Leakage (LLM07) and Vector and Embedding Weaknesses (LLM08) as distinct entries in its 2025 risk set for AI applications (OWASP, 2025). A crew that retrieves from a vector store and passes results between roles touches exactly the surfaces those entries describe.

Direct and indirect prompt injection: the primary trigger for data exposure

Prompt injection takes two forms in a CrewAI deployment. Direct injection is a user or operator instruction that overrides the agent’s intended task scope. Indirect injection is more dangerous: malicious instructions hidden inside a document, webpage, search result, or tool response that the agent processes as trusted input, without ever seeing a user-supplied command. OWASP ranks Prompt Injection (LLM01) and Sensitive Information Disclosure (LLM02) among the top risks for AI applications, alongside Excessive Agency (LLM06).

In a crew, one poisoned input can steer an agent to read a secret and write it out through a second tool, two individually permitted actions that move sensitive data outside its intended boundary. The framework lets agents call tools and pass results to other agents in sequence, so an indirect injection that reaches the researcher role propagates forward to the writer role with no inspection at the handoff. A CERT/CC vulnerability note describes four chained flaws in CrewAI, including server-side request forgery, remote code execution, and arbitrary local file read, that combine through prompt injection to achieve sandbox escape, host-level code execution, and credential theft (CERT/CC, 2026).

Sandbox escape is the point where an agent leak becomes a host compromise. Once an injected instruction reaches remote code execution, the attacker is no longer limited to what the agent was authorized to touch. Environment variables holding API keys, credential files on disk, cached tokens, mounted volumes, and local build artifacts all become reachable. The agent’s original task scope no longer matters; the exposure surface is whatever the host process can read. That is why sandbox isolation and host-level controls belong in any CrewAI threat model, not just prompt-level defenses.

Shared memory, delegation, and logs propagate data invisibly across agents

CrewAI memory, task context, and delegation each extend the data path beyond a single agent turn. Short-term task context passes findings from one agent to the next. Long-term memory accumulates state across runs, and any agent with access can reuse that state in a later task. Delegation lets a manager agent assign subtasks to specialist agents, carrying the delegating agent’s context along with the assignment (CrewAI Docs: Memory, 2026). Each is an unmonitored propagation channel for sensitive data.

Log accumulation adds a persistent dimension. As agents run, they write step records, tool invocation details, and intermediate outputs to logs. Those logs can capture regulated data, authentication artifacts, or internal system paths that were present in the task context. Credential and token exposure often surfaces here first: a failed API response echoed into a stack trace, a debug log that prints a request header, a tool exception that includes the payload, an environment variable rendered into an error message. Each is a place where a secret leaves the intended boundary without any agent deciding to send it. Without classification at the point of logging, the audit trail itself becomes a leakage surface that outlives the original task.

One survey of privacy failures in agentic AI systems argues that memory-induced leakage carries added weight because of its permanence and autonomous reuse: credentials, sensitive inputs, and regulated data can pass through multiple pipeline components, each a potential exposure point (Frontiers in Computer Science, 2026). Data that entered a crew for a narrow purpose can resurface in a later run under a different agent with a different tool set.

Tool parameters, MCP connections, and output channels at the execution layer

In many CrewAI deployments, the tool call is where sensitive data crosses a boundary. When an agent forms a tool parameter, it can place PII, a customer record, source code, or a live credential into an API request that exits the trust boundary (CrewAI Docs: Tools, 2026). A research agent that also holds write access to email or repository tools, for example, carries a combination that can move sensitive findings to external systems, not because either permission is wrong, but because together they create excessive agency.

Output channels are the last mile of that risk. A crew’s final answer rarely stays in a console. Agents route responses to Slack messages, email, repository comments, pull request descriptions, ticketing systems, webhooks, and third-party APIs. Any of those destinations can carry PII, secrets, or proprietary content the crew assembled along the way, and once the message posts, the leak is external and often permanent. Output sanitization that classifies the response before it is forwarded is the control that matches this path.

MCP is one common tool-execution pattern, not the whole agent access-control problem, but it concentrates risk at the server trust layer. Teams often trust MCP servers implicitly, and tool poisoning, where hidden instructions ride inside a tool description, can redirect data with no change to the agent’s visible prompt. Supply-chain risk compounds this: a server update that modifies a tool description after approval can introduce behavior security teams never reviewed. Researchers found more than 12,520 internet-accessible MCP services, mostly unauthenticated, because the protocol does not require authentication by default (Censys, 2026). An impersonating server that mimics a trusted one produces tool calls that look identical to sanctioned activity on the network.

A CI/CD scenario, and leakage paths mapped to controls

Picture a CrewAI release crew: one agent reads a repository, a second runs tests, and a third opens a pull request and posts a summary to a chat channel. To do the work, the crew holds a deployment token, reads source files, and processes build logs. A single indirect injection in a dependency’s README or a build log line can steer the summary agent to echo the deployment token into the pull request description or the chat channel. Two normal actions, reading a build log and posting a summary, combine into a credential leak. Network data loss prevention (DLP) and security information and event management (SIEM) tooling can miss this because the chat post and the API call look like authorized traffic; they may see the destination without the tool parameter content, the agent intent, or how the token moved across the delegated steps.

Least privilege for AI agents means each CrewAI agent reaches only the tools and data its role and task require, and every data-touching action is inspected and recorded in context. Aurascape applies that at the interaction layer: it inspects the actual tool payload and agent output, correlates the agent’s intent with what the tool receives, then applies allow, coach, notify, redact, redirect, block, capture, or require tenant on the action before data leaves. The enforcement point is the interaction itself, the context is the full conversation and the tool parameter, and the outcome is a policy decision applied in real time rather than a log read afterward. Aurascape uses real-time data classifiers to catch a customer record or secret when the parameter is formed, and applies direction-aware classification that catches secrets in both tool call requests and results (Aurascape, 2026). For governed workflows, Aurascape verifies approved tool calls and blocks unmarked calls before execution, and it discovers local CrewAI agents and their connected MCP servers so unapproved crews show up in the inventory before they widen the data path.

For related coding-agent leakage patterns, see how coding agents can expose source code or secrets and the risks of Claude Code with company source code.

A developer and AppSec sequence to reduce CrewAI data leakage

Framework-level hygiene and runtime governance work together. The order below moves from what a developer controls in code to what security enforces at runtime. Scoping CrewAI permissions tightly at each role is the first and cheapest control available.

1. Scope each agent role to the minimum tools and data its task needs. Treat delegation permissions as a privilege, not a default, and avoid combining write-access tools across roles that also read sensitive data stores.
2. Apply role-based access control (RBAC) and domain allow-lists so tools reach only approved destinations, and restrict memory visibility to the agents that need it for their assigned task.
3. Sanitize and classify tool payloads and outputs before they cross a boundary. Strip secrets from responses, mask tokens in logs, and never place authentication materials in prompts, task context, or memory that other agents can read.
4. Pin MCP tool definitions at sanction, require explicit admin review before a server-side update takes effect, and inspect tool descriptions for hidden instructions or auto-approve settings before granting production access.
5. Inspect tool payloads and agent outputs inline with real-time data classification, applying the canonical policy actions: allow, coach, notify, redact, redirect, block, capture, and require tenant.
6. Route agent-to-tool traffic through a gateway that marks approved calls and blocks unmarked ones in governed workflows, so a tool call the agent was never sanctioned to make cannot execute.
7. Keep audit trails that link each agent role and task to every data-touching action, with interaction records governed by RBAC, so AppSec teams can reconstruct a delegated workflow and confirm what data moved where.

Governance is where many teams stall. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, with inadequate risk controls cited as a primary reason (Gartner, 2025). Runtime controls that close each leakage path at the interaction layer keep a CrewAI deployment on the right side of that projection. For more framework context, see Microsoft Foundry agents and data exposure and Copilot Studio agent DLP and compliance.

CrewAI audit logs, compliance evidence, and the interaction-layer record

CrewAI records agent steps and tool invocations, but its logs capture execution flow rather than classify the data that moved through each step (CrewAI Docs: Observability, 2026). Reconstructing which agent carried which data across a delegated workflow, and whether any of it was regulated, takes an additional classification and evidence layer.

Execution logs and compliance-grade evidence are not the same artifact. An execution log answers what ran and in what order. Compliance-grade evidence answers what data was present, what a tool received, and what policy decision applied, tied to a specific agent role and task. Interaction-layer evidence provides that second record: preserved as interaction records for audit and effectiveness, governed by RBAC for privacy. That supports compliance obligations without implying guaranteed compliance. The EU AI Act sets logging and traceability requirements for higher-risk AI systems, and a record that ties an agent action to the data it touched supports those obligations (EU AI Act, 2024). NIST’s Secure Software Development Framework supports the narrower point: teams need verifiable control evidence for software components that handle sensitive data (NIST, 2026).

Frequently asked questions

How can CrewAI agents leak data?

A crew can expose data anywhere context moves without inspection: an injected prompt, a handoff between roles, memory reuse, a tool parameter, an MCP call, or a forwarded output. Any of these can carry PII, source code, or credentials past the intended boundary.

Does CrewAI have built-in data protection?

The CrewAI docs describe roles, tasks, tools, memory, and delegation, but not a default inline classifier for prompts, tool parameters, or outputs. The developer and the controls around the crew supply data protection.

What is the difference between direct and indirect prompt injection in CrewAI?

Direct injection comes from a user or operator instruction that overrides the agent’s intended task scope. Indirect injection hides inside a document, webpage, search result, or tool response that the agent treats as trusted input, often with no visible user command.

Why do traditional security tools miss CrewAI leaks?

A crew’s tool calls and chat posts look like authorized API traffic. Destination-based tools pass them through without seeing the payload content, the agent’s intent, or how data changed hands across delegated steps.

What CrewAI permissions risk creates excessive agency?

Give one agent both read access to sensitive data stores and write access to email or repository tools, and you create excessive agency: each permission is reasonable alone, but together they let sensitive findings move to external systems without a classification step.

How does an inline gateway help with MCP tool-call governance?

In governed workflows, a Zero-Bypass MCP Gateway marks every approved call and blocks unmarked calls before execution. A tool action that was never sanctioned, including one an injected prompt tried to trigger, cannot complete, because the mark is checked before the tool runs.

Can shared memory cause a data leak long after the original task?

Yes. When long-term memory persists across runs, an agent with access can reuse earlier state in a later task. Data captured for a narrow purpose can resurface under a different agent with a different tool set, widening exposure over time.

What should CrewAI audit logs capture for compliance?

Compliance-grade evidence should link each agent role and task to data-touching actions: what data was present, what the tool received, and what policy decision occurred. Execution step logs alone record flow, not the classified data path across agents.

Aurascape closes the CrewAI leakage paths at the point they open: inline data classification on tool payloads and outputs, a Zero-Bypass MCP Gateway that governs the agent-to-tool execution path in governed workflows, continuous discovery of undeclared crews and MCP servers, and interaction-level evidence linking governed agent actions to the data they touched. Teams get control at the point data leaves, not just a record reviewed after the run.

See how Aurascape governs CrewAI agents across memory, tools, and delegation →