OpenDerisk

The web server's authentication in the shipped configuration is not locked down. The agent's shell runs as the server's operating-system user and inherits the server's whole environment, including model and storage keys. There is no scoped identity and no per-request authorization between the agent and its tools.

In the default agent (the v1 ReAct agent named BAIZE) no tool call ever waits for a human. The tool executor only asks for approval when a require_approval flag is passed, and nothing in the code passes it, so shell commands, file writes, web requests and MCP tools all run immediately. The bash tool is marked as needing permission and a separate authorization middleware exists, but neither is wired into the execution path. The inner sandbox shell tool is explicitly marked as not needing permission.

The default agent gets file, shell and web tools. The shell tool takes any command string: the sandbox shell tool contains an allowlist of read-only commands, but the call that enforces it is commented out, and the local bash path only blocks a handful of exact strings such as 'rm -rf /'. The web fetch tool only checks that the scheme is http or https, so it can reach internal addresses and cloud metadata endpoints. File paths are mapped into the sandbox directory without a containment check, and several host directories (/mnt, the skills directory, the configured work directory) are passed straight through.

The shipped configuration uses the 'local' sandbox, and its shell client simply starts a host shell process in a working directory, inheriting the server's whole environment. A macOS sandbox-exec profile and resource limits exist in the local runtime, but the shell client does not use them. Python code blocks from the code agent run natively unless the Python docker package is installed, which is not a dependency. Privilege handling during sandbox initialisation on the host is also not locked down.

The default agent reads untrusted content (web pages, search results, uploaded files, MCP results) into the same context that drives a host shell and an unrestricted web fetch tool, with no provenance marking and no approval step. A hijacked agent can read the server's keys and data and send them anywhere, and can also delete or change files on the host, with no human involved. The HTTP API's exposure in the default configuration is also not locked down.

Agent skills live in one shared skill directory that is listed into every agent's system prompt and that the agent's own file and shell tools can write to, because that directory is on the sandbox's pass-through whitelist. A single injection can therefore plant or edit a SKILL.md that every later session and every user of the server will load and follow. Skill repositories in that directory are also git-pulled from their remotes each time a sandbox starts. Vector-store preference memory is off by default because no vector store is configured.

The agent can install and run third-party packages on the host whenever the model decides to, because its shell is unrestricted and needs no approval. Skill repositories are git-pulled from whatever branch they track every time a sandbox starts, without pinning or re-approval, and skill scripts run through the same host shell. MCP servers configured by an operator are called through the same unapproved tool path. A startup routine that would auto-sync MCP configs from the vendor's GitHub repo exists but is never called.

Model and storage keys come from the TOML config or environment variables and sit in the server process environment, which every agent shell command inherits; the config file holding them is also readable by the shell. Secrets entered through the web UI are encrypted with Fernet, but the master key is stored in the user's home directory next to them. Masking exists only in one configuration API response. No third-party telemetry was found, but every shell command and model output is written to the info-level log unredacted.

Every agent message, including each tool call's action report, is stored in the application database with sender, receiver, conversation id and timestamps, and spans are written to a local JSONL trace file. There is no approval record because there are no approvals, and actor attribution is weak. Both stores sit on the host where the agent's unrestricted shell can edit or delete them, and trace spans are flushed in batches by a background thread.

The default agent has an iteration cap of 300 rounds and per-command timeouts, but no wall-clock or token/cost budget. The shell timeout is chosen by the model with no upper bound, and when a timeout fires only the top shell process is killed. Python code blocks that time out are abandoned while the process keeps running. Stopping a chat cancels the asyncio task, which does not kill subprocesses the agent started, and the shell tool's prompt tells the model to background long-running servers.