Atomic Agent

The agent runs as your OS user and uses whatever credentials it can find: provider keys and a GitHub personal token loaded into its own environment from ~/.atomic-agent/.env, plus your gh, git and SSH setup. Every shell command, skill script and MCP server it starts inherits that full environment; the code itself documents that there is no per-tool filtering. There is no scoped or short-lived identity; the only per-request check is the approval prompt, which is scored under approval gates.

Atomic Agent has a real approval system: a five-step ladder that starts at the strictest level, per-call prompts that show the exact command line or diff, session-only grants, and a trust-config category that can never be silenced. The gap is in what reaches it. The shell guard's auto-allow rules are not a strict boundary. HTTP POSTs (approval mode "never" by default), web fetches, browser typing and clicking, memory writes and scheduled tasks never ask, and MCP tools skip the prompt when the server itself claims to be read-only.

Many tools are narrow and validated: file tools resolve paths and classify them against the working directory, reads outside it require approval by default, and the HTTP and fetch tools block private and cloud-metadata addresses after DNS resolution. But the shell tool is a raw command line with only regex deny-lists, the HTTP tool accepts any public host and POST body (the host allowlist is empty by default), and every tool group, including shell, network and browser, is on by default.

There is no isolation boundary. Shell commands, skill scripts, verify runs and MCP stdio servers are spawned directly on the host as the current user, with the agent's full environment (including API keys from .env) and unrestricted network. The `src/sandbox` directory contains process runners, timeouts and process-group kill, not a sandbox. A command that escapes the approval prompt has the user's whole machine.

Web pages, search results, browser page text, MCP results and files are fed into the prompt with no marking or taint tracking, and nothing changes once untrusted content has been read. A hijacked agent can exfiltrate data unattended through os.http.request POST (ungated by default), os.web.fetch query strings or browser form filling, and gaps in the shell approval guard can let it run commands without a prompt. Writes, email and publishing still prompt, which limits the most visible damage.

Long-term memory is on by default: after each turn a reflection pass stores up to three profile facts and two notes, and the model can also write profile facts and notes directly without approval; these are re-injected into later prompts. Profile facts keep a history and can be listed, voted down and removed. Skills placed in a repository's `.atomic-agent/skills` folder are loaded silently into the skill catalog and override global skills of the same name, though running their scripts still asks for approval. Agent config and .env are read only from the user's state directory, not the working directory.

Third-party code arrives as MCP servers the user configures (or imports from Claude Code/Oh-My-Pi with a checkbox) and skills installed from GitHub or ClawHub. Hub installs are staged with a heuristic scanner that the code itself calls 'NOT a sandbox' and fetch the repository's default branch with no pin or hash. MCP stdio servers are launched as the same user with the agent's entire environment, including every API key, so a malicious server inherits everything.

Secrets live in plaintext files (~/.atomic-agent/.env and config.json) written with owner-only permissions, and GitHub tokens and provider errors are scrubbed in some messages. Error reports to Sentry use a strict field allowlist, and PostHog analytics (on by default) is designed to carry no content. However traces are written unredacted by design, and every subprocess and MCP server receives every key in its environment, where the model can read them with a shell command.

With the CLI or TUI, every tool call is written to a per-session NDJSON trace (tool name, full arguments, status, timestamps) under ~/.atomic-agent/traces, and the session database records each prompted approval or denial with its category and time. The record does not say which person approved, auto-approvals are not logged as approvals, and the files sit where the agent's own process can rewrite them. If a trace write fails, tracing silently switches off for the session and the agent keeps going.

A turn is capped at 25 steps per leg, 1,000 steps and two hours per task, with a 60-second default tool timeout and shell commands detached after ten minutes (hard-stopped after an hour). Stopping kills the whole process group of running commands. There is no token or cost ceiling, no rate limit on side-effecting tools, the model can ask for a shell call with no timeout, and scheduled and cron tasks it creates keep firing later.