Are AI agents a real smart home security risk?

Start with reach, not intelligence

The useful first question in any discussion of AI agents as a smart home security risk is not whether the model sounds clever enough to be dangerous. It is what the agent is allowed to reach. A chatbot that can explain why an automation failed is one thing. A conversational agent holding a persistent credential that can call Home Assistant services against every exposed lock, garage door, alarm, light, and camera is a different system.

As of 2026-08-25, I would not cite a confirmed public home-hub incident where an AI agent was exploited into unlocking a door or opening a garage. That matters. It keeps the discussion out of folklore. The risk is still real, but the evidence is mostly mechanism-level: lab demonstrations, adjacent agentic-AI failures, and smart-home configurations that create an obvious path from text input to physical action.

Home Assistant’s own AI direction is more constrained than the loudest panic implies. The 2025 local-AI work described by Home Assistant focused on suggestion-oriented help such as naming and describing automations, not a default premise that an AI should execute arbitrary home commands unattended [1]. The OpenAI Conversation integration is an opt-in integration, and Home Assistant’s Assist control path depends on which entities are exposed to assistants through the exposed-entities interface [2][3].

That is the right place to begin because it is verifiable. Before worrying about whether a model is local, cloud-hosted, frontier, small, “agentic,” or merely chatty, check what the Home Assistant side has made available to it.

The three access-plumbing risks

Those three rows are more useful than a generic “AI is risky” label. They tell you where to look: the credential store, the exposed-entity list, and the service-call path. If those are tight, the agent has less room to cause damage even when it misunderstands an instruction. If those are sloppy, a modest model can still become a capable actuator.

A long-lived token is not “just setup glue”

Many DIY AI-control recipes start with an innocent step: create a Home Assistant long-lived access token, paste it into an app, script, proxy, or environment variable, and let the model-driven layer call back into the hub. Evan King’s HomeGPT write-up is a useful public example of this pattern: an LLM-side application uses Home Assistant’s API and a long-lived access token to operate the home [4]. Similar patterns show up in hobby projects because they are easy to explain and quick to test.

The problem is not that a token exists. Home automation needs credentials somewhere. The problem is a token that is persistent, broad, forgotten, and stored outside the place where the household admin normally reviews access. Six months after setup, nobody remembers whether the token was copied into a Docker compose file, a cloud function, a laptop script, a GitHub secret, or a test container that never got cleaned up.

Treat the agent credential as a device with privileges, not as a password-shaped footnote. If the model host, agent framework, or proxy is compromised, the attacker does not need to “hack the AI.” They can use the same access path the AI uses. If the token belongs to your everyday Home Assistant admin account, the blast radius is whatever that account can do through the API.

What to change

• Create a dedicated Home Assistant identity for the AI integration where your Home Assistant version and integration path allow it. Do not reuse your primary admin account simply because a recipe says “paste your token here.”
• Name the token after the thing that uses it, for example “ollama-agent-proxy” or “openai-conversation-test,” so future-you can tell what to revoke.
• Rotate or revoke old tokens after experiments. A weekend test that still has a live credential is not a test anymore; it is standing access.
• Keep the token out of prompts, chat logs, screenshots, and YAML snippets you paste into issue trackers.
• If you followed a long-lived-token recipe, revisit it after the system works. The quickest path to a demo is rarely the access model you want for the household.

This is also where internal documentation helps. If you have used a recipe such as Kimi AI control for smart-home devices, write down which token or account was created for it and what system stores it. The dangerous part is often not the recipe itself; it is the undocumented leftover credential.

Entity exposure is the home-specific permission boundary

In Home Assistant, the exposed-entities page is one of the most important AI safety screens because it decides what Assist and connected assistants can work with. Home Assistant documents this as the place to expose or unexpose devices and entities to voice assistants [3]. That makes it a practical boundary: the model cannot responsibly control a device it should never have been shown.

