Meta's Muse Gadgets SDK: What an AI Agent Wired to an ESP32 Means for Device Security

Meta has put an open-source SDK on GitHub that connects ESP32 boards and Raspberry Pi-class Linux machines to Muse, its personal AI agent. The project is called Muse Gadgets. You flash firmware onto an off-the-shelf board, pair it with the Muse app, and the agent can then use the board's screen, buttons, sensors and relays, or reach devices on your home network. Source

This is a useful case for anyone building embedded products that talk to an AI agent. The agent is the new part, but the risks are old firmware risks: secrets in flash, unsigned updates, weak pairing, and a command list that grows without review. Meta's own documentation is frank about several of these, which makes it a good teaching document. This article walks through what the SDK does, what the docs say about its limits, and what a team shipping its own agent-connected device can take from it. It is based on Meta's repository, its Muse Gadgets site and its Home Link guide. We have not built or flashed a Muse gadget ourselves.

What Meta released

The repository has two device SDKs. The ESP32 SDK is firmware that connects a board to Muse over your home Wi-Fi, with options for a display, audio input and output, and other sensors. The Linux SDK turns a Raspberry Pi or other Linux box into a gadget, and Meta suggests using it to let Muse handle sysadmin chores or a Home Assistant setup. Source

The code is under the Apache 2.0 license, with a few third-party files that keep their own licenses. Meta describes the project as built by hackers, for hackers, just for fun, and warns that flashing custom firmware can brick boards and void warranties. Source

Every gadget needs an SDK token from Meta's gadgets site before it can pair, including gadgets you build for yourself. Pairing happens in the Muse app under Settings, Devices, with Developer mode turned on first. Source

Meta's token terms limit use to personal, non-commercial use with your own Muse account. They also say the SDK and tokens are not a supported product or a developer platform. The Apache license covers the code, but it does not grant any right to a token. Source

What runs on the board

The ESP32 README lists more than two dozen supported boards. The simplest, the ESP32-C5 DevKitC-1, gives you a status light and a button. Others add small screens, e-paper displays, push-to-talk audio and touch menus. Meta says the firmware is built with Espressif's ESP-IDF version 6.0.1 and that other versions are not supported. Source

Memory matters here. Boards without PSRAM, such as the classic ESP32 and the ESP32-C6, run without the home-network tunnel, because the tunnel needs more memory than they have. Muse can still reach and control those devices. Source

To give Muse a command of its own, such as reading a sensor or switching a relay, you advertise it in a function called link.register and handle it in the app code. Replies from Muse come back as text, so a spoken answer needs a text-to-speech service of your choice. Source

Meta also made its own gadget, Muse Home Link, a small USB-C device that keeps Muse connected to your home network so it can reach home services on your behalf. Meta's help page says it has no microphone or camera and stores no personal content, and that it is for use in the United States. It is free with an active Muse subscription in the United States, limited to one per subscriber, while stock lasts. Source

What the documentation admits

The ESP32 README has a short list of things "worth knowing." Read as a security review, it is more candid than most vendor docs. Source

Pairing has limits. Pairing needs a press of the physical button, and every setup creates a fresh encrypted session. But because these are community devices, Meta says pairing has no manufacturer verification and cannot prevent an active man-in-the-middle attack, so you should set up a device on a network you trust. Source

The token is in the firmware. Meta says the SDK token ships inside the firmware, so you should treat it as an identifier, not a password. If it leaks, you revoke it, generate a new one and rebuild. Source

Flash storage is readable by default. Wi-Fi credentials and device tokens sit in non-volatile storage. Without encryption, anyone with physical access to the board can read them. Meta strongly recommends turning on NVS encryption, which derives its key from an HMAC key in eFuse. Source

Builds are for tinkering. Builds are signed with a development key and never turn on Secure Boot, so you can reflash as often as you like. Over-the-air updates are off by default, except on boards that run the full on-screen UI, which turn them on. Source

None of this is a flaw in the project. It is a hobby SDK, labeled as one, with the trade-offs written down. The useful question for any team building its own agent-connected hardware is what would change between a workbench and a shipped device. Secure Boot off, a development signing key and a token in the image are all fine on your desk and all wrong in a product. Muse tokens themselves are for personal use, so this is a lesson in what to design for, not a route to a commercial Muse product.

How the docs treat coding agents

One more detail is worth a note. The repository includes an AGENTS.md file in each directory for coding agents, and the ESP32 README suggests letting Meta's Muse Code build and flash the firmware for you. It also says any agent that reads AGENTS.md can do the job. Source

The example command starts Muse Code with its sandbox disabled, because the agent needs access to the board's USB serial port and has to download the ESP-IDF toolchain. The README says you still approve each command before it runs. It also says that if your agent runs in a sandbox, you should let it run the flash and monitor commands outside the sandbox. Source

That is a reasonable trade for a hobby board on a desk. It is also a good reminder that hardware access and sandboxing pull in opposite directions, and that a human approval step is what is holding the line. If your team lets a coding agent flash devices, decide which commands it may run unattended and which need a person.

A checklist for agent-connected devices

Here is how we would turn the SDK's own notes into work for a team building a device that an AI agent can control. This is our reading, not Meta's advice.

1. Keep the command list short and reviewed. Every function you register for the agent is a remote control for your hardware. Write down each one, what it can switch or read, and who approved it.

2. Separate read from act. Reading a temperature sensor and opening a lock should not share a permission. Put anything that changes the physical world behind its own check, ideally a button press on the device.

3. Treat tokens in firmware as public. Meta says as much about its SDK token. If a value ships in the image, assume it can be extracted, and make sure revoking it is cheap.

4. Encrypt flash and turn on Secure Boot before production. Wi-Fi passwords and device tokens should not be readable by someone with a screwdriver. Replace the development signing key with a protected release key.

5. Sign and stage over-the-air updates. An update channel is the most powerful door into a device. Decide who can push a build, how it is verified, and how you roll back.

6. Plan for a hostile network. Meta says its pairing cannot stop an active man-in-the-middle attack. If your device will be set up in homes or offices you do not control, design pairing so it does not rely on the network being friendly.

7. Log what the agent asked the device to do. When something odd happens, you want a record of each command, when it arrived and what it did. Without that, every incident is a guess.

8. Budget memory for security. The README shows that boards without PSRAM drop the home-network tunnel. Encryption, logging and update checks cost memory too, so pick the chip with that in mind.

Where this fits in agent operations

An agent that controls a device is an agent with tools, and the same questions apply as for a software agent: what can it reach, who approved that, and who reads the logs? On a device you also have physical access, flash storage and update channels to think about.

Our AgentOps services page covers the operating side, including tool access, permissions, logging and review for agents in production. If you are building a product where an agent talks to firmware, a short review of the command list, the secrets in the image and the update path is a small piece of work with a clear result.