15,465 MCP servers. That is the number that opened the file.
The second number was 0.45 percent — the share of those servers reachable through consumer-grade tunnels rather than hardened infrastructure. The third was a date: 2026-09-16, the stated launch of a Google Home MCP integration. The fourth was a product name, a shopping agent called Muse, wired to Stripe Link with one-time virtual cards, and a subsequent ban on that agent's checkout path.
Two of those four survived verification. The other two did not resolve at all.
I do not open with the narrative. I open with whether the timestamps resolve. A claim with an unresolvable timestamp is not a fact. It is a hypothesis wearing a fact's clothing. The document I was handed — a scenario analysis of a home AI agent's first autonomy test — had a fact layer that failed systematically while its framework layer held up under real pressure. That split is the story. The home agent is only the vehicle.
Data doesn't care about your timeline. Neither does an audit trail.
The Fact Layer Failed. The Framework Layer Held.
The document cited a "D25 cycle" as a temporal framework. No public definition exists. It is not an industry term. It is the kind of self-invented periodization that generative text produces when it wants to sound authoritative — a label with no referent.
It also cited "Secure Exclaves" as an Apple silicon security primitive. The real term is Secure Enclave. "Exclaves" has no corresponding concept in any published Apple architecture documentation. One wrong term is a typo. A wrong term in the security section is a signal about provenance.
It described an Amazon block on third-party AI checkout agents. No record of that specific action exists. But the pattern is real — platform operators have repeatedly restricted automated agents from transacting on their surfaces. The event was unverifiable; the pattern was accurate. That distinction matters more than most analysts admit.
The one number that behaved was the exposure count: 15,465 MCP servers, 0.45 percent on consumer tunnels. Independent scanning research through 2025 consistently placed exposed MCP infrastructure in the thousands to low tens of thousands, with a small minority sitting on residential-grade connectivity. The order of magnitude held. The specific figure remains unconfirmed.
Here is my operating rule, built during three months of manually auditing 10,000-plus lines of Solidity for the 0x Protocol v2 exchange in 2018: every claim gets a line number or it gets demoted. Seven critical findings that winter survived because each one pointed at a specific function, a specific state transition, a specific overflow. The claims that did not point anywhere were noise. I filed them as noise and moved on.
Applying that rule here: the framework earns medium-high confidence. The facts earn the lowest available confidence. Analysis proceeds on that weighting.
What the Document Actually Argued
Stripped of its unverifiable surface, the document described a home agent operating across three ecosystems — a voice assistant bridge, a commerce agent, and a device-control layer — and identified three structural chokepoints.
Platform veto. The cloud intermediary can hard-block categories of action. Door locks are excluded outright, regardless of user intent.
The approval paradox. Any action carrying real-world consequence requires a human click. The click is presented as safety. It is equally a liability transfer.
Identity fragmentation. The agent authenticates as the user in some contexts, as a device in others, and as an application in a third set. No single verifiable identity spans the three.
The document also flagged that the device maker's terms of service explicitly exclude life-safety use cases. That one is directionally correct — consumer smart-home terms routinely carve out critical reliability scenarios. It is not legal boilerplate. It is a publicly drawn boundary of responsibility.
The Three Chokepoints, Restated as Data
None of the three is a model-capability problem. That is the first thing to establish, because the public conversation keeps misframing it as one.
Perception and planning — understanding an intent, generating a plan — reached production adequacy some time ago. Cross-ecosystem execution sits in restricted production: platform allowlists and blocklists determine what an agent may touch, and locks are excluded. Unsupervised physical execution is proof-of-concept, confined to small-value, reversible, allowlisted actions. Safety-critical execution is explicitly research-stage, and the vendor's own disclaimer says so.
So the maturity ladder is not a capability ladder. It is a governance ladder. The binding constraint is authority, not intelligence.
MCP is the clearest case. The protocol's job is capability discovery and invocation — tools, resources, prompts, transported over JSON-RPC. It answers the question "what can this system do?" It does not answer "is this system permitted to do it, on whose behalf, for how long, and revocable by whom?" OAuth-based authorization was layered on in 2025 and improved delegation. It still lacks fine-grained, delegable, revocable capability credentials at the protocol level.
Where protocol-level authority is missing, the platform substitutes a blunt instrument: ban the category. That is technical debt wearing a business-model mask. Both things are true simultaneously — the lockout protects the ecosystem and it protects the platform's liability exposure. They are not separable, and pretending otherwise produces bad analysis.
The attack surface is not theoretical. Multiple classes of MCP exploit have been publicly reproduced: tool poisoning, where malicious instructions hide inside a tool's own description; rug pulls, where a server ships benign and mutates later; confused-deputy attacks, where the agent is induced to exceed its intended scope; token passthrough, where credentials leak across trust boundaries. Combined with thousands of servers directly exposed to the open internet, the base rate is not low.
In a home, a data breach upgrades into a physical intrusion. That is a change in risk category, not risk magnitude.
I have run this analysis before in a different domain. In 2021 I traced 12,000 BAYC transactions across Etherscan and isolated 45 addresses controlled by a single entity, cycling volume to inflate a floor price. The mechanics were not sophisticated. They were just unexamined. Artificial volume looks identical to organic volume on a chart until you resolve the counterparties. Exposed agent infrastructure looks identical to hardened infrastructure until you resolve the tunnels. Same forensic move, different dataset.
MCP Solves Discovery. It Does Not Solve Authority.
The architecture explains the veto. Instructions route through the platform cloud. The platform is therefore the policy enforcement point by construction. This is not an implementation flaw — it is the consequence of choosing cloud mediation over local direct control.
The genuine technical fork is local-first versus cloud-mediated, not strong model versus weak model. Matter and Thread already provide a local connection layer for cross-ecosystem device control. The document omitted this entirely, and that omission is its largest structural blind spot. Local control routes around the enforcement point. The price of routing around it is losing the platform's identity and policy apparatus — which is exactly the apparatus that currently absorbs the liability.
So the tradeoff is explicit. Cloud mediation buys you governance and sells you autonomy. Local control buys you autonomy and sells you governance. Neither is free, and no amount of model improvement changes the terms.
The Authorization Layer Already Exists — On-Chain
This is where the home-agent conversation should be borrowing from crypto, and is not.
Smart account architectures have spent years solving precisely the problem the document describes as unsolved. Session keys, scoped permissions, spend ceilings, expiry windows, merchant allowlists, category restrictions, per-transaction caps, and revocation that executes without the counterparty's cooperation. An agent can be granted a bounded mandate: this merchant, this ceiling, this time window, this category, revocable at any block. Inside the boundary it operates without a human click. Outside it, execution reverts.
The important property is not the frictionless execution. It is cryptographic auditability without human presence. Every action lands in a state transition that can be reconstructed after the fact by anyone, without trusting the operator's logs.
The document treated the human approval click as the only available solution. That is a failure of technical imagination, and it is the most consequential blind spot in the entire framework. A click proves a human was present. It does not prove the human understood the action, it does not bound the action's scope, and it does not survive repetition — approval fatigue turns a safety mechanism into a rubber stamp within about two weeks of daily use.
I watched the on-chain version of this fail in slow motion. The ERC-20 infinite approval became standard practice because clicking was annoying. Every wallet that ever granted an unlimited allowance to a contract it did not audit converted a bounded risk into an unbounded one. Agent design is walking directly into the same trap, in a new costume. An over-scoped session key is the approve(MAX) of agent architecture.
Agentic payment rails are converging on the correct primitive — per-call metered payment, one-time virtual cards, scoped tokens issued by the card network rather than the merchant. The pieces exist. What is missing is a consumer-facing mental model for scoped delegation, and an insurance market willing to price it.
Irreversibility Is a Schema Problem, Not a UX Problem
Here is the deepest structural difference between a home agent and a code agent, and the document never names it.
Software actions are mostly reversible. You revoke an API call, roll back a commit, cancel a transaction before finality. Physical actions are mostly not. A door that opened is a door that opened. A purchase that shipped is a purchase that shipped. There is no mempool for a hallway.
That asymmetry is why the approval click exists. It is not an interaction design choice. It is a compensating control for missing transactional semantics. The system cannot express "this action is provisional for 30 seconds and auto-reverts unless confirmed," so it substitutes "a human must click before we commit."
On-chain systems solved the analogous problem with finality windows, escrow, and state channels. Physical systems have no equivalent because physical state has no revert function. The only available substitute is pre-commitment — deciding the boundary before the action, not approving the action after it.
The Liability Vacuum
The document's most consequential omission is not technical. It is legal.
When a lock misreads a visitor, a purchase executes wrongly, or a device misfires, who pays? The model provider, the platform, the device manufacturer, or the user? The document does not say. Neither does anyone else.
No responsibility allocation means no insurance. No insurance means no commercial scale. That is the first constraint on deployment, ahead of every technical consideration. The vendor's life-safety disclaimer is not defensive drafting. It is the boundary of the liability they have declined to accept.
The approval click is a liability hedge in disguise. Someone clicked, therefore someone owns the outcome. The friction is a byproduct. The indemnity is the product.
Biometric data compounds this. Facial templates are special-category data under GDPR Article 9, requiring explicit consent, and the household exemption dissolves the moment templates transit to a cloud intermediary. Illinois BIPA has produced settled class actions in the hundreds of millions of dollars against consumer facial recognition deployments. The "maximum six registered users" limit is simultaneously an engineering tradeoff on false accept and false reject rates and a compliance containment boundary. Those two constraints happen to point the same direction, which is why the number exists at all.
There is a further blind spot nobody has addressed: the household has an internal power structure. Who gets to be one of the six? Are domestic workers excluded by default? What happens when monitoring capability is used by one partner against another, or by an adult child against a parent? These are not hypotheticals. They are the documented failure modes of every always-on home sensing system shipped to date, and agent autonomy multiplies them.
Correlation Is Not Causation: The Veto Is Not Antitrust
The tempting read is that platform vetoes are anticompetitive moats dressed as safety. Some of that is true. But the causality runs the other way more often than the narrative allows.
Platforms block physical actuation because they cannot transfer the liability, and because the authorization layer that would let them transfer it does not exist at the protocol level. Fix the authority layer and the veto becomes negotiable. Leave it broken and the veto is the only rational posture, regardless of how competitive the platform feels like being.
Follow the metadata, not the mood. The metadata here says: capability discovery shipped, authorization governance did not. Everything downstream — the veto, the approval card, the six-user cap, the disclaimer — is a downstream consequence of that single gap.
And the counter-narrative that agents simply need better models is not supported. Every one of these failures reproduces identically with a perfect model. A perfect model with an over-scoped credential is a perfect model doing the wrong thing with full confidence.
What to Watch
Three signals, all observable, none requiring a press release.
First, the credential ratio. Watch the share of exposed MCP servers that authenticate with scoped, expiring, revocable credentials versus static API keys. That ratio is the real adoption curve for agent autonomy, and it is measurable today.
Second, session-key grant sizes. Watch the distribution of permission scope on smart accounts interacting with agent endpoints. If median grants trend toward unlimited and non-expiring, the approve(MAX) mistake is repeating at scale and the next incident is already scheduled.
Third, the first liability product. The moment an insurer writes a policy covering agent-initiated physical or financial actions, the constraint has moved from governance to pricing. That date is the actual start of consumer agent deployment, and it will not be announced by any of the companies currently arguing about model benchmarks.
The number I opened with was 15,465. The number that matters next quarter is how many of those servers can prove, cryptographically, who authorized what.
That number is currently close to zero. Data doesn't care how good the demo looked.
