XAgent

XAgent's tools run as root inside a privileged Docker container that sits on the same Docker network as the MySQL and MongoDB databases and the unauthenticated ToolServerManager that can start new containers. Nothing narrows what the agent's shell can reach or checks per-request authority. The web server's default credentials and access checks are not locked down. A hijacked agent effectively holds host root.

There is no approval step before any tool runs. The default mode is fully automatic, and the optional 'manual' mode only lets the user edit the agent's previous thoughts or a subtask goal between steps; the next tool call is generated and executed without being shown for approval. The root shell, Python notebook, file writer and web fetch all execute directly.

The default tool set includes a raw root bash shell, a Python notebook and an arbitrary-URL web fetcher, all enabled by default. The file tools resolve paths and check containment, though the shell makes that moot anyway. The file containment check and the tool blacklist are not strict boundaries, and the web fetcher's request handling is not locked down.

All model-generated code and commands run inside a per-session ToolServerNode container rather than on the XAgent host, and there is no host fallback. But the container is started with privileged: true, runs as root, has Docker installed and started inside it, mounts the shared configuration directory read-write, and joins the network holding the databases and the container manager. A privileged container is not a meaningful boundary: an escape to the host is a documented, routine technique.

The agent browses arbitrary web pages and search results and feeds tool output back to the model as 'system' messages, giving them the same standing as its own instructions. Nothing detects, marks, or limits what a hijacked agent can do after reading that content. With a root shell, unrestricted egress and reach to the shared databases, an injected page can make the agent exfiltrate data and take irreversible actions with no human involved.

XAgent has no long-term memory store (the Pinecone vector DB is commented out). But the ToolServer configuration directory is bind-mounted read-write into every node container the agent controls as root. That directory holds node.yml, which is loaded by every future node and whose enabled_extensions list imports modules into the tool server, and manager.yml, which defines the docker run arguments for every new node. A single hijacked session can therefore persist changes that affect all later sessions and users, with no validation or review.

The shell tool's own description tells the model to install packages, and it does so as root with no consent or pinning, so third-party code is fetched and run at the model's choice. Tool-server extensions are imported in-process from a config list that the agent's container can write. The optional XAgentGen local-model server loads models with trust_remote_code='auto', but it is not part of the default compose stack.

Default deployment credentials are not locked down. Bing and RapidAPI keys live in node.yml, which is mounted into the container where the model's root shell can read it. The recorder masks api_key fields only in the console log; the full run config, including LLM API keys, is stored unmasked in the database, and the conversation-sharing path does not fully protect secrets either.

Every tool call that goes through the function handler is written as a structured record (tool name, input, output, status, the model's thoughts, timestamp) to MySQL, alongside LLM input/output pairs and plan changes. There is no human-versus-agent attribution or approval record because there are no approvals. The database is on the agent container's network, so the record is not protected from the agent.

Each subtask is capped at 15 tool steps, plan depth and width are bounded, and shell and notebook commands time out after 300 seconds. There is no token, cost or wall-clock cap for a run, and the client call that executes a tool has no timeout. Background shells started with run_async are not bounded and keep running until the container is stopped; idle nodes are stopped after 30 minutes. Stopping from the web UI sets a flag that the agent checks between steps, then exits.