Home Assistant Will Show Your AI Agent Its Logs. Know Which Door You're Opening

The most common thing people want from an AI agent in their smart home isn't "turn off the lights." It's "why did my integration break?" Until now, getting an answer meant pasting logs into a chat window or running a community MCP server with broad access.

Home Assistant 2026.11 builds that in. The way it does it is worth understanding before you turn it on.

There are now two doors

Home Assistant's AI plumbing has a concept called an LLM API, the set of tools an AI model gets when it talks to your house. For a long time there was really one that mattered: Assist. It can see and control the entities you've chosen to expose, and nothing else.

In October a second one landed. PR #181958, merged October 8, adds the Home Assistant API (its ID is homeassistant). From the PR: it "manages Home Assistant itself and requires an admin user. Its scope is not bounded by entity exposure. The existing assist API continues to control and read exposed entities."

That last sentence is the whole design. Assist is the door for the household. The new one is the door for whoever administers the system. The PR notes the scopes proposal was approved by the core architecture meeting the same day.

The first tool behind the admin door was modest: read the in-memory warnings, errors and critical log entries, with filters and optional tracebacks.

What it can do now

Two more tools merged on October 23, and they're the ones that make this useful.

Full log timeline (PR #187971, by Paulus Schoutsen). The agent can read "the full logs in a time window, merged into one timeline and paged from a start time." On installs with Supervisor, that covers Home Assistant, Supervisor, host, plugin and app logs. Other installs get the log file. The point, per the PR: "This lets an LLM see what happened around an error."

Integration status (PR #188127, by Allen Porter). A read-only tool, config__get_config_entries, lets the agent list your installed integrations, filter by domain and by status (loaded, error, not_loaded), and read the translated error reason for each.

Put those together and you get the workflow people have been hacking together with community MCP servers. "Which integrations failed to load? Show me the logs from two minutes before that." Both tools read. Neither changes anything.

The argument in the pull request

What I liked most here is that the privacy question got argued in public before it merged.

Reviewer mdegat01 raised it on the log PR. His worry was that anyone who had already set up the MCP Server integration and connected a client would suddenly have logs "from every piece of the HA ecosystem including apps" available to that model, which is "probably a cloud service like Claude, ChatGPT, etc." He pointed out that nobody has systematically stripped personal data from those logs, especially app logs, and suggested an explicit opt-in toggle.

Paulus's answer: nothing is "automatically fed." It's an API. If you ask your model to look at your logs, it will. This is the management API, and connecting it means you intend to manage Home Assistant. He said the team will keep adding tools there and shouldn't require extra opt-ins for each. mdegat01 accepted that once it was clear the model reads logs when asked, not on its own when you open a page.

Franck Nijhof (frenck) then pushed on the part I'd worry about most. Integration debug logs regularly carry tokens and raw payloads, app logs "can carry anything," and through MCP "the model decides on its own when to read." He asked for a best-effort masking pass for obvious patterns like bearer tokens and passwords. The review thread shows credential masking was added and tuned before merge.

I come down closer to mdegat01 than the final design does. "The model reads when you ask" is true. It's also true that agents ask themselves things. The masking is a good backstop, not a guarantee. The OHF Daily summary says it straight: selecting the management connection "can share the requested logs with the configured AI provider."

A security fix that came with it

The same day, Paulus merged PR #188126. The bug it fixes: "Anyone who knew a conversation ID could continue another user's conversation, with its history and tools." Now a conversation has an owner, the user of its first input, and only that user can continue it.

That matters more once admin tools exist. You don't want a non-admin picking up an admin's conversation that had log access.

One side effect worth knowing. In review, frenck noted that if you call conversation.process with a fixed conversation_id shared between users or automations, that now gets refused, and in a voice pipeline it shows up as "Unexpected error during intent recognition." If you've built automations that reuse one conversation ID, look there first when something breaks after the update.

How I'd use it

• Keep household voice and chat on Assist. That's what it's for, and exposure still limits it.
• Connect the admin API only when you're troubleshooting, and only with an admin account you control. I wouldn't leave it wired to a cloud model full-time.
• Think about which provider sees your logs. If you run a local model, this is a good use for it. If you use a cloud one, assume what's in your logs goes with the request.
• Turn off debug logging when you're done. Debug logs are where tokens and raw payloads show up, and that's exactly what you don't want an agent reading later.

When you'll get it

All four changes are in Home Assistant 2026.11. The 2026.11 beta release notes say the LLM API gives assistants tools to "review logs," that "Log access requires an administrator account," and that an assistant "can list your integrations." They also confirm the conversation fix: "an AI conversation can now only be continued by the user who started it." All four pull requests are in the 2026.11 changelog.

Two things to keep in mind. This is the beta, and the notes say "some features may not make it into the final release." The stable release wasn't out when I checked on October 31; the notes point to a release party on November 4. And the notes don't spell out the full log timeline or the integration status filter, so for those details the pull requests are still the source.

The beta goes further than what I've covered here: an assistant can also call actions and reload integrations, and the MCP server gets a read-only option. That's a bigger change, and it deserves its own look before you connect anything.

If you're deciding how to connect an agent in the first place, my comparison of Home Assistant's native MCP server and ha-mcp and the home MCP server security checklist cover the rest. This change adds one line to that checklist: know which door your agent came in through.