MHS Driver and Physical-Agent Safety Evaluation Guide

Quick answer

An MHS driver is ready for a bounded pilot only when you can prove that it identifies the correct physical device, exposes accurate typed state, accepts only authorized commands, enforces deterministic limits, fails safely, supports recovery, and produces evidence an expert can reconstruct.

Anthropic’s research preview says MHS drivers can expose simple read and write primitives, describe physical characteristics in tags, generate a reference file, and enforce stated safety limits. Those mechanisms are useful inputs to a safety case—not a completed safety case.

Evaluate the declaration before the agent

Start with the driver configuration and generated reference, without a model in the loop.

Surface	Required evidence	Reject when
Device identity	Model, serial, location, firmware, interface, owner	Logical identity can bind to an unexpected device
State	Type, unit, range, timestamp, quality, calibration	Missing units, stale values, silent coercion, or ambiguous nulls
Writes	Command, argument schema, preconditions, effect	Generic write can reach an unreviewed actuator
Physical tags	Source, reviewer, version, effective date	Natural-language guidance is ambiguous or unaudited
Limits	Range, rate, sequence, timeout, interlock relation	Limits exist only in a prompt or client description
Recovery	Stop, rollback where physically possible, safe state	Retry may duplicate or compound a physical action

Compare every declared field with the vendor manual, controller configuration, calibration record, wiring or network map, and a direct observed test. A fluent description is not evidence that the driver matches the equipment.

Core safety test matrix

Identity and authorization

• substitute a different device, firmware version, or network endpoint;
• attempt access with an unapproved user, service identity, model, harness, and adapter;
• test cross-site, cross-tenant, and maintenance-mode boundaries;
• prove that the operating agent cannot grant itself wider commands or change safety limits.

Types, units, and boundaries

• send correct values at, below, and above each boundary;
• swap compatible-looking units and test rounding, precision, negative values, NaN, infinity, and overflow;
• test maximum rate of change, repeated writes, unsafe command order, and mutually exclusive operations;
• confirm rejection occurs in deterministic code close to the device.

State and concurrency

• use stale, delayed, duplicated, missing, and out-of-order state;
• let two authorized actors request conflicting commands;
• disconnect during read, validation, write, and acknowledgment;
• restart the agent, adapter, driver, and device controller at each phase.

Physical and environmental failure

• exercise sensor disagreement, calibration drift, obstructed motion, consumable shortage, fixture misalignment, and unexpected resistance with a safe test rig;
• verify that independent interlocks and emergency stops work without the model, network, or MHS service;
• define which conditions halt immediately and which may enter a reviewed recovery path.

Agent and instruction failure

• inject irrelevant, malicious, contradictory, and over-broad instructions;
• remove required context and present misleading device descriptions;
• ask the agent to skip approval, expand limits, suppress logging, or continue after a stop condition;
• test tool errors, partial results, false success, and a generated script that differs from the approved plan.

Keep reasoning outside hard limits

An agent may choose among approved actions, but it should not be the only component deciding whether a physical command is safe. Encode non-negotiable constraints in the driver, controller, or a dedicated policy layer:

• exact device and environment allowlists;
• typed argument schemas and unit conversion;
• state preconditions and command sequencing;
• rate, energy, travel, force, temperature, pressure, and duration bounds;
• approval requirements and separation of duties;
• timeout, safe-state transition, and stop behavior.

If an agent converts exploratory behavior into code, treat the code as a new artifact. Review the diff, pin dependencies, run static and dynamic checks, test it against recorded fixtures and simulation, then execute on a bounded physical rig with supervision.

Evidence pack for an accountable pilot

Keep a compact, versioned record for every accepted workflow:

1. device identity, configuration, calibration, environment, and responsible owner;
2. driver and reference-file version plus reviewed source material;
3. threat, hazard, and misuse analysis;
4. command allowlist, limits, interlocks, approvals, and stop path;
5. test cases, expected results, actual results, anomalies, and remediation;
6. model, harness, MCP/CLI/API adapter, prompts, tools, policies, and generated code versions;
7. operator training, incident response, recovery, rollback, and revalidation triggers;
8. signed approval for the exact device and workflow scope.

Passing a checklist does not transfer accountability to Anthropic, the model, or the protocol. The organization operating the equipment still owns safety, security, compliance, scientific validity, and the decision to continue.

Use the MHS versus MCP architecture guide to place these controls, the MHS preview guide to verify current lifecycle claims, and the MHS readiness check to score the evidence boundary locally.

Frequently asked questions

Do MHS driver safety limits replace hardware interlocks?

No. Treat driver limits as one defense layer. Preserve independent physical interlocks, controller protections, emergency stops, operating procedures, and expert authority that remain effective if the agent or driver fails.

What is the first MHS driver test?

Verify that the logical driver is bound to the intended physical device, firmware, calibration state, location, units, and safe operating envelope before testing any write.

Should an agent be allowed to change its own limits?

No. Safety-limit changes should use a separate authenticated configuration workflow with review, versioning, change evidence, rollback, and approval independent of the operating agent.

Can simulation certify an MHS deployment?

No. Simulation and digital twins help test logic and failure cases, but real hardware introduces timing, calibration, wear, environment, vendor-controller, and physical-interaction risks that require bounded supervised validation.

Official source

• Anthropic: Previewing the Model Hardware Standard
• Model Hardware Standard: preview access and project origin

Source check: August 29, 2026. This guide is an evaluation framework, not a certification or substitute for device-vendor requirements, qualified safety engineering, scientific review, or applicable law.