Two layers, one automatic and always on, one optional and stronger.
Automatic baseline protection
Your saved API keys and WiFi passwords, your task list (including anything typed into an API Call step's auth field), and every Knowledge Base PIN are automatically scrambled using a key derived from your SD card's own unique hardware ID. This happens silently — no setup, no password, no prompt.
What this protects against: someone casually pulling the card and browsing its files on a computer. What it does not protect against: someone who deliberately wants in — the key comes from the card itself, so anyone who has the physical card can, in principle, derive it too.
Full password encryption
For real protection — the kind that holds up even against someone who has the card — activate full encryption from Credentials → Encryption in the web server:
- Open the Encryption page.
- Choose whether this is the first time encryption has been activated on this card.
- Set a password (at least 8 characters, with an uppercase letter, a lowercase letter, a number, and a special character).
- Confirm — this encrypts every existing file with a key derived from your password combined with the card's ID.
Once active, this covers the entire Knowledge Base, chat history, prompts, and credentials — not just the baseline items above.
The password can't be changed directly once set — removing encryption and reactivating it fresh is the only way to change it. There's no recovery if it's lost, so keep it somewhere safe.
Device Lock (child lock)
A separate thing from the two encryption layers above — this doesn't touch your data at all, it's a physical-access toggle on the device's own screen. Turn it on (Settings 1/6 → Device Lock) and swiping into AI Assistant, Translator, or Voice Notes is blocked; the clock face and Settings stay fully reachable either way. What exactly happens on that swipe depends on whether a PIN is set:
- No PIN set — a brief on-screen notice, shown for 5 seconds, then back to the clock.
- PIN set — the same numeric keypad used to turn the lock off (below) opens directly instead of the notice. Entering the correct PIN opens that one page for this visit only; the lock itself stays on, so the very next swipe asks for the PIN again the same way. This is a quick way in without leaving the lock off for anyone else who picks up the device afterward.
Shown for 5 seconds after a swipe into a locked page (no PIN set), then back to the clock.
Turning it back on is always a plain tap. Turning it back off depends on whether a PIN is set:
- No PIN set (the default) — tapping Device Lock again just turns it off, same as any other Settings toggle.
- PIN set — tapping it instead opens a numeric keypad on the device. Enter the correct PIN to turn it off; a wrong entry clears and lets you try again, up to 3 times. On the 3rd miss, the device is bounced all the way back to the clock (still locked) and starts a 30-second lockout. Swipes don't work on this keypad screen — PWR is the only way to back out without entering it.
Reopening Settings and tapping Device Lock again during that 30 seconds shows the same keypad, but grayed out and unresponsive, with a live countdown ("Try again in 12s"…) where the retry count normally shows — it isn't a fresh set of 3 tries, and there's no way to skip the wait. Once the countdown reaches zero the keypad wakes back up on its own, no need to close and reopen it.
Set or change the PIN from Credentials → Device Lock PIN in the web server — 4 to 6 digits, or leave it blank to go back to no-PIN behavior. Forgot the PIN? Just clear or change it there; the web Credentials page is never itself behind this lock.
This is a child-lock, not real access control. Settings is deliberately never blocked, and even with a PIN set, anyone with physical access can still reach every other web-based feature (API keys, files, chat log) — this only stops accidental or casual swipes into three specific pages.
Reprogramming the firmware
Minimal. This device ships fully open — the firmware can be reflashed over USB at any time, by anyone with physical access to it. A lost or stolen device reveals nothing on its own: the encryption key is never stored on it (see Full password encryption, above), so it can't be decrypted.
The attack requires physical access to the device, reprogramming it with lookalike firmware, then waiting for you to re-enter your password — and requires gaining access to the device again, physical or over WiFi, to retrieve any information. This is a general tradeoff of open, reprogrammable hardware, not something unique to this device; a hardware lock (secure boot) is the only way to close it off, and this device doesn't ship with one. Modifying, extending, or replacing the firmware yourself is entirely your own responsibility.
Custom or modified firmware isn't covered by support — if you flash something of your own, troubleshooting it is on you. A bad flash is always recoverable, though: hold BOOT while reconnecting USB and reflash a known-good build over it.