Swarms

Name: Swarms: 1.1/10 (Minimal) · SafetyCard
Item: Swarms
Rating: 1.1
Author: SafetyCard

Python framework for building single agents and multi-agent systems (sequential, concurrent, hierarchical, graph workflows) on LiteLLM.

github.com/kyegomez/swarms · 2026-10-04 · a87cece

Defense-in-depth score

1.1 / 10

Swarms ships almost no safety controls on its tool path: no approval gate, no sandbox, no argument validation, and no restriction after reading untrusted content. Its autonomous mode gives the model a host shell with the full environment behind only a denylist that is not a strict boundary, plus file tools that accept any absolute path. Telemetry is on by default and sends tasks, outputs and agent configuration to a vendor endpoint, and secret handling and transport security are not locked down either.

Safest setup

Swarms runs a single loop by default and turns on no MCP servers or persistent memory unless you add them, and its autonomous mode stops after fixed iteration counts. It has no approval step, no sandbox and telemetry on by default, so the safest setup narrows the tool set, turns telemetry off and builds the containment around the process yourself.

Setup	How	What it gives you
Scoped, low-limit keys	Run the agent in an environment holding only the model key and tool credentials this agent needs, each scoped with a spending limit set at the provider	Whatever the agent or its subprocesses do, they reach only the systems and spend you chose C1
Only the tools needed	Pass `selected_tools` a list naming only the tools the task needs, such as `read_file` and `list_directory`	In autonomous mode the model is offered only those tools, with shell and delete tools added only when you choose C3
Tight loop budgets	Keep the default `max_loops=1`, and in autonomous mode lower `max_subtask_iterations` and `max_subtask_loops` for short tasks	Every run ends after a fixed number of model turns C10
Session-only memory	Keep the default `persistent_memory=False`	Each session starts fresh, so nothing one run reads is replayed as context in the next C6
A clean working directory	Start agents from a directory where neither it nor any parent holds a .env file you didn't write	Model endpoints, keys and other settings come only from you C6
Telemetry turned off	Set `SWARMS_TELEMETRY_ON=false` in the process environment	Tasks, outputs and agent configuration stay on your machine C8
Its own container or VM	Run the agent in a container or VM with no host credentials and network access limited to the hosts the task needs	An outer boundary around shell commands, file tools and MCP servers, and a narrow path for data to leave C4
A saved conversation	Set `autosave=True` on `Agent`	A record of each run's messages and tool output that outlives the process C9

Approving with confidence

Swarms has no approval step, so read each MCP server's command before adding it and pin its version there; the framework runs it as given.

Handling data

Logs and saved conversations go under WORKSPACE_DIR, which the agent's file tools can reach; copy them to storage the agent can't modify and keep them like other sensitive logs.

Key gaps (4)

Autonomous-mode run_bash executes model-written commands on the host with shell=True and the full environment, guarded only by a substring denylist. C4 · Code-execution isolation
No authorization layer or scoped identity: a hijacked agent acts with the operator's full ambient authority. C1 · Identity & least privilege
A hijacked autonomous agent can both exfiltrate secrets and delete files unattended; nothing ties untrusted content to any restriction. C5 · Untrusted input blast radius
Importing swarms auto-loads a .env from the working directory or any parent, letting a workspace redirect model endpoints and keys. C6 · Memory, context & configuration integrity

Criteria

C1 Identity & least privilege

0.00 / 1.00

Swarms agents run with whatever authority the hosting Python process has. LLM provider keys come from environment variables (including any .env found above the working directory), and the autonomous mode's shell tool and every stdio MCP server inherit the full process environment. There is no per-tool identity, no scoped credential, and no authorization check anywhere on the tool path, so a hijacked agent acts with the operator's full local and cloud authority.

C2 Approval gates

0.00 / 1.00

There is no human approval step anywhere in the framework. The tool executor calls registered Python functions directly, the autonomous mode runs shell commands, writes and deletes files, and spawns sub-agents without asking anyone, and MCP tool calls go straight to the server. Interactive mode only asks the human for the next task, not for permission to act.

C3 Tool & action scoping

0.05 / 1.00

Built-in tools are general-purpose and unbounded. The autonomous mode's file tools accept absolute paths and simply use them, so create, update, read and delete reach anywhere the process can, and run_bash accepts an arbitrary shell string. The framework passes model arguments to user tools without validating them against the schema. Developers can narrow the autonomous tool set with selected_tools, but the default is every tool.

C4 Code-execution isolation

0.20 / 1.00

Model-written shell commands in autonomous mode run directly on the host with shell=True, in the process's working directory, with the full inherited environment. The only control is a substring denylist that is not a strict boundary. No container or OS sandbox exists anywhere in the framework, and stdio MCP servers also launch on the host.

C5 Untrusted input blast radius

0.00 / 1.00

Tool results, MCP results and other agents' messages are appended to the conversation and sent back to the model with no marking or restriction. Nothing in the framework distinguishes untrusted content or limits what the agent can do after reading it. In autonomous mode a single session combines reading files and tool output, holding the user's credentials, and running shell commands with network access, so an injected instruction can both exfiltrate secrets and take destructive action with no human involved.

C6 Memory, context & configuration integrity

0.05 / 1.00

Importing swarms searches upward from the current working directory for a .env file and loads it into the process environment, so a cloned or untrusted project directory can set provider API base URLs and keys (read by LiteLLM), turn telemetry on or off, or move the workspace. Optional persistent memory (off by default) appends every message, including tool output, to MEMORY.md and re-injects it as a System message in later sessions, keyed only by agent name with no validation or per-user namespace.

C7 Third-party extensions

0.23 / 1.00

Third-party code enters mainly through MCP servers the developer configures. Nothing is enabled by default, but there is no version pinning, integrity check or re-approval when a server's tools change, and stdio servers are launched as the same user with a full copy of the process environment, including every API key. Marketplace prompts can be pulled by ID at construction time without verification.

C8 Secrets & sensitive-data protection

0.07 / 1.00

Telemetry is on by default and ships each Agent's constructor configuration plus each run's task and output to a vendor endpoint on railway.app. Secret handling on the telemetry, error-logging and model-provider transport paths is not locked down either, and shell and MCP subprocesses inherit every key. Only the MCP manager's own summary and its OAuth token cache are protected.

C9 Audit & traceability

0.15 / 1.00

Tool outputs are appended to the in-memory conversation with timestamps, and loguru writes general logs to WORKSPACE_DIR/logs, but individual tool calls are only logged in verbose mode and the conversation is saved only if autosave is turned on. There is no actor attribution, no correlation across sub-agents, and records live in the workspace that the agent's own file tools can modify.

C10 Limits & kill switch

0.38 / 1.00

The default Agent runs a single loop. Autonomous mode is bounded by planning attempts (5), total iterations (100) and loops per subtask (20), and shell commands time out after 60 seconds. There is no wall-clock or token/cost budget, user tools have no timeout, and sub-agents created by the model get their own fresh loop budgets with no cap on how many are spawned. Stopping relies on KeyboardInterrupt; background sub-agent tasks are not guaranteed to stop.