Google’s Home MCP Turns Smart-Home Control Into an AI Agent Authorization Problem

Google opened early access today to Home MCP, a Model Context Protocol server that lets any MCP-compatible AI agent, including Claude, ChatGPT, Hermes, OpenClaw, and Google’s own Antigravity, query and control devices across a user’s Google Home ecosystem. According to TechCrunch’s Sarah Perez, the rollout covers Nest doorbells and thermostats plus any “Works with Google Home” or Matter device, down to a connected light bulb, and it hands an agent the ability to review camera summaries, monitor activity, control connected devices, and build custom dashboards from plain-language instructions.

The launch matters less as a product feature than as a test case for a question this site keeps circling back to: what happens once the tooling built to let AI agents call software APIs gets pointed at something with physical, in-your-house consequences instead of a codebase or a SaaS account. Google’s own guardrails suggest the company understands exactly what is at stake here. The protocol it built this feature on top of does not have a clean record for the kind of scrutiny that stake demands.

What Home MCP Actually Opens Up

The Model Context Protocol, introduced by Anthropic in November 2024, is a standard way for an AI agent to discover and call an external service’s tools without a developer hand-writing a custom integration for every model and every API. Google already runs MCP servers for parts of its own stack, including Google Cloud, its data platforms, its developer tools, and Google Workspace, so Home MCP extends an existing pattern to a new, much more personal category of data.

Getting connected requires a few concrete steps, independently confirmed across Unite.AI’s and Crypto Briefing’s reporting: a user creates a Google Cloud project, enables the Home API, configures an OAuth consent screen and web-application client ID, then points an MCP-compatible client at the server URL and grants access. Once that handshake is done, an agent can do more than flip a switch. Crypto Briefing reports the connected agent can analyze footage across multiple cameras at once, tally how long a light stayed on or how many laundry cycles ran in a given week, push voice announcements through Home speakers, and assemble a dashboard from whatever slice of that activity a user asks for in natural language.

That level of access is not free or universal yet. Google is limiting the early-access rollout to English-language users in the US who pay for Google Home Premium Advanced, the $20-a-month or $200-a-year tier that already includes 60 days of event-based video history and descriptive camera notifications. Google would not say whether or when the feature might reach its cheaper Premium Standard tier or other markets, and it is soliciting feedback from early adopters through its Smart Home for Developers community while the rollout continues over the “coming weeks,” per TechCrunch.

Google Built In Guardrails, and Said So

Google is not pretending this is risk-free. Per Unite.AI’s account of the announcement, Google describes Home MCP as “safe and secure by design,” built to meet the company’s existing security and privacy standards specifically so that a connected agent “cannot take sensitive actions on a user’s behalf.” The clearest example of what that means in practice: unlocking a door is explicitly on the list of actions Home MCP will not let an agent perform, alongside general rate limits meant to blunt runaway or repeated tool calls. Data tied to recognizing specific people’s faces requires its own separate, explicit consent from whoever manages the household’s Home structure, and any user can revoke an agent’s access at any time from the Google Home app or their account settings.

Google also added a hedge that is easy to miss in the coverage but worth sitting with: per Crypto Briefing, the company cautioned that “connecting outside agents could still result in unexpected behavior,” a direct acknowledgment that a blocked-actions list and a revoke button reduce risk without eliminating it. That is a reasonable, honest way to ship a feature like this. It is also an admission that the guardrails live entirely in Google’s own implementation, not in the protocol everyone building on MCP is relying on.

The Protocol Underneath Makes Authentication Optional

That distinction matters because the Model Context Protocol’s own specification does not require authorization at all. The current MCP authorization specification states plainly: “Authorization is OPTIONAL for MCP implementations.” Where a server does implement it, the spec adds a further carve-out that undercuts the case for treating auth as a given: implementations using the STDIO transport, the local, process-to-process channel a large share of desktop MCP servers use by default, “SHOULD NOT follow this specification, and instead retrieve credentials from the environment.”

