Google Just Let AI Agents Into The House. Who Decides What They Can Touch?

On 16 September, Google started rolling out early access to a Home MCP server. In plain terms, an AI agent such as Claude, OpenClaw or Google Antigravity can now list the devices in a Google Home, read their state, look at the history, and switch things on and off in response to a sentence.

I use AI agents every day, so I'm not writing this to be the grumpy installer. I'm writing it because the interesting part of the announcement is not the capability. It is the question of who draws the boundary.

What Google actually shipped

TechCrunch reported that access is limited to Google Home Premium Advanced subscribers in the US, at $20 a month, with the rollout continuing over the coming weeks. Google's own material describes four abilities: listing entities, checking live state, controlling devices, and querying history. The setup is not one click. You create a Google Cloud project, configure the server, hand the details to your agent, then sign in and grant permissions.

Google also says the system is designed "so agents can't take sensitive actions on your behalf." According to the coverage I read, unlocking doors is the example it gives of something agents are prohibited from doing. The coverage also mentions rate limits, and Google recommends telling other household members when a shared home is connected to an agent. One line I liked for its candour: Google warns that a connected agent's behaviour "can sometimes be unexpected or undesired."

None of this is available in South Africa today, as far as I can tell. I have not used it, and I'm going by Google's documentation and press coverage.

The intern problem

Think of an agent as a very fast intern. It is capable, keen, and reads every instruction as if it came from you. The trouble is that it can also read an instruction that did not come from you. OWASP's recent work on agentic AI found prompt injection sitting behind six of its ten risk categories, because these systems treat the system prompt, the user's request and any outside text as one stream. A calendar entry, an email or a web page can carry instructions.

Two rules of thumb are circulating in that discussion. One is the "lethal trifecta": an agent with private data, exposure to untrusted content and a way to send things out is an exfiltration risk. The other is Meta's "Agents Rule of Two": an autonomous agent should have at most two of those three, and needs a human in the loop if it has all three.

Picture a home agent that can see camera history, and that you also let read your email and send messages. That is all three. So the question of what it can do to the physical house matters a lot.

One vendor's list is not your house's list

Google chose the door lock as its example of a sensitive action, and I understand why. It is the obvious one.

But sensitive is a property of the house, not the product. In the homes I work on, the list is different. It might be the borehole pump, the gate motor, the geyser, the pool pump, the gas isolation valve, or the heating in a wine cellar. A vendor cannot know which of those matters in your home. Somebody who has walked the site can.

This is the same argument I make about handover. The person who designs the system should decide what is exposed, and then write it down.

How I'd set it up on a KNX job

My view, from the integration side, and not a tested standard.

Keep the agent away from the raw bus. If you expose every group address, you have handed a fast intern the master key. Expose scenes and a curated set of readings instead: "evening", "away", a room temperature, a door contact. In Home Assistant, entities must be explicitly exposed before an MCP client can reach them, according to the documentation. That is the right instinct. The integration has been available since Home Assistant 2025.2 and the docs put usage at about 4.5% of active installations.

Start read-only. An agent that can tell you what happened while you were out is useful and low risk. Add control one scene at a time.

Put the safety logic in the hardware, not in the agent. Leak shutoffs, frost protection, setpoint limits and run-time limits belong in the KNX actuators and room controllers, where a wrong instruction from anywhere gets refused at the device. Check each product's application manual for what it supports, because it varies. This is the same principle behind Matter 1.6's Thermostat Suggestions, where the thermostat can decline. An agent that asks nicely should be able to be told no.

Be careful with the community tools that go further. The popular unofficial ha-mcp server, at about 4.6k GitHub stars when I looked, exposes 87 tools, including creating, editing and removing automations and editing configuration. It also offers a read-only mode and per-tool switches. Great for your own test system. On a client's live house I would switch it to read-only or not install it.

Keep an audit trail, and tell the household. Google's advice to inform other household members is right. If an agent can turn off the lights at night, the people who live there should know.

Where this leaves us

Agents will get to the house. The useful question is whether the person who understands the house draws the boundary, or a checkbox in a cloud console does. A wired KNX system with a well-designed integration layer keeps that decision with the owner and the integrator.

If you want to talk through what an AI agent should and should not be allowed to touch in your project, I'm happy to. Just a conversation about what the project needs.

wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za

Sources: TechCrunch, "Your AI agents can now control your Google Home devices" (16 Sept 2026); Unite.AI, "Google Opens Home MCP Early Access to AI Agents for Smart Home Control"; Google Home Developers, "Home MCPs" (developers.home.google.com/mcp); aicybr.com guide to Google Home MCP requirements and safety limits; Home Assistant, "Model Context Protocol Server" integration docs; GitHub, homeassistant-ai/ha-mcp; Help Net Security, "Prompt injection still drives most agentic AI security failures" (11 June 2026).