Before you let an agent touch something physical

Almost everything an AI agent has ever done to you was reversible. It wrote a bad draft and you deleted it. It pushed a wrong commit and you reverted it. It sent an email you would not have sent, and that one stung, but the damage was social, not structural. Your habits were built on that assumption. You let it run, you skim the output, you fix what it got wrong afterwards.

Devices break the assumption. A model that can set a temperature, unlock a door, or start a motor produces consequences that do not have an undo button, and the software layer that lets it do so is arriving faster than most operators have thought about it. This guide is for a solo operator or a small team that owns something physical and networked: a 3D printer, a laser cutter, smart locks on a rental you manage, a climate controller in a storeroom, a bench instrument in a two-person lab. If everything you own is a laptop and a phone, skip this one. If you run a certified production line and already employ a safety engineer, you have a compliance process and this is not a substitute for it.

Physical access reduces to read and write

On 27 August 2026 Anthropic opened a research preview of the Model Hardware Standard, described as “a shared specification for AI agents to safely operate physical devices” [1]. The design is deliberately small. Instead of a bespoke integration per instrument, “the MHS driver uses a simple set of primitives—commands like ‘read’ (for example, ‘get temperature’) or ‘write’ (for example, ‘set temperature’)—that any hardware device can understand and act on” [1]. It “works with any device that has a programmable interface”, it is model-agnostic, and “any agent harness can access it using standard protocols, such as the Model Context Protocol” [1].

That is the whole vocabulary. Read the state of a thing, or change the state of a thing. Which means the permission question you face is one you have already answered a hundred times for software: this key can read, that key can write, and the difference is the entire security model. An agent with a read scope on a temperature probe is a monitoring tool. The same agent with a write scope on the heater attached to that probe is something else.

So the first piece of work is a list, and it is boring. Write down every device on your network that accepts a command from software. Next to each one, write “read” or “read and write”, meaning what the agent is actually allowed to do, not what the device is capable of. Most equipment on that list needs read only. A printer that reports its own status, a sensor that reports a number, a camera that returns a still: an agent can do useful work with all of those and cannot break any of them.

A physical write has no rollback

Anthropic is unusually plain about the limitation in its own announcement: “As a large language model, Claude learns about the physical world through text and images, meaning its spatial and physical reasoning have limitations that still require expert oversight” [1]. The example it publishes comes from Genentech, where bubbles formed during liquid handling. “When it encountered runtime errors caused by bubbles during mixing, Claude’s default instinct was simply to retry the operation in the same plate well with different parameters. But this only agitated the fluid further and created more bubbles” [1]. What fixed it was a person supplying the physics. Once Claude was told the error came from bubbles and that it had to move to a clean well and reduce the number of mixing cycles, “it maintained that context for the rest of the run” [1].

Notice what makes that story survivable. The failure was cheap, it was visible, and a trained person was standing there. Take away any one of those and the same class of mistake stops being a research anecdote. The model was not lying and it was not malfunctioning. It was reasoning about a fluid it has only ever read about, and it got the physics wrong in a way that looked, from inside the text, entirely reasonable.

Sort your devices by what one wrong write costs. The first group is annoying: a lamp, a fan, a speaker. The second group is expensive: a printer mid-job, a kiln, a compressor, anything with a consumable or a duty cycle. The third group is unsafe or irreversible: locks, heaters, water valves, anything with a blade or a motor that can trap a hand, and anything that opens your premises to a person who is not you. Grant an unattended agent write access to the first group if you like. Require a human confirmation on the second. Do not wire the third to an agent at all until you have a specific reason and a way to stop it that does not depend on software.

Standardisation is why this arrives sooner than you planned

The reason to think about this now rather than in two years is that the integration cost, which has been the natural brake on the whole idea, is the exact thing being removed. Anthropic’s framing of the problem: “It typically takes a lab or manufacturing facility weeks, if not months, to set up and integrate their hardware” [1]. Their Carnegie Mellon result: “The time from raw, non-automated equipment readiness to a completed dilution curve, including one autonomous rerun, was eight hours. By contrast, engaging a vendor to deliver a working automated setup typically takes multiple weeks” [1].

One result from one lab is not a trend, and it is worth treating it as a vendor’s own best case. The signal that matters more is who signed up to build against it. On the research side: Genentech, the University of Washington Baker and Pinglay labs, Carnegie Mellon University, HHMI Janelia, QuEra Computing and Tetsuwan Scientific. On the industry side, named as adding MHS integration: Amazon Web Services with Strands Robots, Automata, Danaher, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan, Universal Robots, Hugging Face and Raspberry Pi [1]. Lab-automation vendors and a robot-arm manufacturer do not commit engineering time to a specification unless they expect customers to ask for it.

None of this is available to you today. The preview is open to “a first group of scientific research labs and advanced manufacturers” [1], and Anthropic says it is “developing a physical safety roadmap to further bolster our safeguards policy and enforcement coverage against the risk of misuse” [1], with findings from the preview to be published as guidance for deploying the standard safely before MHS is open-sourced [1]. Read that as the honest version: the standard is not finished, and the safety guidance for deploying it is being written alongside the deployments rather than before them.

Expose the shortest list of devices that does the job

You do not have to wait for a hardware standard to face this, because the consumer version already shipped. Home Assistant publishes an integration that “enables using Home Assistant to provide context for MCP (Model Context Protocol) LLM Client Applications”, so Claude or ChatGPT can query and control the house [5]. The design decision worth copying is the one about scope: “Clients can only control or provide information about entities that are exposed to it” [5]. Nothing is reachable until you put it on a list.

