When I run a CrewAI crew that has tool access — shell, HTTP, a code interpreter — I keep running into the same worry: the crew logic and the trust boundary around it are two different problems, and CrewAI (rightly) only owns the first one.
Concretely, two things I haven’t found a clean community pattern for:
1. Credential isolation. If an agent has my API keys in its environment and it also has an HTTP or shell tool, a prompt injection in a fetched page can read those keys and exfiltrate them. Passing keys in as plain env vars feels wrong. How are you scoping secrets so a single misbehaving tool call can’t walk off with everything? Read-only mounts? A broker process the agent calls instead of holding the key? Something else?
2. Egress control. Same shape — an agent with a network tool can reach any host by default. I’d like an allowlist: this crew may talk to my vector DB and the model API, nothing else, and anything off-list gets logged (or blocked). Are people doing this at the container/network layer (iptables, a proxy sidecar), or is there a CrewAI-native hook I’m missing?
Context, so this isn’t abstract: I’m building an open, Apache-2.0 sandboxed runtime for agents (enclave) — container isolation, an egress allowlist, a read-only secrets mount — the layer an agent process runs inside, underneath whatever framework wires the logic. So I’ve got a strong bias toward “solve it at the runtime, not the framework.” But I’d genuinely like to know what’s worked for people staying inside CrewAI: sidecars, custom tool wrappers, network policies, war stories where isolation would have saved you.
What are you actually running in production?