AI Gadget Home Network Security: A Practical Guide

AI gadget home network security is mostly ordinary hygiene done on purpose. Pair the gadget on a network you trust, keep your router and firmware current, give the device only the access it needs, and know what it sends to the cloud. A DIY Muse gadget is a small computer with a microphone, sometimes a camera, and a link to your agent, so it deserves the same care as any other connected device in your home.

What data leaves an AI gadget

Start by knowing what actually crosses the network. This table comes from Meta's SDK docs. For anything beyond it, read Muse's privacy policy rather than guessing.

Part	What leaves the device	When
Connection	Pairing with your phone over Bluetooth LE, then an encrypted session to Muse over Wi-Fi	At setup, then while it is on
Microphone	Your voice note, which Muse transcribes	Only while you hold push-to-talk
Camera (Watcher)	A JPEG	When Muse requests a capture; off by default in the build
Air sensors (Indicator)	CO2, tVOC, temperature and humidity readings	When Muse reads them
Home-network tunnel	Traffic between Muse and your devices with a local HTTP API	When Muse uses those devices
Linux gadget	Command output and file contents	When Muse runs a command or reads a file

On the agent side, Muse's homepage says you approve actions such as sending emails and making purchases before they happen, and that your conversations "are not shared with Meta's ad systems".

AI gadget home network security starts at the router

The FTC's home Wi-Fi advice covers most of what you need:

Use WPA3 Personal or WPA2 Personal encryption.
Change the router's default admin username, password and network name.
Keep the router's software up to date.
Turn off remote management, WPS and UPnP.
Turn on the router's firewall.

Then pair the gadget at home, not on a coffee shop network. Meta's SDK says pairing "has no manufacturer verification and can't prevent an active man-in-the-middle attack. Set it up on a network you trust." Pairing does require a press of the button on the device, and every setup creates a fresh encrypted session.

Should it go on a guest or IoT network?

The FTC suggests setting up a guest network with its own name and password. A separate network is a good fit for gadgets that only talk to Muse, like a desk companion or an e-paper display. The tradeoff is reach: a gadget can only get to what its own network can. If you want the home-network tunnel to reach your smart plugs or a local HTTP service, those devices need to be reachable from the gadget's network. Also make sure that network offers 2.4 GHz, since ESP32-S3 boards use 2.4 GHz Wi-Fi.

Lock down the gadget itself

Treat the SDK token as an identifier, not a password. It ships inside the firmware. Still, never commit it to git or paste it in full anywhere. If it leaks, revoke it on gadgets.muse.ai, generate a new one and rebuild.
Turn on NVS encryption. The board stores Wi-Fi credentials and device tokens in flash, and without encryption anyone with physical access can read them. The README strongly recommends enabling CONFIG_HOMEHUB_NVS_ENCRYPTION if your board supports it.
Leave Secure Boot off. The SDK says never to enable Secure Boot, flash encryption or eFuse pairing auth on a board you want to keep reflashing.
Mind where the board sits. Anyone with physical access can read an unencrypted board, so keep it somewhere strangers can't quietly pick it up or plug into it.
On a Raspberry Pi, limit the account. Muse gets the same access as the account you install it for: "If it can use sudo, so can Muse." The README tells you to read install.sh before you run it, and --run-as lets you give Muse an account without sudo.

The guide to Muse on a Raspberry Pi covers the Linux setup step by step.

Updates without surprises

Boards with the full on-screen UI, such as the StickS3 and the Waveshare round AMOLED, have over-the-air updates turned on. Other boards, including the ESP32-C5 DevKitC-1, the reTerminals and the Voice PE, have them off by default, so you update them by pulling the latest code and reflashing. Reflashing keeps your pairing and Wi-Fi settings, while erase-flash wipes them.

Keep the router updated too. And remember that Meta's terms say the SDK "may change, stop working, or be withdrawn at any time", so check the repo now and then.

Microphone and camera habits

Push-to-talk by design. Voice boards record only while someone holds the button. The trade-offs are covered in push-to-talk vs always listening.
Use the hardware mute. Home Assistant says the Voice PE mute switch "physically cuts power to the microphones".
Place cameras with care. The SenseCAP Watcher camera is off by default. If you turn it on, aim it at a desk, shelf or doorway, not a bedroom or bathroom, and tell the people you live with. It is powered only while a capture or the live view runs.
Be upfront when you give one away. Meta's terms say you must tell the other person, before they pair it, what the device does with their information, and you may not keep or reuse their prompts or data.

Don't flash random firmware, and back up first

Only flash firmware you built from the official facebookincubator/muse-gadget-sdk repo, or code you have read. If a coding agent does the work, Muse Code still asks you to approve each command before it runs. Meta's own page is plain about the risk: "Side effects of tinkering may include bricked boards, voided warranties, brownouts, or bankruptcies."

Before the first Muse flash, save the board's original data:

SenseCAP Watcher: Muse overwrites its factory data, which is unique to each Watcher. Back up the nvsfactory partition with the SDK's paced tool: tools/muse/paced_esptool.py --chip esp32s3 -p PORT read-flash 0x9000 0x32000 nvsfactory.bin. Plain esptool fails on the Watcher's USB bridge.
M5Stack StickS3: back up the full 8 MB flash with read-flash 0 0x800000 sticks3.bin so you can return to UiFlow2.
M5Stack StickC Plus2: back up the flash at 230400 baud before the first flash.
Home Assistant Voice PE: Muse replaces the firmware on the ESP32-S3 only. Never reflash the XMOS audio chip.

Keep backups out of git and somewhere you will find them later.

Questions people ask

Should I put my AI gadget on a guest network?

It is a reasonable choice for gadgets that only need to reach Muse, like a desk companion or an e-paper display. If you want Muse to reach other devices through the gadget's home-network tunnel, those devices need to be reachable from the network the gadget is on.

Is the Muse SDK token a password?

No. Meta says to treat it as an identifier, because it ships inside the firmware. Keep it out of git anyway, and if it leaks, revoke it on gadgets.muse.ai, create a new one and rebuild.

Does a Muse gadget listen all the time?

The voice boards in the SDK use push-to-talk, so they record a voice note only while you hold the button. The SDK docs don't describe a wake word.

What should I do if I lose a gadget?

Revoke your SDK token on gadgets.muse.ai and rebuild your other gadgets with a new one. If NVS encryption was off, also change your Wi-Fi password, since the board stored it in flash.

Sources

Prices and details checked October 5, 2026.