A broad exposed-entities list is especially easy to create in a mature Home Assistant install. Years of helper entities, old test switches, camera streams, door sensors, locks, scripts, groups, and automations can accumulate. Some are safe conveniences. Some are physical controls. Some look harmless until you remember that a script named “night mode” also arms an alarm or changes a door lock state.

The review should not start with device count. It should start with consequence. A living-room lamp and a front-door lock do not belong in the same mental bucket just because both appear as entities. A temperature sensor, a camera stream, a garage door cover, and an alarm control panel produce different failure modes, so they deserve different exposure decisions.

The trap is exposing a friendly abstraction without checking what it triggers. A script called “open up” might only open blinds. It might also disarm an alarm and unlock a side door. An agent does not need malicious intent to choose the wrong callable thing if the home presents too many vaguely named tools.

A better exposed-entities pass

1. Open the exposed-entities page for the assistant or AI path you actually use.
2. Remove locks, garage doors, gates, alarm panels, cameras, and sirens unless you have a specific confirmation design for them.
3. Audit scripts and scenes by downstream effect, not by name.
4. Prefer small, explicit helper entities for AI use instead of exposing a large room, area, or integration wholesale.
5. Re-check after adding devices, renaming areas, installing a new voice assistant, or changing an AI integration.

The service-call path is where text becomes motion

The last boundary is execution. A model can misunderstand a household request, hallucinate a state, invent a parameter, or choose a similarly named entity. That is irritating when the result is a bad answer. It is different when the output is immediately converted into a Home Assistant service call.

Physical systems need a boring layer between probabilistic text and irreversible-enough actions. One Home Assistant-oriented generative-agent project implements that idea with “Sentinel” rules that check device state and a “Critical Action PIN” pattern for sensitive actions such as locks and garage doors [5]. That project is not proof of a universal best practice, and it is not a Home Assistant core feature claim. It is useful because it shows the right shape of the control: deterministic checks and human confirmation before a risky action fires.

Suggestion-only mode is the cleanest version of this for many homes. Let the model draft an automation, explain why a condition failed, propose an entity name, or say “I can unlock the door, please confirm in Home Assistant.” Do not let it perform the action unless the path includes a deterministic rule or a person deliberately approving it.

The household admin should be able to answer one plain question at 11:40 p.m.: “Could the agent have done this by itself?” If the answer requires reading three repositories and guessing which token a container used, the configuration is not auditable enough.

What the evidence actually proves

The strongest evidence does not say “Home Assistant AI agents are being exploited in the wild.” It says that agents become dangerous when broad tool access, persistent credentials, and unattended execution are combined. That is enough to justify containment without pretending a home-specific incident has already happened.

Unit 42’s agentic-AI threat work lays out nine framework-agnostic attack scenarios against AI agents, including patterns where the agent’s tools and permissions become the useful target [6]. These are not Home Assistant break-ins. They are threat models for agent systems, and they matter because a smart-home agent is also an agent with tools.

The BashAgent study is sharper because it measured agent behavior under malicious-intent tasks. In the UC Davis paper, the unconstrained BashAgent executed 76 of 95 malicious intents, while the sandboxed variant blocked all of them [7]. A shell agent is not a smart-home hub, but the lesson maps cleanly: the same model becomes far less dangerous when the execution environment restricts what it can do.

MCP and server-side tool plumbing deserve attention for the same reason. Check Point reported that 40% of analyzed MCP servers were vulnerable, which is relevant because MCP-style connectivity expands what agents can call beyond the chat window [8]. That finding should not be inflated into “your home is compromised.” It is a warning about the layer that brokers tool access.

Government guidance is moving in the same direction. The May 2026 Five Eyes guidance on careful adoption of agentic AI services calls out risks such as over-privileged agents and confused-deputy patterns [9]. Again, that is not a smart-home incident report. It is confirmation that the permission model is not a theoretical concern invented for consumer devices.

