Quick answerCan the agent proactively adjust a device without being asked, like lowering a thermostat during an away period? Only for devices and actions the customer has explicitly pre-approved for proactive, unprompted control; treat this as a separate, opt-in capability layered on top of the reactive control governance described here, not a default extension of it. What happens if the smart-home platform itself, not the agent, reports an incorrect device state? Fail safe: if the agent cannot get a confident, current status read, it should tell the customer the state is unknown rather than assuming a default and either acting on that assumption or reassuring the customer incorrectly.
Quick answer
Physical-device actuation, unlocking a door, disarming a security system, changing a thermostat, carries a different risk profile than reading or writing financial or scheduling data, because a wrong action has an immediate physical-world consequence with no reversal window. Classify every controllable device by physical-safety severity, require explicit per-device, per-action consent rather than one blanket smart-home authorization, default to read-only or status-check access for anything safety-critical like locks and security systems, and build a mandatory confirmation step for any irreversible or safety-relevant action before the agent executes it.
Why physical-device actuation is a different category than connected accounts
Governance for an AI agent touching a customer's connected bank or calendar account is fundamentally about data access and financial exposure: read the wrong balance, write to the wrong calendar slot, and the damage is informational or financial, both correctable after the fact. A smart lock opened for the wrong person, or a security system disarmed at the wrong moment, has a real-world physical-safety consequence that data-access governance frameworks were never built to address. Treat smart-home and IoT device control as its own governance category, not an extension of the connected-accounts framework, even though both involve a customer granting the agent access to a third-party-connected system.
Classify devices by physical-safety severity before writing any policy
Not every connected device carries the same risk. A smart light bulb or a connected speaker has essentially no safety-critical failure mode; a thermostat sits in the middle, uncomfortable but rarely dangerous if set wrong; a smart lock, garage door, or security system sits at the top, where a wrong action creates a real physical-safety or physical-security exposure. Build the governance tier around this classification rather than a single policy for "smart-home access," and require a materially higher bar of verification and confirmation for anything in the top tier.
Default to read-only for anything safety-critical
For locks, security systems, and garage doors specifically, default the agent's access to status-check only, "is the door currently locked", not actuation, "unlock the door", unless the customer has explicitly and separately granted actuation authority for that specific device, with its own consent flow distinct from whatever blanket smart-home integration permission they granted at setup. Even with actuation authority granted, require a real-time confirmation step, not a pre-authorized standing instruction, before the agent executes an unlock, a disarm, or any other top-tier action.
Designing for the failure and misuse cases
Plan explicitly for two failure modes: a social-engineering attempt where someone convinces the agent they're the legitimate resident and requests a door unlock, the same category of live signal your financial-exploitation red-team program already tests for, applied to this specific action type, and a genuine device malfunction or connectivity failure, where the agent needs to fail safe, defaulting to no action and a clear status message, rather than guessing at the device's current state and acting on that guess. What to require before letting your AI agent write to a customer's financial account sets a useful template for the consent and confirmation architecture, even though the risk category, physical safety rather than financial loss, is different.