When Anthropic previewed the Model Hardware Standard on 27 August 2026, the detail that should stop an engineer mid-scroll is not that an AI agent can now drive a microscope. It is how the agent is told what the microscope can survive. The MHS driver, in Anthropic’s own words, “contains tags that let the user write this information directly in natural language” — and the user can supply that information “by chatting to an agent that interviews them about their hardware setup.” From those tags the driver “automatically produces a reference file” that the agent then reasons inside.
So the boundary between an agent and a laser powerful enough to destroy the sample under it is, at least in part, a sentence somebody typed. That is not a criticism. It is a genuinely useful engineering artifact, and it solves a real problem — machine characteristics that were previously locked in paper manuals or a senior postdoc’s head are now machine-readable. But agent hardware safety questions get answered badly when a description is mistaken for a control, and the two are different kinds of object with different obligations.
One caveat governs everything below. As of 29 August 2026, MHS is a gated research preview — modelhardwarestandard.com says access “is by application during the preview” — with no public specification, schema, SDK or repository. Every architectural claim here rests on a single vendor narrative that nobody outside the partner list can independently inspect.
The Question Is Not “Is It Safe” — It Is “What Layer Is It”
Functional-safety engineering has a specific meaning for the word control, and it is much narrower than everyday usage. A safety-rated control is a defined safety function, implemented in an architecture chosen to hit an assigned integrity target — a Performance Level under ISO 13849-1, or a Safety Integrity Level under IEC 61508 and IEC 62061 — validated against that target, and independent enough that it still works when the thing it protects against has already gone wrong.
IEC 61508-1:2010, Edition 2.0, published 30 April 2010, is the base publication for this idea. Its scope covers “those aspects to be considered when electrical/electronic/programmable electronic (E/E/PE) systems are used to carry out safety functions.” The operative phrase is carry out. A document that describes a limit does not carry out anything.
That gives a cleaner framing than arguing about whether MHS is “safe”:
- An advisory limit reduces the probability that an agent commands something dangerous.
- A safety-rated control reduces the probability that a dangerous command produces harm.
They compose, and they are both worth having. But only one of them keeps working when the description is blank, stale, or wrong — and notice that the first one sits entirely upstream, inside the reasoning of a system whose own designers describe its behaviour probabilistically.
The One-Line Test
Here is the test worth carrying out of this article and applying to any agent-operated rig:
If the tag were blank, or wrong, would anyone be hurt?
If the answer is yes, the tag was never the safety system. Something else has to be, and that something else has to work whether or not the description exists. If the answer is no — if a wrong tag costs you a ruined sample, a wasted week, a bleached slide — then the tag is doing exactly the job it should, and it is doing it well.
That distinction is not pedantry. It is the entire difference between a productivity feature and a protective device, and they are procured, validated and audited under completely different regimes.
Tags Describe a Device. Hazards Live in an Application.
This is the structural point, and it is the one most likely to be missed.
The ISO 10218 series splits across exactly this seam. ISO 10218-1:2025 covers industrial robots and places requirements on the robot manufacturer — the robot itself is treated as partly completed machinery. ISO 10218-2:2025 covers industrial robot applications and robot cells and places requirements on the integrator: integration, commissioning, operation, maintenance, decommissioning. The 2025 editions cancel and replace the 2011 editions, and ISO’s catalogue describes the main change as incorporating safety requirements for robots intended for collaborative applications — formerly the content of ISO/TS 15066.
(A precision note, because it is repeated carelessly all over the internet: the content of ISO/TS 15066 being folded into the series is not the same claim as that document having been withdrawn. A technical specification is not automatically withdrawn when its content is absorbed. iso.org returns HTTP 403 to automated checks, so treat the catalogue status as unconfirmed and say “incorporated into ISO 10218:2025” rather than “withdrawn.”)
Why two standards instead of one? Because a robot arm has no hazards in the abstract. A six-kilo arm moving slowly in an empty cell is a different risk from the same arm holding a scalpel next to a person’s hand. The hazard is a property of the application, not of the device. That is why Part 2 exists and why it addresses the integrator rather than the manufacturer.
An MHS tag describes a device: this arm weighs X, this laser tops out at Y, this stage travels Z. That is Part 1 territory — genuinely useful, and genuinely not the layer where most hazards are assessed. A device-level description cannot be an application-level safety case, for the same structural reason Part 1 cannot substitute for Part 2.
The terminology change in the 2025 revision makes the same point from another angle: it works in terms of a “collaborative application”, not a “collaborative robot,” because only an actual application can be designed, assessed and validated as collaborative. “Cobot” is a product-marketing word, not a safety category.
Notice How Often the Word “Safety-Rated” Appears
The four recognised collaborative techniques are worth reading closely, because of a qualifier that keeps recurring:
| Technique | What it does |
|---|---|
| Safety-rated monitored stop | The robot halts when a person enters the shared space, and resumes once they leave |
| Hand guiding | The operator moves the robot directly, under defined conditions |
| Speed and separation monitoring | Robot speed scales with measured distance to a person, using safety-rated sensors |
| Power and force limiting | Contact force and pressure stay within defined limits by design, allowing direct contact |
A stop does not become a safety-rated monitored stop because somebody wrote “stop when a person enters” in a config file. It becomes one through rated sensors, a rated architecture, and validation against an integrity target. Two of the four techniques above name safety-rated explicitly, and a third — power and force limiting — specifies “by design,” meaning the limit is a physical property of the machine rather than an instruction given to it.
The US regulator frames it identically. OSHA’s Technical Manual chapter on industrial robots answers human presence by reducing the machine, not by instructing it: during teaching, “robot speeds should be placed at a reduced speed of 10 inches per second (250 mm/second) or less.” Its safeguarding list is physical or sensing — “presence-sensing safeguarding devices; fixed barrier/perimeter guards.” Not one item on that list is a description. (That chapter references the 2011/2012 standards generation, so cite it for the shape of the expectation, not for what the 2025 editions say.)
The Laser Example Protects the Sample, Not the Scientist
Anthropic’s flagship safety illustration comes from HHMI Janelia, where Virginie Ruetten, a scientist in the Ahrens lab, is quoted saying: “MHS enforces device-level safety limits, I don’t need to worry about the agent accidentally using excess laser power, for example, which risks bleaching the fluorescent molecules.”
Read what the harm actually is. Photobleaching is a scientific-integrity failure, not a personnel-injury one. Preventing it is a real, valuable win — ruined samples cost weeks, and a power cap that reliably prevents them is worth having. But presenting that win as evidence about human safety is a category error, and it is an easy one to make because the sentence contains the word “safety” twice.
It is also worth being careful about who is claiming what. That “enforces” sentence is a researcher’s quotation, not an Anthropic engineering specification. Anthropic’s own prose is narrower: the reference file carries “information about a device’s general characteristics, such as what it can measure, what can be adjusted, and what safety limits will be enforced” — a description of what the file documents. Across the announcement, Anthropic makes no claim in either direction about certification or safety-rating. The category is simply not addressed, and the honest sentence is to say so rather than to put a disclaimer in their mouth.
Lasers, incidentally, already have a regime. IEC 60825-1:2014 classifies laser products emitting between 180 nm and 1 mm by hazard level and sets requirements for labelling and protective features. Laser hazard control is a classification-and-engineering-controls discipline, which is precisely the point: the existing layer does not go away because a new descriptive layer arrived above it.
Enforce Where the Model Cannot Reach
The security community reached the same conclusion from a completely different direction, and the convergence is the most transferable idea here.
OWASP’s LLM06:2025 Excessive Agency entry names three root causes — excessive functionality, excessive permissions, and excessive autonomy, the last defined as systems that “lack verification/approval mechanisms before high-impact actions.” Its primary mitigation reads like a machinery-safety principle: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”
Sitting alongside it, OWASP’s LLM01:2025 Prompt Injection entry concedes something that matters enormously once outputs become torque: “it is unclear if there are fool-proof methods of prevention for prompt injection.” Indirect injection — where a model “accepts input from external sources” whose content “alters the behavior of the model” — is a live concern for any agent ingesting instrument logs, protocol documents or vendor files. If untrusted content can reach the reasoning layer, then the reasoning layer is not where a physical limit should be enforced.
Two fields, no shared vocabulary, same conclusion: put the limit somewhere the model cannot argue with it.
There is a supply-chain restatement of this too. The npm worm work on this site landed on the line a signature proves who, never what — origin verification is a closed question with a decision procedure, while intent verification is an open question with none. The physical version: a driver’s tags describe intent, not capability. A tag saying the laser stops at 30 mW is a statement about what should happen. Only the hardware makes it a statement about what can.
What the Evidence Actually Shows So Far
Carnegie Mellon’s reported result is the most safety-adjacent number in the announcement: “We artificially induced six different conditions: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, and active emergency stop. The system correctly blocked all six before any device moved.”
Six for six is a good sign and worth reporting. It is also n = 6 induced conditions, self-administered by the integrating team, published by the vendor. That is a smoke test, not a coverage proof and not an independent audit. No claim in the announcement has been independently replicated outside Anthropic and its named partners.
The same document also records the opposite failure mode, honestly. At Janelia, “Claude often stopped to wait for human confirmation before performing an action it deemed even slightly risky, meaning experiments would sometimes pause overnight while Claude waited for approval.” An advisory layer that is too cautious is a productivity problem; the same mechanism tuned the other way is not a safety guarantee. Both behaviours come from the same probabilistic place.
And Anthropic’s own safety language is explicitly future tense: the company is “developing a physical safety roadmap to further bolster our safeguards policy and enforcement coverage,” and intends to “build safety evaluations and develop best practices” with partners “ahead of making the standard open source.” That is a reasonable position for a research preview. It is not a shipped safety case.
The Layer Model, Written Down
Richard Cook’s How Complex Systems Fail has two theses that apply directly. Thesis 2: high consequences of failure “lead over time to the construction of multiple layers of defense against failure.” Thesis 14: when new technologies are used to eliminate well understood system failures, “they often introduce new pathways to large scale, catastrophic failures.”
The layered reading, then:
- Physical and engineering controls — interlocks, guards, rated stops, force limits, laser classification. Work regardless of software state.
- Safety-rated control systems — defined safety functions at an assigned SIL or PL, validated, independent.
- Application-level risk assessment — ISO 10218-2 territory, owned by the integrator, covering the cell as deployed.
- Downstream authorization — permissions enforced where the model cannot reach, per OWASP LLM06.
- Advisory description — MHS tags and the generated reference file, shaping what the agent is likely to command.
MHS lands at layer 5, and layer 5 is real. It plausibly reduces how often layers 1–4 get tested. What it does not do is reduce how much they are needed — and Cook’s thesis 14 is the standing warning that a new layer which feels like it replaces the ones below it is exactly the kind of change that opens new failure paths.
Worth noting the regulatory direction of travel too. Regulation (EU) 2023/1230 on machinery defines a “safety component” in terms that explicitly include software: “a physical or digital component, including software… which is designed or intended to fulfil a safety function.” Its recitals go further, saying software performing a safety function and placed independently on the market “should be considered a safety component,” and that systems “with a fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions” fall into the high-risk listing. (The regulation’s application date and the exact Annex I item number could not be confirmed from primary text and are deliberately not printed here.) Whether an MHS-style descriptive layer ever counts as a safety component depends entirely on whether anyone claims it fulfils a safety function — which is a good reason for nobody to claim that loosely.
The Honest Summary
The Model Hardware Standard puts physical knowledge that used to live in manuals and people’s heads into a machine-readable place, and lets an agent reason with it. For scientific-integrity risks — the wrong power, the wrong volume, the wrong duration ruining an experiment — that is a strong, useful mechanism, and the reported early results are encouraging.
For hazards that can injure someone, the safety stack that existed before 27 August 2026 is the safety stack that exists now. Nothing in the announcement claims otherwise, and the standards it sits beside are the ones that will still be correct after MHS’s spec, partner list and even its name have changed.
Ask the question that survives every version bump: if the tag were blank or wrong, would anyone be hurt? Build for that answer, not for the description.
Frequently Asked Questions
Does the Model Hardware Standard make an AI agent safe to run lab equipment?
It is not that kind of object. MHS supplies an agent with a natural-language description of a device’s characteristics and limits, which plausibly reduces how often the agent commands something harmful. It does not perform enforcement in the sense functional-safety engineering means, and Anthropic makes no claim about certification or safety-rating in either direction. Whether a rig is safe to run autonomously still depends on the interlocks, rated stops, guards and application-level risk assessment around it.
Is an MHS safety tag the same as a safety-rated control?
No, and the difference is architectural rather than semantic. A safety-rated control is a defined safety function implemented to hit an assigned integrity target — a Performance Level under ISO 13849-1 or a SIL under IEC 61508 — validated against that target and independent enough to work when the thing it protects against has already failed. A tag is a description that shapes an agent’s reasoning. Use the one-line test: if the tag were blank or wrong, would anyone be hurt?
Why does it matter that MHS tags describe a device rather than an application?
Because hazards are properties of applications, not devices. The same robot arm is a different risk in an empty cell than beside a person’s hands. ISO 10218 splits along exactly this seam: Part 1 places requirements on the robot manufacturer, Part 2 on the integrator who builds and commissions the actual cell. A device-level description sits on the Part 1 side and cannot substitute for the application-level assessment Part 2 governs.
Can I download the MHS specification and check this myself?
Not as of 29 August 2026. MHS is a limited research preview with access by application, and there is no public specification, schema, SDK or repository. Anthropic has said it intends to open-source the standard, but nothing is downloadable today — so every architectural claim about MHS, including the ones in this article, rests on a single vendor narrative that cannot be independently inspected.
What is the strongest published evidence about MHS blocking unsafe actions?
Carnegie Mellon’s reported precondition check, which blocked six artificially induced conditions — missing plate, rotated plate, reader busy, disconnected camera, unreachable device and active emergency stop — before any device moved. Six for six is encouraging, and it is also n = 6, self-administered by the integrating team and published by the vendor. No MHS claim has been independently replicated outside Anthropic and its named partners.
Does prompt injection matter for hardware agents?
Yes, and more than for text agents, because the output is physical. OWASP’s LLM01:2025 entry concedes that “it is unclear if there are fool-proof methods of prevention for prompt injection,” and indirect injection through instrument logs, protocol files or vendor documents is a realistic path into an agent’s context. That is the practical argument for OWASP LLM06’s rule: implement authorization in downstream systems rather than relying on the model to decide whether an action is allowed.
📦 Recommended Resources
The primary sources here are the standards themselves, and they are not free — IEC 61508, ISO 10218-1/-2:2025 and IEC 60825-1 are all paid documents. The genuinely free starting points are OSHA’s Technical Manual chapter on industrial robots, the OWASP GenAI entries for LLM01 and LLM06, and Richard Cook’s four-page How Complex Systems Fail. Read those first. These three books are for the layer underneath — the reasoning that makes a standard make sense, rather than the clause numbers.
- Functional Safety: A Straightforward Guide to Applying IEC 61508 and Related Standards by David J. Smith and Kenneth G. L. Simpson — the rung this article leans on hardest and the one our catalogue has least of. If the phrases “Safety Integrity Level,” “safety function” and “proof test interval” are words you can recognise but not yet use precisely, this is the book that fixes that. It is what turns “advisory limit versus safety-rated control” from a slogan into something you can actually assess a design against. Note this is the 2nd edition (2004); a later retitled edition exists as The Safety Critical Systems Handbook, but the ISBN above is the one we verified.
- Engineering a Safer World: Systems Thinking Applied to Safety by Nancy G. Leveson — the argument that safety is an emergent property you can design for, controlled through constraints on system behaviour, rather than a matter of chasing component failure rates. It is the most direct intellectual answer to the question this article circles: what do you actually do when the dangerous thing is an interaction rather than a broken part? Directly relevant to an agent that now closes the loop between reasoning and torque.
- Normal Accidents: Living with High-Risk Technologies by Charles Perrow — the counterweight, and you should read it as one. Perrow’s thesis is that in tightly-coupled, interactively-complex systems, some accidents are structurally inevitable rather than attributable to a single failure. Leveson’s systems-theoretic approach is in part a response to exactly that pessimism. Both are still actively cited, and the disagreement between them is live — which is more useful to you than either author’s conclusion on its own, especially when you are deciding how much to trust a new layer that sits above everything else.
✅ Pro tip: Before any of these, spend ten minutes on Cook’s How Complex Systems Fail. It is free, it is four pages, and thesis 14 — that new technologies introduced to eliminate well-understood failures “often introduce new pathways to large scale, catastrophic failures” — is the single most useful sentence to hold in your head while evaluating an agent-operated rig.