Industrial IoT safety discussions reach a similar practical conclusion: read-only or approval-based agent use is much easier to defend when AI is connected to physical systems [10]. A home is not a factory, but a front door is still a physical actuator. The scale changes; the need for a control boundary does not.

Prompt injection matters, but it is not magic

Prompt injection is often described as if hostile text alone opens a door. In a home hub, hostile text needs a path: the agent must ingest it, treat it as an instruction, have a credential, see the relevant entity, and be allowed to execute the service call. Remove any one of those pieces and the scenario changes.

That is why a smart-home risk review should not stop at “do not trust web pages” or “sanitize prompts.” Those are useful ideas, but the household-level control is more concrete: do not give the agent a broad, unattended route from untrusted text to sensitive devices.

Hallucination belongs in the same practical bucket. A model may claim a door is already locked, choose the wrong entity name, or invent a service parameter. The fix is not to demand a model that never makes mistakes. The fix is to make the service-call layer check state, restrict entities, and require confirmation for actions where a mistake has a real-world consequence.

Local versus cloud is a decision factor, not the verdict

Running the model locally can reduce cloud exposure and keep more household context inside your network. That is a valid privacy and resilience reason to prefer local inference. It does not, by itself, fix an overpowered Home Assistant token, an exposed lock entity, or a direct service-call path.

A cloud model with narrow, suggestion-only access may be safer for physical control than a local model with full Home Assistant API authority and no confirmation gate. A local model with scoped entities and deterministic checks may be safer still. The model location changes who sees the conversation and where processing happens; it does not automatically define what the agent can do.

For the privacy side of that decision, compare your setup against a local-versus-cloud AI smart-home security review or a Gemini smart-home privacy check. For physical-action safety, come back to the same three questions: credential, exposure, execution.

What a safe-enough Home Assistant AI setup looks like on 2026-08-25

A safe-enough configuration is not a promise that the model is harmless. It is an auditable state of the hub. On the publication date, the setup I would trust is narrow, named, and easy to revoke.

• The AI integration is intentionally enabled, your Home Assistant version is noted, and you know which conversation agent, add-on, proxy, or external service is connected.
• The agent uses a dedicated credential or identity where possible, not a forgotten admin token copied during a test.
• Tokens are named, reviewed, and rotated or revoked when the agent changes.
• The exposed-entities list is small and consequence-based. Locks, garage doors, gates, alarms, sirens, and cameras are not exposed by habit.
• Scripts and scenes exposed to the agent have been checked for downstream actions.
• Critical actions require human confirmation, a PIN, or an equivalent approval path.
• Read-only or suggestion-only behavior is used where the agent’s job is explanation, drafting, naming, or troubleshooting.
• After Home Assistant updates, AI integration updates, MCP/server changes, or new device additions, the exposed-entities and credential review is repeated.

This is the boundary that keeps the answer honest. A smart-home AI agent is not automatically unsafe, and there is no confirmed public home-hub exploit to point to as of 2026-08-25. But an agent with broad persistent credentials, un-scoped entity access, and unattended service-call authority is a real smart home security risk because the failure mode has already been demonstrated in adjacent agent systems. The practical answer is not to fear the model in the abstract. It is to make the hub’s access plumbing narrow enough that a bad instruction cannot become a bad physical action.

References

1. Building the AI-powered local smart home, Home Assistant, 2025-09-11
2. OpenAI Conversation, Home Assistant
3. Exposing entities to Assist, Home Assistant
4. Using LLMs to control a smart home, Evan King
5. home-generative-agent, GitHub
6. AI Agents Are Here. So Are the Threats., Unit 42
7. Security of AI Agents, UC Davis
8. Agentic AI Common Security Risks, Check Point
9. Careful adoption of agentic AI services, ASD/CISA/NSA/NCSC-NZ/NCSC-UK, May 2026
10. Agentic AI in the Physical World: The Read-Only Safety Protocol for Industrial IoT, IoT For All