QwenPaw

QwenPaw runs as the operating-system user who starts it and does nothing to narrow that authority: shell commands inherit the full process environment, including any keys you add through its environment manager, and there is no per-tool or per-request credential. The governance layer decides which actions run, but it does not scope identities. Its own security policy tells operators to give it a dedicated OS user or host; nothing in the default install does that for you. If the agent is steered, it acts with everything your account can reach.

QwenPaw has a real approval system: a policy engine asks a human before risky calls, the approval card shows the exact tool input, unknown tools are denied and a governance start-up failure denies everything. But at the default approval level, shell commands run immediately unless one of the built-in dangerous-command patterns or sensitive-path checks fires, so the most powerful tool is effectively ungated. The approval level can also be changed at runtime without an operator-level step. There are no default checkpoints, so most actions can't be undone.

The tools are general purpose: a raw shell, file tools that deliberately don't confine paths, and a web fetcher that takes any http(s) URL and follows redirects without blocking internal addresses. What validation exists is a denylist of dangerous shell patterns and glob rules on the target path, which mostly allow. Shell, file write, browser and web tools are all on by default, though each can be switched off in the console. A misused tool can reach anything the user can.

By default shell commands run as ordinary host subprocesses with the full environment, because the global sandbox switch ships off and the governance layer then runs them unsandboxed without asking. An OS sandbox exists (Bubblewrap or Landlock on Linux, Seatbelt on macOS, AppContainer on Windows) that limits writes to the workspace, but it leaves the network open, passes most of the environment through, covers only the shell and the recall REPL, and is skipped silently when the platform can't provide it. Turning it on is worthwhile but does not make the shell a contained environment.

The agent reads web pages, search results, files, browser content and MCP results, and none of it is marked or handled differently from the user's own instructions; the only defence is a system-prompt line telling the model to treat such content as data. In the default configuration a hijacked agent can read the user's files, run shell commands and send data out through the web fetcher or the shell, all without a human. The project's own security policy says the model is not a trusted principal and treats prompt injection as out of scope unless it crosses a boundary, but the default boundaries are wide.

Each agent's workspace holds instruction files (AGENTS.md, SOUL.md, PROFILE.md) that are loaded into the system prompt on every turn, plus MEMORY.md and the ReMe knowledge base. The agent's file tools may write anything inside its workspace without asking, so content it reads in one session can rewrite the instructions every later session follows. QwenPaw does not load instruction or config files from the projects you point it at, and memory lives per agent, but there is no validation, provenance or review step for memory writes and automatic checkpoints are off.

QwenPaw loads three kinds of third-party code: plugins from its marketplace, which are imported into the main process; skills, which run with the process's privileges and are only scanned in warn mode; and MCP servers, which the user adds and whose calls ask for approval by default. Nothing third-party is verified: plugin archives are installed without checking the catalog's listed hash, and the shipped external-agent entries launch npm packages at whatever version is latest, though the tool that uses them is off by default. A malicious plugin gets everything the agent has.

Stored secrets are encrypted with a master key kept in the OS keychain or a 0600 file, and the secret directory is on the file guard's protected list. But environment variables configured through QwenPaw are injected into the process environment and reach every shell subprocess, there is no general redaction before content goes to logs or the model, and a daily content-free usage ping is on unless you opt out. Anything a key can do, a hijacked shell can do with it.

Every governed tool decision, including user approvals and denials, is written immediately to a SQLite audit log under the QwenPaw home directory with time, agent, session, tool, target and decision. It is on by default and sits outside the agent's workspace, but the unsandboxed shell can still edit it and the policy file can turn it off. Calls to MCP servers go through a separate driver path that doesn't write to this log, and the record keeps the target rather than full arguments or results.

Runs stop after 100 reasoning steps by default, a repetition detector is on, shell commands default to 60-second timeouts, and cancelling a command kills its whole process group. There is no default token or cost cap (a token-budget gate exists only in custom loop modes), the model can ask for longer shell timeouts up to a 24-hour ceiling, sub-agents start their own step budgets, and scheduled jobs keep running after a chat is stopped.