C1 Identity & least privilege
0.00 / 1.00
The daemon launches each coding CLI with the operator's entire shell environment plus stored provider keys, so cloud, GitHub and other ambient credentials reach a model running with all permissions skipped. The workspace connection uses a single workspace token that the backend treats as owner-equivalent and that is shared by agents, daemons and share links. There is no per-tool or per-request authorization and no narrowing of the user's authority. A hijacked agent holds everything the user holds on that machine plus owner rights on the workspace.
C2 Approval gates
0.00 / 1.00
Every shipped CLI adapter disables its runtime's own approval prompts (Claude Code with --dangerously-skip-permissions, Codex with --dangerously-bypass-approvals-and-sandbox, others with --yolo or auto-approve), and comments state the daemon is meant to be the approval boundary. The daemon contains no approval step: workspace messages are dispatched straight to the CLI. Shell, file writes, public tunnels and scheduled routines all run without a human seeing the exact call. A plan mode exists but is a mode toggle, not a per-call gate.
C3 Tool & action scoping
0.07 / 1.00
The default tool set given to Claude Code is Read, Write, Edit, Bash, Glob and Grep plus workspace tools, with permissions skipped, so arbitrary shell and network access are part of designed use. The connector's own comment notes the allowlist is a suggestion, not a boundary, in execute mode. The workspace fetch and file-from-URL endpoints are well protected against SSRF on the server, but that does not constrain the local shell. The result is an agent whose tools reach the whole machine.
C4 Code-execution isolation
0.00 / 1.00
Model-chosen commands run as plain host subprocesses of the daemon, in the agent's working directory, with the full user environment. The connector adds no container or OS sandbox, and for Codex it explicitly passes the flag that removes Codex's own sandbox. One adapter (DeepSeek) deliberately keeps its runtime's workspace-write sandbox, but that is the exception. An injected command has the same reach as the user.
C5 Untrusted input blast radius
0.25 / 1.00
Agents act on any message delivered to them in the workspace, from any person holding the workspace link or token and from other agents, with no check that the sender is the agent's owner. Untrusted content arrives through the shared browser, web fetches, shared files and peer-agent messages, and the agent can then run shell commands, write files, open public tunnels and make outbound requests with no human step. The only structural defense found is a data fence around pinned knowledge-base entries, which is a prompt-level marker. A successful injection can leak local secrets and take irreversible actions unattended.
C6 Memory, context & configuration integrity
0.05 / 1.00
Several persistence paths can carry an injection forward. Any workspace token holder can send a skill.install control event, and the daemon then downloads a skill (including bundled scripts) from GitHub or from an uploaded workspace file into the agent's skills directory, where the CLI auto-loads it, with no local trust decision. Agents can write shared knowledge entries that are pinned into later prompts as 'settled decisions', and can create recurring routines that re-trigger themselves. Knowledge is scoped per workspace but shared by all of its agents and users.
C7 Third-party extensions
0.07 / 1.00
Skills are fetched from a GitHub repository's main or master branch (or from an uploaded workspace file) with no version pin, hash or signature. Installation is triggered remotely by a workspace control event, not by a local consent step. Installed skills run inside the coding CLI as the same user with the full environment and skipped permissions. Agent runtimes themselves come from the vendor's own registry endpoint.
C8 Secrets & sensitive-data protection
0.20 / 1.00
In the default skills mode the owner-equivalent workspace token is written in plain text into a SKILL.md file inside the agent's working directory and becomes part of what the model reads. Provider API keys are stored as plain text env files with no permission tightening, and the full environment is passed to the CLI. Error and stderr diagnostics are redacted, but tool-call previews (commands, paths, the first 100 characters of written content) are posted unredacted to the workspace. No telemetry SDK was found in the connector.
C9 Audit & traceability
0.20 / 1.00
For Claude, each tool call is posted to the workspace as a status line with a truncated input preview, and the daemon writes an unstructured log to ~/.openagents/daemon.log. There is no structured record of arguments and results, no attribution of which human or agent requested the action, and failures to post are silently swallowed. The local log is writable by the agent's own shell, and the log rotates at 10 MB keeping one backup.
C10 Limits & kill switch
0.25 / 1.00
The workspace Stop control kills the CLI's whole process group, which is a real halt. Beyond that there is no step, cost or wall-clock cap from OpenAgents: only a five-minute silence watchdog and a one-hour idle release. Agents can create recurring routines and timers that re-trigger themselves after a run ends, and those continue until cancelled.
SafetyCard