I was reviewing the audit logs for my CrewAI crew this morning and noticed something concerning: every agent in the crew had access to the full, global system prompt in their message history. This seems like a significant information leak, especially when dealing with sensitive instructions or segmented knowledge.
Looking at my crew definition, I used the standard pattern from the tutorials:
```python
from crewai import Agent, Task, Crew, Process
manager = Agent(
role="Project Manager",
goal="Oversee the project",
backstory="Experienced manager.",
verbose=True
)
researcher = Agent(
role="Researcher",
goal="Find relevant information",
backstory="Detail-oriented analyst.",
verbose=True
)
```
The issue appears to be that when you don't explicitly provide a `system_prompt` to each individual agent, they default to using the crew's overarching prompt. This means the Researcher agent can potentially see instructions meant only for the Manager, like "you have final approval on budgets" or "do not share X with the other team members."
This is problematic for a few reasons:
* It violates the principle of least privilege.
* It breaks the intended role separation in a crew.
* It creates a risk of prompt leakage or manipulation in the agent's context window.
Has anyone else run into this? What's the recommended practice for scoping system prompts to individual agents in CrewAI to maintain proper isolation? I'm currently working around it by manually setting a unique `system_prompt` for each agent, but that feels like something that should be the default, secure behavior.
Oh wow, that's a really important catch, and honestly a bit scary. I'm new to CrewAI myself and just following tutorials, so I wouldn't have thought to check the audit logs for something like that. Your example about budget instructions or "do not share X" really drives it home.
If I'm understanding right, this means the default setup is basically like giving every employee the master key to the whole building, even the janitor and the intern, which goes against everything I've been reading about security in self-hosting. 😬 Could this be why sometimes my test agents seem to act outside their defined roles? They might be getting confused by conflicting instructions meant for other agents.
Is there a confirmed way to lock this down yet? Like, should we always be defining a unique `system_prompt` for every single agent, even if it's just a basic one, to override that global default? I'd hate to add all that extra code if there's a simpler flag or setting somewhere.
Yeah, that "master key" analogy is spot on, and it likely is why your agents act outside their roles. It's like giving them conflicting scripts.
From my tinkering, you do have to explicitly define a unique `system_prompt` for every agent. There's no simple flag to isolate them, unfortunately. The global default just gets inherited.
But you can keep it minimal. I often use a short base prompt like "You are the [role]. Your goal is to [goal]. Stick strictly to your defined role." Just writing that out once and reusing it as a template variable cuts down the boilerplate a lot.
It's extra code, but it's the only reliable fix right now.
No cloud, no problem.
Totally agreed, and I've been doing the same with a template variable. It feels like unnecessary boilerplate, but it does lock things down.
One caveat I'd add: even with a unique `system_prompt`, you still have to be careful with the `llm` parameter if you're passing a custom config. I made the mistake of defining a custom LLM config with high-level instructions and then passing that same `llm` object to multiple agents. Those instructions ended up in the context for all of them too, basically creating a different kind of leak.
So the rule of thumb is isolation for both `system_prompt` and the `llm` config object. Kind of a pain, but at least it's predictable.
lab.firstname.net
Yeah, a template variable helps with the boilerplate, but it doesn't solve the supply chain issue. Where's that template stored? In a config file that gets committed? Who reviews changes to it? You're just centralizing the risk.
Everyone's focused on the code fix, but nobody's asking for a signed manifest or a way to verify the prompt actually deployed is the one you wrote. What if your `system_prompt` variable gets overwritten by a dependency update or a mis-merge? You're back to square one, silently.
The real pain isn't the extra code, it's the lack of a verifiable boundary.
mj