Can a gateway secure a whole CrewAI deployment?

No, and any tool that claims to should be treated with suspicion. A CrewAI crew runs Python in your process space: inter-agent delegation, memory, and tool execution happen locally, and a code-execution tool can run a subprocess a network proxy never sees. A gateway governs what crosses the network to a model, and any HTTP tool traffic routed through it. The local execution surface is a separate application-security job. The honest pattern is a gateway on the model boundary plus real controls on the runtime itself.

Why give each CrewAI agent its own identity?

Because a shared provider key collapses the forensic trail. With one key across a researcher, a writer, and a manager agent, every call looks identical to the provider and to any audit, so nobody can attribute a prompt to the agent that sent it. Minting a per-agent identity and routing each agent's LLM through a gateway binds every model call to the specific agent, which is what makes per-agent policy and a usable audit record possible.

How do you route CrewAI model calls through a gateway?

CrewAI sends model calls through LiteLLM, so you set the LLM's base URL to the gateway and give it a per-agent token instead of the raw provider key. The gateway verifies the token, applies policy, and forwards to the real provider using a key it holds itself. Combined with egress control that blocks direct connections to provider hosts from the app tier, this makes the gateway the single path every agent's model call travels.

Does prompt injection against a CrewAI agent get stopped at the gateway?

Partly, and it helps to be precise about which part. An injected instruction that changes what an agent decides to do executes inside the crew's runtime, which is outside a network gateway. What the gateway does see is the outbound result: if the injection drives the agent to send a restricted data class to the model or to reach a disallowed endpoint, identity-bound policy and egress control block that call and record it. The gateway does not stop the agent from being manipulated. It stops the manipulated agent from moving data it is not authorized to move.

CrewAI Security Patterns: Governing What Your Agents Send to the Model

A CrewAI crew is Python that runs in your process space. You define agents with a role, a goal, and a set of tools, group them into a crew, and pick a process, sequential or hierarchical, that decides how tasks flow between them. The framework handles delegation, memory, and tool invocation locally. Under the hood, when an agent needs the model, CrewAI routes the call through LiteLLM to an LLM endpoint over HTTP.

That last sentence is where security patterns for CrewAI actually attach. Most of what a crew does, the task delegation, the local memory, the tool execution, happens inside your own runtime and is an application-security problem. The part that leaves your environment is the outbound HTTP call to the model, and that is the part a gateway governs.

Draw the boundary before writing controls

Be honest about what a network gateway can and cannot reach in a CrewAI deployment, because the wrong mental model produces controls that do nothing.

Inside the boundary a gateway enforces:

An agent's call to an LLM, which CrewAI sends over HTTP through LiteLLM.
An HTTP tool that reaches an external API, if that tool's traffic is routed through the gateway.

Outside that boundary:

Inter-agent delegation and the process controller, which run in-process.
Local memory reads and writes.
A code-execution tool that runs a subprocess on the host. That is local execution, and a proxy between agents and models never sees it.

A gateway secures the model traffic and the HTTP tool traffic. It does not sandbox a crew that runs arbitrary Python. Treat the local execution surface as a separate application-security job, and keep the gateway focused on what crosses the network to a model.

Give each agent its own identity on model calls

The default CrewAI pattern points every agent at one provider key. A researcher agent, a writer agent, and a hierarchical manager agent all authenticate to the model as the same credential. When something goes wrong, the forensic trail ends at the shared key, and nobody can say which agent sent which prompt.

Configure each agent's LLM to route through the gateway, and have the application present a per-agent identity the gateway can bind to:

The gateway verifies the per-agent token, evaluates policy against that agent identity, and holds the real provider key so no agent can address the provider directly. Now the audit trail names the researcher agent, not a shared key.

Classify the prompt, because agents assemble context you did not write

A CrewAI agent builds its own prompt from its backstory, the task, the tool output it just received, and its memory. That means the content leaving for the model is assembled at runtime, and a retrieved document or a tool result can carry data an agent should not be sending. The gateway classifies the actual outbound prompt against regulated data types and applies policy on the data class, not on a template the developer reviewed once. This is the same reason agentic runtime security has to inspect the request rather than trust the design.

Constrain egress so an agent cannot route around the gateway

A per-agent identity means nothing if an agent can still open a direct connection to the provider. Restrict egress from the crew's runtime so the only route to any model endpoint is through the gateway:

With egress locked down, a misconfigured agent or an injected instruction that tries to reach a provider directly fails at the network, and the gateway remains the single place every model call passes through.

Record what each agent asked the model

Every model call an agent makes produces a decision record: the agent identity, the task context, the data class in the prompt, the pass-or-block outcome, and the policy version. For a hierarchical crew where a manager agent delegates to workers, that record is what lets a later review reconstruct which agent, under which task, sent which class of data to the model. The record commits before the response returns, on a write path the crew cannot alter.

DeepInspect

This is exactly what DeepInspect does. A CrewAI crew makes model calls over HTTP, and DeepInspect sits at that boundary between your agents and the LLM endpoints they call.

For every agent request, DeepInspect binds the call to the per-agent identity the application supplies, classifies the assembled prompt against regulated data types, applies the per-agent and per-route policy, and makes a deterministic, fail-closed decision before the request reaches the model. Every decision commits a signed, identity-bound audit record before the response returns, on a write path the crew never controls. DeepInspect governs the model traffic and any HTTP tool traffic routed through it, and it does not claim to sandbox the local Python a crew executes, which stays an application-security problem. If you are running CrewAI agents on a shared key and cannot say which agent sent what to which model, book a demo today.