AI-native risk intelligence: multi-agent SRE system (SRE/Code/Report/Data agents) for RCA
github.com/derisk-ai/OpenDerisk · 2026-10-03 · 5b0e729
Defense-in-depth score
1.1 / 10
As shipped, OpenDerisk's default agent runs model-written shell commands directly on the server host, with the server's full environment and API keys, and no tool call ever asks a human. The web server's default network exposure and authentication are not locked down, and anyone who controls a web page or file the agent reads can drive a host shell. Its 'local sandbox' is a working directory, not an isolation boundary, and the approval and authorization modules in the codebase are not wired into the execution path.
OpenDerisk records every agent message and tool call in its database and caps each run at 300 rounds. Beyond that the defaults are weak and there is little to turn on: the default agent runs model-written shell commands on the server host with the server's keys, and no tool call asks for approval. The safest setup builds the boundaries around the server yourself.
| Setup | How | What it gives you |
|---|---|---|
| Scoped, low-limit keys | Give the server a model key with a spending limit and a storage key limited to its own bucket | Anything that reads the server's environment reaches only that spend and that bucket C8 |
| Access for trusted users only | Run the web server on a private network or behind a proxy that signs users in | Only people you trust can start agent runs, which drive a host shell C5 |
| Its own container or VM | Run the server in a container or VM holding no files or credentials beyond this deployment's | Model-written commands and package installs reach only that box, not your other systems C4 |
| Limited outbound network | Allow outbound traffic only to the model provider, the storage endpoint and the hosts your tasks need | Data the agent reads has a narrow path to leave, and web fetches stay off internal addresses C5 |
| A read-only skill directory | Make the directory set in skill_dir read-only to the server's user, and update skills from outside the server | Every session loads only skills you wrote or reviewed C6 |
| Reviewed skill repositories | Keep only skill repositories you control in the skill directory, tracking a branch you review | Each sandbox start pulls only skill changes you approved C7 |
| A record off the host | Ship the SQLite database at path and the trace file under TRACE_FILE_DIR to storage the server's user can't modify | A record of every tool call that the agent's shell can't edit or delete C9 |
| Stop at the container | End runaway work by stopping or restarting the container, alongside stopping the chat | Subprocesses and background servers the agent started end with the run C10 |
SafetyCard
log_level = "INFO" every shell command and model output is logged unredacted; store the server logs like the keys the agent can read.0.00 / 1.00
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.
0.00 / 1.00
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.
0.07 / 1.00
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.
0.00 / 1.00
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.
0.00 / 1.00
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.
0.00 / 1.00
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.
0.00 / 1.00
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.
0.20 / 1.00
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.
0.45 / 1.00
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.
0.40 / 1.00
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.