The Home Agent Autonomy Test Is an Authorization Test — Not a Model Test

Fifteen thousand four hundred and sixty-five. That's the count one security firm put on MCP servers reachable from the open internet, with roughly 0.45% of them — call it seventy — shielded by nothing more than a consumer-grade tunnel, the kind of thing you spin up on a laptop over a weekend and forget about for a year. Now put that server in a hallway. Give it the front door, the thermostat, a payment method, and a camera. Ask it to let the plumber in. The uncomfortable part isn't that a model can plan that sequence. Models have been able to plan it for a while. The uncomfortable part is that nobody has published a serious stress test of what happens when the plan is wrong — not wrong in the hallucination sense, wrong in the "the door is now open and the person on the porch is not the plumber" sense. We didn't spend the last decade building authorization for software that can open a door. We built authorization for software that moves money, and we built it badly enough that infinite token approvals are still the default on most wallets. The home agent inherits that legacy and raises the stakes, because a bad approval costs you a wallet and a bad unlock costs you a house. Three sticking points keep surfacing in every account of this problem: the platform's veto over what an agent may touch, the approval card that asks a human to click yes, and the identity layer that fragments the moment you leave one vendor's ecosystem. Read them again. None of them is a model problem. MCP — the Model Context Protocol — is a JSON-RPC interface for discovering and invoking tools, resources, and prompts. That's it. It is a capability discovery layer, and it is good at that job. It standardized how an agent learns what exists in the world; it did not standardize who is allowed to touch what, under which conditions, with what recourse. The OAuth-based authorization framework that landed in 2025 got us delegated access in the coarse sense, but there is still no native primitive for a fine-grained, attenuable, delegable, revocable capability credential. The protocol knows what a tool is. It does not know what a mandate is. That gap explains the whole architecture. Because the instruction path runs through the platform's cloud, the platform sits at the policy enforcement point whether it wants the job or not. Hard-blocking door locks from third-party agents isn't primarily anti-competitive posturing — it's what you do when you have no authorization layer and you're on the hook for the outcome. Meanwhile the ecosystem has already reproduced every classic failure mode: tool poisoning, where malicious instructions hide in a tool's own description; rug pulls, where a benign tool mutates into a hostile one after listing; confused deputy, where the agent is talked into exercising authority it legitimately holds on behalf of someone who shouldn't have it; and token passthrough, where credentials leak down a call chain that was never designed to carry them. Thousands of servers exposed to the open internet. Data breaches in a home context escalate into physical intrusion. One more thing before the analysis, because it changes the weight of everything that follows. Much of the source material circulating on this topic is not reporting. It contains a "D25 cycle" that no one has ever defined, product launches dated to 2026 with no public record, and an Apple "Secure Exclaves" — a term that does not exist, sitting one consonant away from a Secure Enclave that does. That kind of mismatch is the fingerprint of generated text, not of a leak. But the pattern underneath is real: Amazon has genuinely moved against third-party AI shopping agents, and vendors genuinely do carve life-safety scenarios out of their terms. So I'm reading the framework as credible and the specifics as noise. The framework is what's worth your attention. Start with the part crypto people should recognize instantly. The lineage of capability tokens — macaroons, then biscuits with their attenuating caveats, then session keys in the account abstraction stack — is the only mature answer we have to the triad of delegable, attenuable, revocable. A biscuit can be handed to a sub-agent with a caveat that strips it of authority: this token may unlock, but not between 11pm and 6am, not for more than one door, and not after Friday. That is exactly the object the home agent needs and exactly the object MCP does not issue. Instead we got ERC-20 allowances: a single integer, no scope, no expiry, no context, and a user base trained by a decade of habit to approve infinity. Session keys improved the ergonomics without fixing the semantics. A session key that can call any function on any contract is an allowance with better marketing. Then there is the problem nobody wants to write about, which is that physical actions do not roll back. Software agents mostly do. You revoke an API call, you reverse a transaction, you replay from a checkpoint. A door that opened has opened. My audit work on DAO treasury modules taught me to think in terms of transaction semantics — preconditions, atomicity, rollback, dispute windows — and the moment you apply that lens to a hallway, the approval card stops looking like a UX compromise and starts looking like a missing primitive. It is a manual stand-in for the thing we never built: an execution layer with finality guarantees appropriate to the medium. The crypto-native answer would be optimistic execution with a challenge window and a bonded agent that gets slashed if the action is disputed. Elegant on paper. Broken on contact with a porch. A lock needs to resolve in three hundred milliseconds; a challenge window needs ten minutes to be economically meaningful. You cannot bolt cryptographic finality onto a hinge. The honest engineering conclusion is that irreversible physical actions need pre-commitment, not post-hoc adjudication — the decision has to be constrained before it executes, because after it executes there is nothing left to arbitrate. That's a mandate problem, not a consensus problem. Biometrics are where the compliance math gets ugly, and where the industry's silence is loudest. A household face recognition system stores biometric templates, which under GDPR Article 9 are special category data requiring explicit consent; the household exemption evaporates the moment a template leaves the device for a cloud. Illinois BIPA has produced consumer class actions in the hundreds of millions on far less. The commonly cited cap of six registered users is usually framed as a product limitation. It isn't. It's a false-accept/false-reject engineering tradeoff that happens to land exactly on the boundary of what a vendor can defend in a deposition. The privacy-preserving alternative — proving membership in a household set without revealing the template — is well understood in zero-knowledge circles. It is also, per-action, still too expensive to run on every doorbell press. Proving costs have come down, but not to the level where a consumer device can afford a proof per event, and anyone claiming otherwise is pricing hardware they haven't shipped. Now the vacuum that actually blocks commercialization: liability. If the agent misunlocks, misbuys, or misidentifies a visitor, who pays? The model provider, the platform, the device vendor, or the user who clicked? No document I have read answers this, and the omission is structural rather than accidental. No liability allocation means no insurance product; no insurance product means no institutional deployment; no institutional deployment means the whole category stays a demo. The approval card, seen this way, is not friction. It's a signature. Someone clicked, therefore someone is liable. It's an ECDSA signature with a human being behind the key, and it exists because we never built the bonded-agent alternative that would let the system absorb the risk instead. And then there is the part the entire discourse skips, which is power inside the household. Who gets to be one of the six registered users? Is the housekeeper on the list, or is she a guest account with degraded rights? What happens when the person who controls the registry is the person everyone else needs protection from? Elder guardianship, coercive control, a tenant whose landlord owns the lock firmware — these are not exotic edge cases. They are the default failure mode of any access control system that has never modeled adversarial relationships among its legitimate users. DAOs spent years discovering that voter eligibility is a security surface, not an onboarding form. The smart home industry has not had that conversation yet. Here is the bear-market version of all this, since that's the world we're actually trading in. Agent infrastructure is one of the few categories where you can measure something real: authorization calls served, mandates issued, revocations executed, disputes resolved. Most of the tokens in this narrative have none of those numbers, and the ones bleeding liquidity are the ones whose only usage metric is the token itself. Liquidity isn't depth on a screen; it's the confidence that you can leave. Apply that test to any agent-authorization protocol you're holding and watch how many of them fail it — because if you can't exit a position, you were never in a market, you were in a queue. So here's the contrarian turn, and I'll take it against my own instinct. The crypto-native answer to home agent authorization is, right now, worse than the platform veto it's meant to replace. Session keys are a UX catastrophe for anyone who isn't already fluent in hex. Revocation is philosophically beautiful and operationally useless once the deadbolt has turned. On-chain governance adds latency to decisions that need to resolve before a stranger reaches the porch. And the identity layer we'd propose — DIDs, verifiable credentials, on-chain attestations — solves a fragmentation problem by introducing a coordination problem, which is the classic trade in our industry and usually the wrong one. Freedom isn't the absence of a gate. It's the presence of consent — recorded, scoped, and revocable. The platforms are shipping gates. At least they're honest about it. We're shipping consent theater with a proving cost attached. What I'd actually expect, and what I'd watch for, is a hybrid nobody is marketing yet: a local-first execution path where the lock resolves on-device in milliseconds, wrapped in a cloud-issued, attenuable capability credential that was scoped in advance, logged for audit, and revocable in one call — with a bonded liability pool behind it so the vendor has somewhere to put the risk other than a disclaimer. Matter and Thread already provide the local control plane. The missing piece is the mandate, and the mandate is the one thing our industry genuinely knows how to build. Identity isn't a login. It's a set of capabilities someone chose to lend you, with an expiry and a way to take them back. The household agent will be the first consumer product where that distinction becomes physical. The question worth asking isn't whether your home agent can pass the autonomy test. It's whether you'd still want it to, once you understood who signed the mandate — and whether you were ever asked.