> For the complete documentation index, see [llms.txt](https://docs.miuro.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.miuro.ai/miuro-claw/miuro-claw-system-mechanisms-and-safeguards.md). # MIURO Claw System Mechanisms and Safeguards ### 1. Memory and Tool System #### 1.1 Memory Model MIURO Claw’s memory system is divided into two independent systems: cloud memory and device memory. * **Cloud Memory: Account Level** Cloud memory uses account-level persistent memory stored in `claw-account-memory`. It distills the user’s long-term creative preferences, music taste, and commonly used styles into long-term memory. It also keeps the most recent conversations as short-term context, creating a hybrid memory model. When the same account is used across multiple devices or endpoints, the system serializes memory processing by `account_id` to avoid memory conflicts. * **Device Memory: Local** The Device Claw running on the user’s MiuroBox has an independent local memory system. By default, it does not interoperate with cloud account memory in the v1 phase. This design protects user privacy. Even when offline, the device can continue providing personalized services based on local memory. #### 1.2 Tool and Skill System * **Cloud Claw:** Cloud Claw only exposes a safe subset of tools, mainly including songwriting generation, points checking, and music library queries. These are primarily read-only or low-risk operations. * **Device Claw:** Device Claw provides access to the complete OpenClaw skill ecosystem, allowing users to install and use different Skills. It also supports 24/7 automated tasks triggered by schedules or events, enabling Claw to continuously perform creative assistance in the background. On the device side, Claw focuses more on orchestration. Specific tool execution can be handled through the MCP protocol by calling cloud or local resources, keeping runtime operations lightweight. *** ### 2. Device Communication and Runtime Mechanism Communication between the device and the cloud is the key to enabling remote wake-up and coordinated operation in MIURO Claw. #### 2.1 Communication Architecture Since most home networks are behind NAT, the device maintains online status through outbound persistent connections. * **Network Layer:** MIURO Claw uses the lightweight MQTT protocol, either TLS 8883 or WebSocket 443, to establish a persistent signaling channel. This channel handles device presence and wake-up signal delivery. The cost is extremely low, with an estimated annual cost of approximately $0.042 per device. * **Compute Layer:** The openclaw warm-up gateway on the device remains cold by default. It only warms up after receiving a wake-up signal, reusing the try-now warm-up mechanism. This avoids unnecessary 24/7 resource consumption. #### 2.2 Offline Detection and Message Routing * MIURO Claw uses MQTT LWT, or Last Will and Testament, to detect offline status within seconds. * When a user sends a request through the web, app, or IM, the system routes the message to the corresponding device for processing. * After processing is completed, the result is returned to the user through a persistent message queue called River. * If the device is offline, the user interface will immediately display: “Your Claw is offline.” The system will not fall back to cloud processing. This design ensures fast response while maximizing user privacy. *** ### 3. Data, Encryption, and Backup MIURO Claw uses a layered data management strategy to balance convenience and privacy. * **Cloud Data:** Account-level data is stored in the cloud using standard AWS storage. * **Device Data:** Device data is stored locally on the MiuroBox with encryption at rest. Core data is not uploaded by default. * **Backup Strategy** * Songs support cloud backup by default, which users can disable. * Sensitive data such as personality, memory, and creative preferences supports optional encrypted backup, which is disabled by default. * **Factory Reset:** A factory reset destroys the device key, enabling cryptographic erasure. This permanently clears local data, protects the privacy of previous users, and solves data security issues in second-hand device and RMA scenarios. This design allows users to flexibly choose where their data is stored based on their privacy needs. *** ### 4. Business Model and Device Benefits MIURO uses a hybrid business model combining hardware ownership with subscription-based metering. It clearly separates the two types of benefits. #### 4.1 Two Benefit Axes | Benefit Type | Corresponding Content | Payment Model | Key Feature | | ----------------------- | -------------------------------------------------------------------------- | ------------------------------------------------- | ---------------------- | | Device Key Axis | Local studio, offline music library, 24/7 automation and full skill access | One-time hardware purchase, permanently available | Buy the box and own it | | Account Membership Axis | Cloud songwriting models and LLM usage | Membership or token-based metering | Use on demand | #### 4.2 Core Business Principles * **Local Core Capabilities Are Permanently Owned** After purchasing MiuroBox, users permanently retain access to local recording, noise reduction, transcription, offline music library, and automation functions. Even without renewing membership, local capabilities will not expire. * **Only Cloud Capabilities Are Metered** Cloud-based songwriting models are high-value proprietary resources. They are billed based on membership duration or token usage. * **Hardware Purchases Include Membership** Users who purchase different MiuroBox models receive corresponding membership periods. For example, ORIGIN includes 12 months of Studio membership. This lowers the entry barrier for users. This model protects the user’s hardware investment while enabling MIURO to generate sustainable revenue through cloud capabilities. *** ### 5. Security and Privacy Safeguards MIURO Claw considers multiple security threats from the design stage and introduces corresponding mitigation measures. | Threat | Mitigation | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Device theft | Local encryption at rest. In the P2 phase, secure element support will ensure private keys are never exported. | | Key copying and multi-device reuse | Single key, single active session, anomaly detection and automatic revocation. In the P2 phase, hardware binding and per-request signatures will be supported. | | Cross-tenant message routing errors | Strict device-to-account authorization chain verification with tenant-level partitioning. | | Supply chain attacks during factory key injection | Unique keys, backend registration, revocability and one certificate per device. | | OTA poisoning | A/B partitions, binary signatures, mTLS and automatic rollback. | | Device identity bypassing account quota | Sensitive operations such as songwriting must still be charged against the account quota. | Through these mechanisms, MIURO Claw protects user privacy and data security while reducing the risk of system abuse. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.miuro.ai/miuro-claw/miuro-claw-system-mechanisms-and-safeguards.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.