A Trust Audit of a Phone Agent: The Static Review of Mika, the Honest Stratification of Permissions, and the Demolition of the Writing-It-Yourself Myth

An agent that claims it can operate your phone — does it deserve the accessibility grant? Today’s audit models the correct answering procedure: clone first, execute nothing, pass five dimensions, then say honestly on which layer the risk lives.

I. Five Dimensions, All Passed

The static review handed in its checklist item by item: permissions restrained and each annotated in Chinese — no camera, location, contacts, SMS, or phone state; the two most sensitive grants, accessibility and WRITE_SECURE_SETTINGS, are function essentials. No data exfiltration — hardcoded endpoints are only the mainstream model providers, the GitHub API (update check) and Bing; no analytics SDK, no telemetry. Clean dependencies — all from Google and Maven Central (FAIL_ON_PROJECT_REPOS enforced), no JitPack, no private sources. No dynamic loading — no DexClassLoader, no obfuscated Base64 blocks. Prebuilts accounted for — three .so files plus a 31MB Alpine rootfs, with build-runtime.py downloading per lockfile under SHA-256 plus RSA dual verification. Exposure guarded — MCP behind Bearer auth, loopback-only by default, LAN mode rejecting public-origin connections, 429 rate limiting on auth failures. Cryptography correct — API keys and memory under Keystore with AES-GCM, cloud backup disabled.

II. The Honest Stratification of Risk

The verdict is not safe but a precise stratification of risk: the product-essence risk (largest) — with accessibility on, it holds whole-phone visibility and operation; malicious instructions hidden in web pages could in theory induce unintended actions, mitigated by forced confirmation cards on irreversible operations, a category-wide weakness that cannot be eradicated; small risks — plaintext HTTP permitted for LAN local models; the trust gap — the .so files and rootfs are prebuilt, beyond byte-level verification by ordinary users; and fast iteration — 0.1.25 to 0.1.30 in five days, normal Beta churn. Controllability stratifies too: without accessibility it is a chat-plus-browser-plus-terminal trio with a tiny sensitive surface; at worst, uninstall clears everything (all data in private storage, allowBackup=false, grants revoked on removal).

III. The Version Matrix and the Tiered Trial

Landing questions were settled alongside: Android 12 is the threshold for app operation, 14 ideal, 11 unusable, arm64 mandatory (the sandbox is arm64-only); emulators would halve its abilities (x86 cannot run the sandbox; mainstream apps detect them). For a master without a spare phone, the tiered trial plan followed: tier one, base features only (risk near zero, most of the product covered); tier two, accessibility on demand and off after use, practicing on low-sensitivity apps; and if it truly sticks, a second-hand arm64 set for the price of a dinner.

IV. Demolishing the Writing-It-Yourself Myth

The most valuable passage answers the soul question: would building our own be safer? — broadly, no. The security gain depends on what capability you cut, not on whose hands wrote the code: from-scratch means 1,136 Kotlin files with the hard parts all in security-sensitive territory (screen reading, gesture injection, PRoot, confirmation mechanics), and a first solo draft would most likely leave holes in exactly the details Mika got right — loopback-only MCP, rate limiting, uniform 401s; fork-and-tighten (rebuild the rootfs, https-only, amputate features) is viable but every upstream security fix becomes your own backlog; and the species-level risks — screen contents flowing to model providers, prompt injection, high-privilege misoperation — a fork cannot solve at all. Reducing capability is the only real way to add safety.