Home Assistant's AI Can Act on Your House Now. Start It Read-Only

For most of this year, giving an AI agent access to Home Assistant meant one of two things. You used the built-in MCP server and got a polite assistant that could only touch what you'd exposed to Assist, or you installed a community server like ha-mcp and got something that could rewrite your automations.

In the same week in late October, both sides moved. Home Assistant's 2026.11 release gives its AI tooling the ability to act, and adds the first first-party switch for limiting it. The ha-mcp project shipped a release that's mostly about locking itself down. Put together, there's finally a sensible way to set this up.

What Home Assistant 2026.11 adds

From the 2026.11 release notes, in the section titled "Your AI assistant can help troubleshoot":

The LLM API already gave assistants tools to search devices and automations, review logs and look up historical statistics. Log access requires an admin account. Then: "This release goes a step further. An assistant can look up your system information, search the actions that are available, and call one. It can list your integrations and reload one."

Home Assistant's own advice in the next sentence is the one I'd tape to the monitor: "That makes it something that can act on your setup, not only read it, so give it the access you are comfortable with and no more."

Two guardrails came with it:

• A read-only MCP mode. "You can set the MCP server to expose only read-only tools."
• Conversations belong to whoever started them. "An AI conversation can now only be continued by the user who started it." That closes a gap where someone else could pick up a conversation, and the tools that came with it.

One more detail that matters: "Any LLM API becomes available only once an administrator attaches it to a conversation agent or to the MCP server." Nothing new is wired up for you. KNX users also get an LLM API of their own, with tools for the telegram store, project file and data point types.

What the MCP server docs add

The release notes mention read-only mode but not how it works in the UI. The Model Context Protocol integration documentation fills that in.

• Read-only is off by default. You have to turn it on if you want it.
• Where to change it: Settings > Devices & services > Model Context Protocol > Configure. (The main MCP URL is also listed under Settings > System > AI.)
• It only applies to the main URL (/api/mcp, shown as Main URL). Configuration options such as read-only affect that endpoint only.
• Individual tool-set URLs are never read-only. Each set has its own URL under Individual URLs (for example /api/mcp/assist for Device control). Those URLs ignore the read-only setting. /api/mcp/assist is still limited to entities you expose to voice assistants; the other individual URLs require an administrator account.

That integration page does not describe a per-action allow or deny list. Choosing which tool sets the main URL exposes only works after you turn off Expose all AI tools, which is on by default. The release notes describe call-action and reload capabilities under Home Assistant's LLM API, but the integration docs do not map those tools to a specific named set.

What ha-mcp v9.0.0 changed

ha-mcp is the community MCP server a lot of people use to let Claude, ChatGPT or Cursor edit Home Assistant dashboards and automations. It had more than 5,000 GitHub stars when the project was checked on October 30. Version 9.0.0 came out October 28, and the "Added" list reads like a security review:

• "Access switch to grant and revoke access to the in-process server." As I read it, that's the copy that runs inside Home Assistant through its component. You can now turn agent access on and off without uninstalling anything.
• "Locked-down defaults for new server entries, no secrets in the log."
• "None-mode OAuth redirects only to allowlisted callbacks," plus an optional callback allowlist.
• "Run the in-process server with an administrator's own token."
• "Run the server each component release pins instead of self-updating it." That's a supply-chain fix. A server that updates itself is running code you never chose to install. Pinning means you get a new server version when you update the component, on purpose.
• Secret redaction for operator-listed app option keys, and snapshot backups stored where Home Assistant stores its own.

The fixes are the same flavor: refusing a restart during a database upgrade, hiding hidden scripts, scenes and automations even when an agent asks for them by key, binding the consent form's token to its own authorization code, and restoring entity backups to their registry settings. Pre-release work toward 9.1.0 also refuses credential and user-management WebSocket commands in the raw escape hatches.

I haven't run v9, and the release notes are item titles, not docs. But the direction is clear. The project that gives agents the most power is now spending a release on taking it back by default.

How I'd set up agent access now

This is the order I'd do it in, for either server.

1. Start read-only. On Home Assistant's built-in server, turn on the read-only option once you're on 2026.11. On ha-mcp, keep the locked-down defaults on new entries. Let the agent look around for a week before it can touch anything.
2. One user per agent. A separate Home Assistant user for each AI client means you can see what did what, and cut one off without breaking the others. The per-user conversation rule in 2026.11 makes this more useful.
3. Widen access one step at a time. If you need write access, give it for a job and take it back after. ha-mcp's access switch exists for exactly that.
4. Keep household voice on Assist. Voice in the kitchen should only reach exposed entities. Save the admin-level tools for when you're actually managing the system.
5. Don't let servers update themselves. Pin versions and read the release notes before you move up.

If you're still deciding which server to use, my comparison of Home Assistant's built-in MCP server and ha-mcp covers the basic split. The other platforms are working on the same problem in different ways: Hubitat's community MCP server uses per-client tokens limited to chosen tools, and openHAB's MCP add-on ties an agent's access to the openHAB user behind its token, with the risky capabilities off by default.

The common thread is that "can the AI do this?" stopped being the interesting question. "Should this agent be allowed to, right now?" is the one that matters. With 2026.11, Home Assistant gives you a switch for it.