The same specification is candid about the failure mode this produces. It has a dedicated section titled “Confused Deputy Problem,” warning that “attackers can exploit MCP servers acting as intermediaries to third-party APIs” by using stolen authorization codes “to obtain access tokens without user consent.” That is not a hypothetical the spec’s authors invented. It is the exact vulnerability class sxz.io covered in depth in its own tutorial on fixing the confused deputy problem with scoped authorization tokens, and the reason Cloudflare shipped optional, task-based OAuth scopes for MCP servers earlier this year rather than forcing users into an all-or-nothing grant.

What Optional Authentication Has Already Produced

None of this is abstract risk. The Cloud Security Alliance’s AI Safety Initiative published a research note in May 2026 documenting at least seven confirmed high- or critical-severity CVEs against MCP implementations, with more under active tracking, and an internet-wide scan from July 2025 that turned up 1,862 publicly reachable MCP servers responding to unauthenticated requests. The same note ties roughly 200,000 vulnerable MCP instances to a single compromised software supply chain, with downstream effects reaching tools like LiteLLM, Cursor, Windsurf, LibreChat, and Flowise.

Two incidents from that same window show what “optional authentication” looks like once someone exploits it.

A Fake Package That BCC’d Every Email It Sent

In September 2025, a fake npm package called postmark-mcp impersonated a legitimate email-sending MCP integration, shipping 15 clean versions to build trust before version 1.0.16, released September 17, quietly added a single line of code that blind-copied every outbound email to an address the attacker controlled. The Hacker News reported the mechanism itself, and Koi Security disclosed the backdoor eight days later, on September 25; the security firm’s co-founder Idan Dardikman estimated that roughly 300 of the package’s 1,643 downloads were organizations actively using it in production, together leaking an estimated 3,000 to 15,000 emails a day. Postmark pushed back hard on that estimate, telling The Register that only one of its actual customers had used the fake package, a reminder that download counts and confirmed victims are not the same number.

A Critical Flaw in the Proxy Millions of Setups Rely On

Separately, sxz.io independently confirmed CVE-2025-6514 directly against the National Vulnerability Database: an OS command injection flaw in the mcp-remote proxy, disclosed by JFrog Security Research in July 2025, that let a malicious MCP server run arbitrary commands on a connecting client’s machine by crafting the URL it returned during an authorization exchange. NVD scores it 9.6 out of 10, critical severity.

Google’s own implementation is not implicated in any of that history, and building a proprietary, tightly scoped MCP server on top of the Home API is a meaningfully different exposure than an open-source proxy or a third-party npm package with no vetting at all. But the incidents above are not edge cases dredged up from MCP’s earliest, roughest days. They land in the same twelve-month window Google chose to build a consumer smart-home integration on the same underlying standard, one whose own specification still treats server-side authentication as optional rather than required.

Why a Living Room Is a Different Kind of Attack Surface

A compromised coding-agent MCP server can leak source code, API keys, or a cloud account’s credentials. A compromised smart-home MCP server can leak whether anyone is home, what a household’s daily routine looks like from its own security cameras, and a rolling log of exactly when every door, light, and thermostat in the building changed state. Google’s decision to explicitly block door unlocking is a tacit admission that irreversible physical actions sit in a different risk tier than reading a camera summary, and it is the right first line to draw. It does not change the fact that camera footage, presence data, and full device-state history are exactly the kind of information a scoped OAuth token is supposed to protect, and exactly the kind of information a confused-deputy attack or a token-passthrough bug is built to steal.

Home MCP’s early-access gating (one country, one language, one subscription tier, weeks of staged rollout) reads like a company giving itself room to find problems before they reach a mass audience, which is a more careful posture than most of the MCP ecosystem’s incident history displays. That caution is worth taking at face value. It is also worth remembering that Google is choosing to add every safety property this feature has (blocked actions, rate limits, granular consent, one-click revocation) on top of a protocol whose baseline security posture, per its own written specification, requires none of them.

Readers building or evaluating their own MCP integrations can find sxz.io’s practical walkthroughs on locking this down directly: the confused deputy tutorial covers replacing prompt-based restrictions with signed, scoped tokens enforced in code, Cloudflare’s task-based OAuth consent model shows how to let a user grant less than full access in the first place, and the site’s coverage of Cloudflare’s temporary, credential-free agent accounts is a working example of an alternative to handing an agent a long-lived bearer token at all.