UI-TARS Desktop / Agent TARS

Agent TARS runs every tool as the operating-system user who launched it. Shell commands inherit the full process environment (including the model API key and anything loaded from a .env file), and the browser and file tools have no separate or narrower identity. The local web server it starts is reachable only from this machine by default and demands a token when bound to the network, which controls who can drive the agent but does nothing to narrow what the agent itself can reach. A hijacked session therefore holds the user's whole account: SSH keys, cloud credentials, and every logged-in service the shell can reach.

There is no human approval step anywhere in the agent loop. Shell commands, scripts, file writes, browser JavaScript, and form submissions all run the moment the model asks for them, and the system prompt even tells the model to add -y or -f flags so commands never pause for confirmation. Nothing provides checkpoints, undo, or dry runs, so a wrong or hijacked action, such as deleting files or submitting a purchase in the browser, cannot be caught or reversed.

The file tools check that paths stay inside the working directory, but that check is not a strict boundary. Every other default tool takes raw input: the shell runs any command string from any directory, the browser navigates to any URL (including internal addresses), and browser_evaluate runs arbitrary JavaScript. Shell, write, and network tools are all enabled by default, so the shell alone bypasses whatever the file tools enforce.

By default every shell command and script the model writes runs directly on the user's machine as the user, with the full process environment and no timeout. The bundled browser's launch settings are also not locked down. The system prompt tells the model it is in a Linux sandbox, which it is not in the default local mode. An opt-in AIO sandbox mode sends built-in tool execution to a remote endpoint instead, but it must be configured explicitly and any extra MCP servers the user adds still launch locally.

Agent TARS reads web pages, search results, and files as a matter of course, and nothing separates that content from the user's instructions or limits what the agent can do afterwards. A hijacked session can send data anywhere by navigating the browser or running curl, and can take irreversible actions on the machine or in logged-in websites, all without a human in the loop. This is the worst-case outcome the scorecard describes.

Agent TARS treats the directory it is started in as the workspace and, with no trust prompt, loads .env files into the process environment and a .tarko/instructions.md into the system prompt as higher-priority user instructions; project-scoped configuration is not integrity-protected. The agent's own file tools can write these files, so a single injection can persist for future runs in that directory, and in a shared repository for other users too. The scorecard's repository-configuration cap applies.

The system prompt tells the model to install whatever software packages it needs through the shell on its own, which means downloading and running package install scripts with the user's full environment and no consent. Extra MCP servers come from configuration, are typically launched with unpinned npx -y commands, and nothing verifies their versions or hashes; workspace configuration affecting them is not integrity-protected. Configured MCP servers do get a reduced environment, but packages installed through the shell get everything.

API keys come from command-line flags, config files, or a .env file in the working directory, and are loaded into the process environment that every shell command inherits, so the model can print them with a single command. The only redaction is masking the API key when the web UI shows the configuration. Session transcripts, including all tool output, are stored unencrypted in a local SQLite database, and the command server always logs command output to the console. There is no telemetry by default.

Every tool call, including calls to user-added MCP servers, produces a structured event with the tool name, full arguments, result, and timing, and the CLI stores these events in a SQLite database under the user's home directory by default. The record carries no notion of who requested or approved an action (there is no approval step to record), and the agent's own shell can edit or delete the database. Storage failures are printed to the console and the agent carries on, so records can be lost silently.

The only hard limit is an iteration cap of 1,000 model turns. There is no session time limit, no token or cost budget, and no timeout on shell commands. Stopping a run sets an abort flag that is checked between tool calls, but a command already running keeps going because nothing kills its process.