nanoMuse proposes a personal agent that runs on devices its user owns, with an optional open relay connecting them. The report describes version 0.1.40, including Android, iOS TestFlight, desktop and web applications under GPL-3.0.
The project combines screen operation with readable memory and scoped approvals. Its authors position it as an open counterpart to hosted personal agents. Their report is an architecture account and roadmap, not an independent performance or security audit.
Run the agent on the device that performs the work
The Android application builds on OpenMinis, with a sandboxed Alpine Linux environment, shell, browser, MCP servers and scheduled tasks. The desktop uses an Electron shell around a Python runtime; that runtime also serves the web application from a user's computer.
A single device can use its owner's model-provider key without a relay. That arrangement still sends model calls to the chosen provider unless the user selects a local model server. Running agent software on a personal device does not make every part of inference local.
Cross-device work uses a relay and its presence hub. The report describes devices as peers: a requesting device can ask another to do a job, but the acting device applies its own approval controls. The requester cannot lend permissions it does not possess.
Put approvals between proposed actions and execution
Every tool call passes through a Sentinel policy gate. It checks denied tools and user rules, then applies allow/ask lists, data-taint handling and risk settings. Particular warnings, including destructive commands or committing interface labels, require approval.
Grants can apply once, to a conversation or to a named target. The permission list includes revocation controls. The authors distinguish this policy boundary from the stronger privilege boundary described in their account of Meta's hosted architecture.
Screen operation, called Hands, is off by default. The system prefers a skill, command-line tool or MCP interface before using the device's screen. Its screenshot loop proposes one action at a time, with a visible description and stop controls. On iOS, the report says the agent cannot operate other applications through their screens.
Inspect what memory and synchronization retain
The phone stores memory in Markdown files that a person can open. The computer's memory store includes change history and undo. Those readable representations support inspection, but the report lists richer memory provenance among the remaining open work.
The relay stores account and usage metadata, the agent profile and conversations selected for synchronization. The authors say it does not retain files, images or tool-return content. Conversation synchronization is therefore a separate data decision from choosing where an agent executes.
nanoMuse gives developers a concrete design to inspect for local personal-agent software. Its safety claims need to be read as descriptions of mechanisms, not proof that those mechanisms resist every attack. The useful next evaluation would test the actual screen and permission behavior in controlled conditions. The paper itself identifies an evaluation suite for the Hands component as roadmap work, rather than presenting one as completed.
Comments