Prompt injection can enter through a camera or calendar

A parcel sits in the porch camera's frame with a sticker on the box, and buried in it is a line nobody asked the assistant to read. People have already lost control of a lock, a thermostat, or a notification feed this way, without anyone breaking in. The household agent trusted a sentence that walked through a camera, a calendar invite, or a QR code somebody printed, and did what it said.

That's the part local inference doesn't fix. Running the model on a board in a closet instead of a cloud API keeps video and transcripts on your own network. It says nothing about whether an email, webpage, or calendar entry deserves to be obeyed. A home agent allowed to propose automations folds a poisoned entry into its reasoning the same way it folds in a legitimate one.

Write the four-line spec before you trust it with anything

The board matters less than people think. Storage, power supply, cooling, the OS, radio or accelerator support, and the service downstream that consumes the output: that's the appliance. A model run once from a shell is still several decisions from a household feature. Start there, then write the job in four lines: event, input, output, deadline. "Add AI to the camera" is a wish. "When a parcel sits in the porch zone for twenty seconds, generate one local notification with a thumbnail" is testable, and it shows you which half of the pipeline never needed a model.

Testing it well means acting like an adversary, not a user. Label everything arriving from outside as data, never as instruction. Isolate the tools it can call, require authorization for anything physical, then feed it text built to look like a command, the way you'd red-team a coding agent's tool calls. Test against the actual room: real camera angle, microphone, evening light. Edge deployments amplify a warm cabinet, a marginal cable, a busy database far more than a model upgrade ever will.

Keep a short record while you're at it, because "it worked once" tells you almost nothing:

• board, power, and cooling as installed, not as advertised
• the exact model artifact and runtime version
• cold, warm, and sustained latency, memory, wall power
• whether it duplicated a notification, survived a reboot, and reconnected
• what a false action cost, a missed one cost, and how it recovered
• what it did when the inference service went down

That last one matters most. A feature other people in the house rely on needs visible state and a manual fallback. Nobody should have to know which container crashed just to turn on a light.

Give the model an opinion, not a key

Here's the boundary I don't compromise on: generative output can interpret a request, summarize a history, rank options. It cannot be the only thing between a stray sentence and a door lock, a heater, an alarm, a valve, a battery, or a person. Ranges, permissions, timeouts, confirmations, and device interlocks belong in deterministic code the model can't argue its way around, the same output-validation discipline you'd apply to any untrusted generator.

Camera text, calendar entries, webpages, MQTT payloads, voice transcripts: all of it is data the model reads, none of it is an instruction the house obeys. Every string arriving from outside the process stays untrusted, full stop.

Privacy needs the same whole-path treatment. Local inference stops one upload, but recordings, logs, thumbnails, backups, and a phone dashboard can still leave copies around the house. Decide what gets kept, for how long, and who can pull it during debugging. The most private frame is the one the camera never captures. The next best is the one thrown away right after the decision it fed.

None of this survives a device that falls over. Run it under a service manager or a small pinned container, keep configuration apart from the model files, and write a health check that proves the actual function, not just a port. Back up the controller state, export model hashes, and keep a known-good image for hard-to-reach nodes. Measure power and heat at the wall, peripherals included: a board that throttles, swaps, or corrupts storage under load isn't ready, no matter how good the model looked alone. When the model goes down, the house should get less clever, not stop working; edge AI is a narrow layer above reliable sensors, below a household policy someone wrote down.

I've made my peace with what this costs. Every camera frame, calendar entry, and scanned code gets treated as hostile until proven otherwise, so it sometimes refuses or asks twice for something a less careful setup would just handle. I take that trade on purpose. I'd rather eat that friction than have something unlock a door because a sticker told it to.