The reason for that default is stated bluntly in the same project’s documentation. You must expose entities deliberately, and the rationale is “to avoid that sensitive devices, such as locks and garage doors, can inadvertently be controlled by voice commands” [6]. Whoever wrote that sentence had already imagined the failure. Adopt the same posture whatever your stack is: an allow-list of specific devices, not a category, not a room, not everything the integration can see.

The protocol’s own security guidance says the same thing in security language. Its section on scope minimisation warns of an “expanded blast radius” when a stolen broad token “enables unrelated tool/resource access”, lists “Using wildcard or omnibus scopes (*, all, full-access)” among the common mistakes, and recommends a “minimal initial scope set” of “only low-risk discovery/read operations” with “incremental elevation” when privileged operations are first attempted [4]. Access to the physical world is the case where that advice stops being hygiene and starts being the difference between a wasted afternoon and a callout.

Two practical settings follow. Home Assistant supports OAuth and, for clients without it, long-lived access tokens, and notes that “Connecting to any API other than Assist requires the authenticated user to be an administrator” [5]; make the agent’s account a limited one rather than your admin login. And keep the per-tool confirmation on. The same documentation notes that “Claude will ask you for permission before calling any tools” [5]. That prompt is the last human checkpoint in the chain, and turning it off to stop the clicking is the single most common way people end up with an agent that acts without them.

Treat everything the agent reads as a possible command

An agent that can write to a device is only as trustworthy as the text it consumes. This is the failure mode people underestimate, because it does not look like a hack. It looks like the agent doing what it was told, by someone who was not you.

The MCP security document describes the mechanism directly. Under session hijacking it walks through an attacker sending a malicious event that a second server enqueues and the first server then delivers, after which “the client receives and acts on the malicious payload, leading to potential compromise” [4]. Under local server compromise it warns clients to flag that “MCP servers run with the same privileges as the client”, and lists an attacker distributing “a malicious payload inside the server itself” or including “a malicious ‘startup’ command in a client configuration” [4]. It recommends executing servers “in a sandboxed environment with minimal default privileges”, launching them “with restricted access to the file system, network, and other system resources”, and using “the stdio transport to limit access to just the MCP client” [4].

Translate that into your setup. The agent that reads your inbox, browses supplier sites, or ingests customer messages should not be the same agent that holds write access to equipment. Untrusted text in, physical action out, with nothing between them, is the arrangement to avoid. If you run one agent for both, you have made every email you receive a potential instruction to your hardware. Separate the two, keep the device-facing server local and authenticated, and log every write with a timestamp so that a wrong action leaves a trail you can read the next morning.

The rules for machines were written before your agent existed

Physical safety is a regulated field, and none of the regulators were waiting for this. In the EU, Regulation (EU) 2023/1230 on machinery was adopted on 14 June 2023 and “applies on a mandatory basis as of 20 January 2027”; machinery placed on the EU market before that date must comply with the current Machinery Directive 2006/42/EC [8]. The regulation’s recitals already anticipate learning systems: recital 54 states that “systems with self-evolving behaviour ensuring safety functions should be included in Annex I due to their characteristics such as data dependency, opacity, autonomy and connectivity, which might considerably increase the probability and severity of harm” [7]. Recital 55 narrows the third-party conformity assessment provisions to “systems with a fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions”, and says they “should not apply to software incapable of learning or evolving, and programmed only to execute certain automated functions” [7]. If your agent is a convenience layer on top of equipment that is already safe without it, that is a different position from an agent that is the safety function. Keep it in the first category.

Vendor policy draws a second line. Anthropic’s Usage Policy, effective 15 September 2025, prohibits using its products to “Facilitate the destruction or disruption of critical infrastructure such as power grids, water treatment facilities, medical devices, telecommunication networks, or air traffic control systems” [2], and for outputs affecting individuals in high-risk domains requires that “a qualified professional in that field must review the content or decision prior to dissemination or finalization” [2]. OpenAI’s usage policies, effective 29 October 2025, prohibit the “automation of high-stakes decisions in sensitive areas without human review”, and the list of sensitive areas explicitly includes critical infrastructure and product safety components [3]. Both are worth reading as design constraints rather than legal boilerplate. If a workflow you are building would need a human in it to comply with the policy, put the human in it now, while the workflow is still small enough to change.

What still goes wrong

The honest state of this in September 2026 is that the standard is a gated preview, the safety guidance for it is still being written by the vendor’s own account [1], and the thing you can actually deploy today is a home-automation bridge that was not designed for equipment that can hurt someone. That gap is where the trouble sits. The easy path is to connect a printer or a lock through a consumer integration because it works, and to inherit none of the review that a lab or a manufacturer would apply to the same action.

Confirmation prompts decay. The first week you read every one. By the third week you approve them the way you approve cookie banners, and an approval you do not read is not a control. There is no clean fix for this, only a partial one: keep the number of confirmable actions small enough that each prompt is still a surprise. If your agent asks you to approve twenty device writes a day, you have already lost the checkpoint, and the answer is fewer exposed devices rather than more attention.

And the model’s physical reasoning remains the weak joint. Anthropic says so about its own system, and points at spatial and physical reasoning as the areas that still require expert oversight [1]. Expert oversight is exactly what a one-person operation does not have on tap. If you do not know what the correct behaviour of a machine looks like well enough to spot a wrong command before it executes, you are not supervising the agent, you are watching it. Those are different jobs, and only one of them is safe to do with equipment that moves.