Python framework for building autonomous and traditional AI agents, with filesystem/shell toolkits, MCP, skills, memory, and multi-agent teams.
github.com/upsonic/upsonic · 2026-10-04 · 101f031
Defense-in-depth score
2.1 / 10
Upsonic's headline AutonomousAgent runs whatever shell commands the model writes directly on your machine, with your full environment (API keys, cloud credentials) and no approval step; the 'dangerous commands are blocked' claim is a five-entry substring denylist. The framework has a real per-call approval primitive and an E2B remote sandbox, but both are opt-in. It also auto-loads a .env and AGENTS.md from the working directory, so a cloned repo can steer endpoints and instructions. Treat the default as unsandboxed host execution and add confirmation flags, E2B, and a scrubbed environment before pointing it at anything untrusted.
Upsonic ships a tool-call cap and an in-memory record of each run, and its file tools stay inside the workspace. As shipped, the AutonomousAgent runs model-written shell commands on your machine with your full environment and no approval step, so the safest setup turns off the host tools, moves code into the E2B sandbox, turns on per-call approval and builds containment around the process.
| Setup | How | What it gives you |
|---|---|---|
| A dedicated, low-limit environment | Run the agent in an environment that holds only the model key and tool credentials this agent needs, each scoped with a spending limit at the provider | Whatever the agent runs, it reaches only the systems and spend you gave it, not every key in your shell C1 |
| Host tools off | enable_shell=False on AutonomousAgent, and enable_filesystem=False unless the task edits workspace files | The model has no general command line on your machine, only the tools you chose C3 |
| A remote code sandbox | Add E2BTools to tools for any code the task needs to run | Model-written code and commands run in a remote E2B sandbox, away from your keys and files C4 |
| Per-call approval | Pass requires_confirmation=True to each toolkit you add, such as E2BTools, and mark your own consequential tools with @tool(requires_confirmation=True) | The run pauses before each call and hands your code the exact tool and arguments to approve C2 |
| A clean workspace | Launch from, and set workspace=<dir> to, a directory holding only the task's files, with no .env or AGENTS.md you didn't write | Instructions, endpoints and keys come only from you, not from a repository you happen to run in C6 |
| Reviewed, pinned extensions | Add only MCP servers and skills you have read, pinned to a fixed version or commit | Only code you have checked runs alongside the agent, and it can't change after you checked it C7 |
| A tool-call budget | Keep the default tool_call_limit=100, or lower it for short tasks | Every run stops calling tools after a fixed number of calls C10 |
| Its own container or VM | Run the agent in a container or VM whose network reaches only the hosts the task needs, with instrument=True sending traces to a collector outside it | An outer boundary around everything the agent runs, a narrow path for data to leave, and a record that outlives the process C5 |
0.00 / 1.00
Upsonic agents run with whatever authority the Python process has. The built-in shell tool and every MCP stdio server receive a full copy of the process environment, so model provider keys, cloud credentials, and anything else exported are available to model-chosen commands. There is no per-tool identity, no scoped credential, and no authorization check between a tool call and its execution.
0.23 / 1.00
The framework has a real human-in-the-loop primitive: a tool marked requires_confirmation pauses the run and hands the exact tool name and arguments to the calling code for approval. It is off for every tool by default, and none of AutonomousAgent's built-in shell, file-write, or delete tools set it, so the default agent runs shell commands and deletes files with no human involved. Optional safety policies are LLM or keyword classifiers, not approval gates.
0.28 / 1.00
The filesystem tools resolve each path and refuse anything outside the workspace, which is a sound check. That check is moot because the shell tool, on by default, accepts any shell string with only a five-entry substring denylist (for example 'rm -rf /'), and runs it with shell=True. The model can also choose the command timeout and extra environment variables. Registered user tools get schema typing but no shared argument policy.
0.50 / 1.00
By default, model-written shell commands and Python run directly on the host as the user, via subprocess with shell=True and the full environment, in a working directory that defaults to wherever the script was launched. Skill scripts also run on the host. Upsonic offers an opt-in E2B tool kit that runs code in a remote sandbox, but its upload and download tools read and write arbitrary host paths chosen by the model, and using it does not remove the host shell tool unless the developer disables it.
0.00 / 1.00
Tool results, file contents, command output, and MCP tool descriptions enter the model context with no provenance or untrusted marker, and nothing in the agent loop changes what the model may do after reading them. In the default AutonomousAgent, a hijacked model can read secrets from the environment through the shell, send them anywhere over the network, and delete files, all without a human. The safety engine's injection and content policies are optional classifiers.
0.10 / 1.00
Importing Upsonic loads a .env file from the current working directory, and the AutonomousAgent workspace defaults to that same directory; that file can set provider base URLs, keys, or the telemetry DSN for any variable not already set. An AGENTS.md in the workspace is read silently into the system prompt, and the agent's own write_file tool can create or edit that file, so an injection can persist into every later session. Session memory itself defaults to an in-memory store keyed by a random session id.
0.00 / 1.00
The default AutonomousAgent loads no plugins, but its shell tool's own documentation suggests 'pip install -r requirements.txt', and nothing stops the model installing and running any package. When developers add extensions, MCP stdio servers launch through npx/uvx (and docker) with the full environment, GitHub skills are pulled from the tip of a branch with no hash, and prebuilt agents clone the latest Upsonic master at runtime; skill scripts run on the host.
0.25 / 1.00
API keys come from environment variables (often from an auto-loaded .env), and the shell tool and MCP servers get the whole environment, so a single 'env' command puts every key into the model's context and the provider's logs. Only some vector-database configs use masked secret types; there is no redaction of logs, console tool-call printing, or model-bound messages. Error telemetry to Sentry is opt-in.
0.35 / 1.00
Each run keeps a structured list of tool calls (name, arguments, result) on the task object and emits tool-call events, and calls are printed to the console by default. By default this lives only in process memory (InMemoryStorage), so it disappears when the process exits or crashes, and there is no actor attribution or tamper-evident storage. OpenTelemetry instrumentation exists but is opt-in.
0.40 / 1.00
Agents stop executing tools after 100 tool calls by default, and shell commands get a 120-second timeout. There is no token or cost cap: a UsageLimits class is defined but never used, and the model can pass its own, longer timeout to each shell command. Cancellation is checked between steps, and the shell timeout kills only the direct child process.
SafetyCard