Before You Connect an AI Agent to Your Smart Home: What a Scan of 15,465 MCP Servers Found

Over the last few weeks I've written about almost every way to hand an AI agent the keys to a smart home: Home Assistant's built-in MCP server and the community ha-mcp, Hubitat's community server with per-client tokens, openHAB's MCP add-on, and a Mac app that opens a tunnel so ChatGPT can drive your lights. Each piece had its own safety notes.

What I didn't have was numbers on how the wider MCP world actually behaves. OX Security just provided some, and they're not comforting.

What OX found

OX's security research lead laid out the findings in a contributed article on The Hacker News on October 6, with more on OX's report page. They "analyzed 15,465 publicly indexed MCP servers across 5 MCP registries, deduplicated to 5,095 unique hostnames." The findings that matter for a house:

• No vetting. "MCP marketplaces have no equivalent" of an app-store malware scanner. "Anyone can write a server, push it, and publish it."
• The repo might not be what's running. "Remote MCP servers can run backend code that differs entirely from what their public repository shows." Reading the GitHub code tells you what the author published, not what their server does.
• Home tunnels. 0.45% of servers "route traffic through consumer tunneling services, mainly ngrok-free." OX's read: these run "from personal machines and, likely, home networks."
• Dead domains. 2.3% no longer resolve, and six sit on expired domains "that anyone can register for $4 to $12 a year." Whoever buys one inherits every agent still configured to call it.
• "Always allow" can outlive its welcome. In OX's testing with Claude Code running Haiku 3.5, one "Always-Allow" permission let a malicious MCP server use later prompt injection to get privileged file access "without another user confirmation." The same attack failed against Opus 4.6 and 4.7.

What it doesn't say

I want to be careful here. OX looked at servers listed in public registries. It didn't scan home automation servers specifically, and it doesn't say it found any Home Assistant, Hubitat or openHAB MCP server exposed. 0.45% of 5,095 hostnames is a couple dozen machines. This is not "your smart home is hacked."

What it does show is the shape of the risk. The weak spots are the same ones that came up in every home MCP story I've covered: one powerful token, a tunnel to the internet, a server you didn't write, and an agent you told to stop asking permission.

My checklist for a home MCP setup

This is pulled together from the platform docs and everything I've covered so far. None of it is exotic.

1. Start with your platform's built-in server. Home Assistant's built-in MCP server only sees entities you've exposed to Assist and supports OAuth 2.0 with PKCE, so you sign in rather than paste a forever token. Hubitat's built-in AI (MCP) Connector is local-only. openHAB's add-on leaves the dangerous features off until you turn them on. First-party servers ship with your hub's updates. That beats a stranger's server on almost every count.

2. Use the narrowest credential you can. A dedicated user, not your admin login. In openHAB, the token inherits its user's permissions, so make a limited user. On Hubitat, the community server now gives each AI client its own token with its own tool list and read/write limits. One leaked key should cost you one client, not the house.

3. Keep locks, garage doors, alarms and water valves out at first. Expose lights and sensors. Add anything that can open a door or flood a basement only when you have a specific reason and have watched the agent behave.

4. Prefer read-only for anything automated. ha-mcp has a /readonly endpoint. Read its own fine print: it's "a connection mode for automated agents, not a separate permission on the credential." It stops a well-behaved agent from writing. It does nothing if someone else has the URL.

5. Don't click "Always allow" on write tools. OX's test shows why. Auto-approve reads if you like. Make writes and deletes ask every time. It's a few extra clicks. It's also the only thing standing between a prompt-injected agent and your configuration.

6. No public tunnel unless you need one, and never left open. Cloud assistants like Claude's connectors or ChatGPT need to reach your server from the internet. That's the trade-off. If you do open a tunnel, make it short-lived. House Control's AI Access is a good model: a random tunnel URL that dies when you stop it, with an auto-stop timer. I'd set that timer to an hour. If your agent runs on the same machine, skip the tunnel.

7. Only install MCP servers you can trace. Prefer servers that run locally, from a repo you can read, with real release notes. Be very wary of remote MCP servers from registries: per OX, you can't verify what's running. And prune your config. An old server entry pointing at a domain that's since lapsed is exactly the takeover OX describes.

8. Patch the platform, too. The agent isn't the only attack surface. openHAB's 5.2.2 release fixed five security advisories, including an OAuth code-theft bug in the login and proxy code that sits in front of everything, MCP included. The same release also fixed local OAuth in the MCP add-on itself.

The honest bottom line

Nothing in OX's numbers says "don't do this." I think AI agents are genuinely useful for building automations and dashboards, and I'll keep covering them. What the numbers say is that nobody is vetting this ecosystem for you. Your hub's vendor vets its own server, sort of. Everything else is on you.

So treat an MCP connection like you'd treat giving a contractor a key: the smallest key that does the job, for as long as the job takes, and you check the work before you leave them alone with it.