Google Home speaks MCP now, and the door lock is off the menu

Google started an early access programme on September 16 that lets outside agents talk to Google Home over MCP. The named clients are Claude, OpenClaw, Hermes and Google Antigravity. Through the server an agent can read the structure of a household, run parameterized commands, query a device's event history and build its own dashboards on top. Access is limited to Google Home Premium Advanced subscribers in the USA. I haven't touched it (no US subscription), so everything below comes from The Verge's coverage, and I couldn't find the exact limits published anywhere.

What caught me is that this is the first MCP deployment I know of at consumer scale where a wrong tool call moves something in a real room. Most MCP incidents so far end with a leaked token or a wiped branch. Here the worst case is a garage door.

Two guardrails, and what they imply

Google names two: rate limits, and a ban on sensitive actions, with unlocking doors as the example. The ban is reported as a ban, not a confirmation prompt. The action simply isn't on the menu. Any agent, any model, any prompt injection hidden in a calendar invite, and the tool still isn't there to call. That is an allowlist by construction, and it's the right default for anything irreversible.

A confirmation dialog can be clicked through by a tired human at 11 pm, but a tool that was never exposed can't be called by anyone.

The rate limit is less obvious. I doubt it exists mainly to protect Google's servers. A loop that toggles a lamp forty times a minute is annoying, but the same loop on a smart plug feeding a heater is wear on hardware and possibly worse. Rate limits are the cheap way to cap blast radius when you can't predict what a model will decide to do.

What I'd want in the permission model

Those two rules are the floor. If I were writing the policy layer for any agent over physical devices, I'd ask for five things. Tools split by reversibility rather than by device, so switching a lamp on or off is fine and opening a lock is not. Per-agent grants, so a dashboard builder gets read access and never even sees a write tool. Limits per device and per action class instead of one global counter. A read-mostly default, with writes opt-in per room. And an audit trail recording which agent acted, on whose behalf, and what the model had been told when it decided.

Here is a sketch of how I'd express it. This is my own illustration, not Google's schema.

agent: dashboard-builder
  grant: read(structure, events)
agent: evening-routine
  grant: write(light.*, thermostat.setpoint[16..24])
  limit: 6 writes/min per device
  deny:  lock.*, garage.*, alarm.*

Look at the setpoint range. Parameterized commands are where an allowlist gets interesting, because "set thermostat" is harmless at 21 degrees and dumb at 40. Bounding parameters is the same instinct as the mass and safety limits that the Model Hardware Standard carries in its driver metadata: the layer next to the hardware knows what the hardware can take, and the model doesn't get a vote.

The part that still worries me

Read access to event history is the quiet risk. A log of when doors opened and rooms were occupied is a very good map of when nobody's home. Blocking the unlock action does nothing about an agent that can read that history and pass it on to a model provider. I don't know how Google scopes history reads (retention window, per-device consent), and that is the first thing I'd check once access opens up.

There's a second design question, and the langchain.mcp move makes it sharper. When MCP lands in the core of a popular framework, the decision about which tools an agent gets drifts toward whoever wires things together. In a home that means a hobbyist with a free weekend. So the server has to be the enforcement point, and Google seems to have understood that. A client-side instruction telling the model never to unlock the door is a suggestion. A server that doesn't expose the door is a policy.

I'd like every vendor putting MCP in front of hardware to copy the order: remove the dangerous tools, bound the parameters, rate limit the rest, log everything. What is the equivalent of the door lock in the MCP servers you run yourself?