CrewAI

CrewAI has no identity or authorization layer of its own. Each tool reads whatever API key is in the process environment and builds its own client, so an agent acts with the full authority of every key the developer exported. Local MCP servers do get a reduced environment from the MCP SDK, but nothing checks per request whether the agent, or the user it serves, should be allowed to make a call. With platform apps (Gmail, Slack, Sheets) and third-party tools enabled together, a hijacked agent can write to several outside systems.

Out of the box nothing asks a human before a tool runs: any tool the developer registers, including email, file writes or external APIs, executes as soon as the model calls it. Task 'human_input' only reviews the final answer after actions have already happened. The framework offers before-tool-call hooks that every executor runs and that can block a call or prompt the console user, but a developer has to write that gate, and the hooks do not cover every path. Because the hook is opt-in, its score is capped.

Every tool's arguments are checked against a typed schema before it runs, and the first-party crewai-tools package adds real input controls: file paths are resolved and confined to a base directory, URL fetchers block private and cloud-metadata addresses and re-check every redirect, and the SQL tool is read-only by default. Agents get no tools unless the developer adds them. The weak spots are that the default base directory is the working directory (which holds the project's .env and the auto-loaded training-data file), one environment variable switches off both path and SSRF checks, and custom or MCP tools only get schema typing.

The old local code interpreter has been removed, and the framework ships E2B and Daytona tools that run model code in remote, per-call sandboxes, but those are opt-in. By default, every tool runs inside the agent's own Python process with its environment and network. One default execution path that loads a workspace file is not confined.

CrewAI does nothing to limit what a hijacked agent can do after reading hostile content. Web pages, files, MCP results and other agents' outputs enter the conversation with the same standing as the developer's instructions; there is no tagging, no quarantine and no rule that switches off email or write tools once untrusted text has been read. The official docs show agents that search the web, read local files and send Gmail in the same session, so a successful prompt injection can leak data and take irreversible actions with no human involved.

Memory is off by default; when enabled, the model can save anything with a 'Save to memory' tool and it is recalled into later prompts, stored per project folder with no per-user separation unless the developer adds scoping. Two files in the working directory shape every run without any trust decision: the training-data file, whose contents are added to the prompt as instructions the agent 'MUST follow', and the project's .env, loaded at import, which can redirect model endpoints or switch off the tools' path and SSRF checks. The file-writer tool writes into that same directory by default, so a hijacked agent can make its compromise persistent.

Extensions are chosen by the developer (MCP servers, registry skills, platform apps); nothing third-party is enabled by default, and local MCP servers get a reduced environment from the MCP SDK. But nothing verifies what is loaded: MCP launch commands and registry skills resolve to whatever is latest unless pinned, with no hash or signature checks or re-approval on change. A workspace file loaded by default is not integrity-protected.

API keys come from environment variables (and a project .env loaded at import) and are passed to tools in plain form; the framework has no redaction for logs, events or model-bound messages. The bundled web fetcher does strip credentials on cross-origin redirects, and some configs use masked secret types. Anonymous usage telemetry is on by default but content-free unless the developer opts in with share_crew; content tracing needs explicit consent. Any tool that can read the working directory (the file reader's default scope) can read the .env file into model context.

CrewAI emits structured events for every tool call (tool name, arguments, agent role, timestamps, parent event IDs), but by default nothing records them durably. The opt-in output log file records only task start and end, and opt-in tracing, which does capture tool calls, buffers events in memory and uploads them to the CrewAI platform at the end of a run, so a crash loses the record. There is no attribution of who approved an action.

Each agent stops after 25 reasoning iterations by default, which bounds a single loop. There is no default time limit, cost or token budget, or rate limit; the optional time limit raises an error but leaves the worker thread running to completion. Delegating to another agent starts a fresh iteration budget, and tasks are retried on error, so the effective ceiling multiplies, and there is no stop that interrupts in-flight tool calls.