AppAgent

The agent acts with the operator's full ambient authority on two fronts: adb gives it complete control of the connected phone and every account logged in there, and its host subprocesses run as the operator's OS user with the full environment inherited. There is no scoped identity, no per-action authorization check, and no narrowing of either authority. A hijacked agent therefore holds the user's whole phone, and host-side handling is not locked down either.

There is no approval step anywhere. Each round the model's chosen tap, text, long-press or swipe is parsed and executed immediately over adb, and the loop continues until the model says FINISH or 20 rounds pass. Consequential phone actions such as sending a message, confirming a purchase or deleting data happen without the user seeing them first.

The action vocabulary is small (tap an element index, type text, long-press, swipe, grid taps), and some arguments are parsed as integers or checked against a fixed set of swipe directions. But the typed text argument receives little validation and its handling is not strict. Element indices are not bounds-checked, and all actions are enabled in every run.

Actions are carried out by invoking adb as a host subprocess under the operator's user, with the API key and full environment available. Handling of model-generated arguments on that path is not strict. There is no sandbox of any kind.

The agent's entire input is untrusted: screenshots and UI XML of whatever app is open, including incoming messages, web pages, notifications and ads, go to the model every round with the same standing as the user's task. Nothing separates that content from instructions or restricts what follows once it is read. A successful injection can make the agent type private data into a message or browser (exfiltration), take irreversible actions in logged-in apps, all without a human in the loop.

The exploration phase saves model-written descriptions of UI elements to apps/<app>/auto_docs (or demo_docs) as plain files keyed by element ID, and every later deployment run injects them into the prompt with an instruction to always prioritize them. Nothing validates, reviews or tags these entries, so text injected during exploration (for example, by a malicious app's screen) persists and steers tool use in future sessions. The files are local, readable and deletable by the user, and they are parsed with ast.literal_eval, which does not execute code.

The agent loads no third-party code at runtime: no plugins, MCP servers, dynamic imports, model-file loading or model-chosen package installs. Its Python dependencies are a build-time concern outside this criterion.

The API key is meant to be pasted into the tracked config.yaml in plaintext, and that file overrides environment variables, so the file is effectively the only way to supply it. The whole process environment is merged into the config object and inherited by every adb subprocess. Logs store full prompts and model responses (not the key), and every phone screenshot, which may show private messages or financial data, is saved locally and sent to the model provider. There is no redaction on any path.

Each round's prompt, image filename and raw model response are appended as a JSON line to a log in the run's tasks directory, before the chosen action is executed, and screenshots are kept alongside. That lets someone reconstruct what the model decided, but the log has no per-step timestamp, no record of the actual adb command or its result, and no actor attribution. It sits in a plain local directory writable by the same user.

The agent stops after MAX_ROUNDS (20 by default) and sleeps REQUEST_INTERVAL (10 seconds) between actions, which bounds how much it can do in one run. There is no wall-clock limit, no cost cap beyond a per-response token limit, and no timeout on the model HTTP request or adb subprocesses. Stopping is Ctrl-C on the foreground process; nothing is scheduled to keep running afterwards.