CrewAI's job is orchestration: defining role-based agents and running them as a "crew" that executes tasks in sequence or under a manager's delegation. Authenticating those agents, authorizing what their tools can do, and capping what they spend at the organization level are governance functions that sit in the layer built around the crew, the same as with most agent orchestration frameworks.
This post covers what CrewAI actually provides, where the resulting gap sits, and what a security or platform team needs to add around it.
What CrewAI provides
CrewAI is a Python framework for building multi-agent systems around the metaphor of a crew: a set of agents, each defined with a role, a goal, and a backstory that shapes how the underlying model reasons about its assignment, working through a list of tasks.
Two orchestration patterns are the core of the framework:
- Sequential process — tasks run in a defined order, with each agent's output available as context to the next.
- Hierarchical process — a manager agent decomposes work and delegates tasks to worker agents, reviewing and combining their output.
Agents are given tools — Python functions or wrapped integrations — that they can invoke to take action: search the web, query an API, read or write a file, call another service. Tasks are attached to agents, and the crew's execution engine handles calling the underlying model, parsing its tool-call intent, executing the tool, and feeding the result back into the agent's context.
All of this happens in-process. There is no external service brokering identity, authorization, or execution — the crew is a Python object graph that runs inside your application, and the tools attached to each agent execute with whatever permissions the process itself holds.
Where the governance gap sits
The gap in a CrewAI deployment shows up in four places, and each one maps to a control that has to live outside the framework.
1. Agent identity
A CrewAI agent's identity is a role name, goal, and backstory string — a prompting construct, not a credential a downstream system can verify. A "researcher" agent and a "reviewer" agent are both, from the perspective of any API or database they call, the same process using the same credentials unless you provision otherwise. If you attach a database credential to a tool, every agent that can invoke that tool inherits the same access — there is no per-agent principal the database, API, or MCP server on the other end can distinguish. This is the same gap covered in why agents need their own credentials: without a distinct identity per agent, you cannot scope access, and you cannot attribute an action to the agent that took it.
2. Tool-level authorization
Tools in CrewAI are attached directly to an agent's definition as Python objects. Whatever the tool's code is capable of doing is what the agent is capable of doing — there is no external authorization check between "the model decided to call this tool" and "the tool executed." If a tool wraps a broad API client (say, a full-access ticketing or CRM client) so that one function can be reused across several agents, every agent holding that tool has the CRM client's full permission set, whether or not the agent's task requires it. This is precisely the over-provisioning problem addressed by least-privilege design for agents: the fix is scoping the credential the tool holds, not trusting the agent's role description to constrain its behavior.
3. Delegation in hierarchical crews
In a hierarchical process, the manager agent can decide, at runtime, which worker agent handles which subtask, and can pass along its own reasoning and context. This is a delegation relationship, and it carries the same risk as any agent-to-agent handoff: if the manager can invoke a worker with more effective access than the subtask needs, a compromised or misdirected manager can route sensitive tasks to whichever agent has the broadest tool set. The threat model for agent-to-agent delegation abuse applies directly here — delegated tasks should carry a narrower authorization footprint than the delegator holds. CrewAI's task-passing mechanism moves context and assignment between agents; confirm separately, at the tool and credential layer, that a worker agent's effective access is actually narrower than its manager's.
4. Spend and execution limits
A crew executing a multi-step task can retry, loop through the hierarchical manager, or fan out across several agents, each making its own model calls and tool invocations. CrewAI ships max_rpm and max_iter to bound request rate and iteration count per crew, and per-crew token usage metrics you can read after a run. Confirm what your CrewAI version reports on cost, and where an org-level budget is actually enforced — a per-crew iteration limit and token count are not the same guarantee as a cap tied to organizational spend, an alert on an unusual cost pattern, or a halt when a crew's combined agent activity exceeds an expected envelope. Budget policies with hard spend caps and anomaly detection for agent spend are both external controls worth layering on top, because a runaway crew's model and tool calls are indistinguishable, from a cost perspective, from a legitimate one until the totals are compared against a baseline.
What good looks like
| Control | What CrewAI gives you | What to add externally |
|---|---|---|
| Identity | A role name and backstory string | A distinct, verifiable principal per agent, not per process |
| Tool authorization | Whatever the tool's code permits | Per-tool, per-agent scoped credentials, checked before execution |
| Delegation | Manager-to-worker task assignment | Narrower authorization on every delegated task, logged |
| Spend | Iteration/step limits per crew run | Org-level budget caps and anomaly alerts across all crews |
| Audit | Task output history in the crew's own memory | A tamper-evident log of every tool call, decision, and delegation |
A production CrewAI deployment should be able to answer, for any completed crew run: which agent held which credential, which tools were invoked with which arguments, which delegations occurred and to whom, and what the total cost was against budget. None of that comes from the crew definition itself. It comes from wrapping each tool call in an externally enforced authorization check, issuing distinct scoped credentials per agent rather than per process, logging every delegation and tool invocation to a record that survives the crew's own memory, and monitoring spend against a budget independent of the framework's own rate and iteration limits. Treat the crew as the orchestration layer it is, and put the identity, authorization, spend, and audit layer around it, rather than assuming the crew definition covers it. For the fuller set of controls a multi-agent deployment needs regardless of which framework runs it, see building secure multi-agent workflows and the AI agent security guide.
Common questions
Does CrewAI's role and goal configuration act as an access control?
No. A role string like "financial analyst" or a backstory describing an agent's expertise shapes how the underlying model reasons about its task — it is a prompting technique, not an enforced boundary. Nothing in the framework prevents an agent with a narrowly described role from calling any tool attached to it, including tools that have nothing to do with the described role. If two agents in the same crew share a tool, both have that tool's full access regardless of how differently their roles are described.
Is the hierarchical process safer than the sequential process?
Not automatically. The hierarchical process adds a manager agent that decomposes and delegates work, which introduces a delegation relationship worth scoping carefully, but the authorization check itself is the same external addition either process needs. Both processes execute tools in-process with whatever credentials those tools were configured with. Choosing hierarchical over sequential is a task-decomposition decision, not a security decision, and should not be mistaken for one.
Can a compromised tool in one crew affect other crews running in the same application?
It depends entirely on how credentials are provisioned, not on anything CrewAI itself isolates. If multiple crews share the same broadly-scoped API client or database connection because it was convenient to configure once, a vulnerability or misuse in one crew's tool call can reach whatever that shared credential can reach, independent of which crew triggered it. Provisioning distinct, narrowly scoped credentials per crew — or per agent, where task requirements differ within a crew — contains this blast radius the way least-privilege design does for any other agent architecture. Auditing which credentials are shared across how many agents and crews is worth doing on a recurring basis, not just at initial setup, since shared credentials tend to accumulate quietly as new crews are added to an existing application over time, long after the original reason for sharing them has been forgotten by anyone still on the team.