AgentScope

AgentScope has no agent identity or credential scoping. In the default configuration the Bash tool runs as the operating-system user on the host and every command inherits the agent process's full environment, including the model API key the quickstart reads from an environment variable. Whatever the user can reach (cloud CLIs, SSH keys, git credentials) the agent can reach once a command is approved or slips through the read-only auto-allow. The agent service binds its own app tools (schedules, teams) to the authenticated user id, but that does not narrow what shell commands can do.

AgentScope ships a real, on-by-default approval system: every tool call goes through a permission engine that asks the human unless the call is classified read-only or matches an allow rule, the console shows the exact tool name and arguments, and the approved call is the one that runs. The gaps are in what gets auto-approved: the Read tool is treated as read-only for any path, MCP tools are auto-approved whenever the server itself declares them read-only, and neither the Bash read-only auto-allow nor approval in the bundled agent service is a strict boundary. Nothing provides undo or checkpoints for approved actions.

The default coding tools are general-purpose: Bash runs any shell string and Read accepts any path on the machine. Write, Edit and Bash carry denylist checks (sensitive dotfiles and directories, a short list of dangerous command patterns, `rm` of system directories), and Bash flags command substitution and control flow for review, but these are filters rather than allowlists. The Toolkit starts empty, which is a safe constructor default, but the README quickstart and examples register Bash, Write and Edit straight away.

By default the Bash tool runs commands directly on the host through a local subprocess with the agent's full environment; there is no isolation. AgentScope does ship workspace sandboxes (Docker, Bubblewrap, Apple Container, E2B, Daytona, Kubernetes, OpenSandbox) that rebind the built-in tools to the sandbox, and the E2B option is a remote sandbox service, but all of them are opt-in and the Agent constructor has no workspace by default. The Docker workspace is a stock container (root, default capabilities, default network) with an optional read-write host mount.

AgentScope does not track where content came from: tool results, MCP outputs and file contents enter the conversation with the same standing as anything else, and there is no taint-based restriction. What limits a hijacked agent is the general approval gate, which asks before most writes and shell commands in the default mode. But reads of any file are auto-approved, and MCP tools that their server labels read-only (fetch-style tools commonly are) run without a prompt, so an injected instruction can read secrets and send them out through such a tool without a human seeing it. Irreversible actions still need approval in the default mode.

The SDK itself keeps conversation state in memory and does not auto-load instruction files or .env files from the working directory. Its long-term memory middlewares are opt-in, but when enabled (Mem0 defaults to its 'both' mode) every exchange is written back automatically, the model's add_memory tool is always allowed, and retrieved memories are re-injected as an assistant message rather than marked data. Memories are namespaced by a required user id. In workspace mode, MCP server declarations persist in a `.mcp` file inside the agent-visible working directory and are read back in later sessions.

Third-party code enters through MCP servers and skills that the developer (or, in the agent service, a user browsing ClawHub or the GitHub MCP registry) chooses. Nothing is pinned or integrity-checked, and there is no re-approval when a server's tools change. Stdio MCP servers run as separate processes; the MCP library's default environment handling passes only a minimal set of variables unless an env is configured. A workspace's `.mcp` declarations live in the agent-writable working directory, so an approved file write can add a server. Separately, MCP servers can exempt their own tools from the approval gate by labelling them read-only (scored under approval gates).

Model-provider API keys are held as pydantic SecretStr, which keeps them out of reprs, and the framework ships no telemetry. Beyond that there is no secret handling: shell subprocesses inherit the full environment (including those keys), the Read tool and `cat` are auto-approved for any path such as `~/.aws/credentials` or `/proc/self/environ`, and nothing redacts secrets from tool output before it reaches the model or logs.

Out of the box the SDK keeps no durable record: tool calls, results and denials live in the agent's in-memory state and the event stream handed to the caller, and are lost when the process exits unless the developer persists them. An opt-in OpenTelemetry tracing middleware records reply, model-call and tool-execution spans, but it does not hook the permission check, so approvals and denials are not traced, and export is best-effort. The agent service stores session state in its database.

Each reply is capped at 50 reasoning-acting iterations and each Bash command at a 2-minute default timeout (the model may raise it to at most 10 minutes). There is no wall-clock or spend cap by default; a token-budget middleware exists but is opt-in, and MCP tool calls have no timeout unless one is configured. Interrupting the agent cancels the loop, but the Bash backend only kills the shell on timeout and never kills a process group, so background or child processes can keep running.