governed agent-to-hardware · running in your browser

An AI agent drives a motor. The boundary decides what actually happens.

The agent expresses intent through MCP. Then three layers decide, bottom-up: a policy says who may act, the device clamps to a safe envelope, and a hardware disengage overrides everything below the software path. Authorized does not mean safe.

This motor is simulated and runs in this page as an MCP server. It is the twin of a real 3-phase controller: point a provider at the same slot and the exact same calls drive real hardware. Natural language is never the safety mechanism here.

Policy (who / what / where) Safety envelope (device clamps) Hardware e-stop (physical override)

Three outcomes: authorization denied, safety-refused, completed — Every call below resolves to one of three outcomes. Watch them in the audit log: policy denies, the device refuses on safety, or it completes.

Device · motor-1 (MCP provider)

resource /acme/lyon/assembly/line-3/cell-2/motor-1

CRITICAL OP

E-STOP
ACTUATION
BLOCKED

SPEED

0 rpm

CURRENT

0.0 A

TEMP

24 °C

Hardware e-stop. Latching. Overrides policy and agent. No software path can rearm it.

Critical operation. A cycle that must not be interrupted. While active, the device refuses anything that would halt it, stop and set_speed below the floor alike: safety guards the effect, not the method name. The hardware e-stop still overrides.

resources/read · motor-1/safetyadvisory · non-authoritative

Advisory only. It reports live conditions and the operations the device is currently refusing. Observing a value is never proof the next call is safe: the device re-checks at execution.

Caller · token & controls

edge signal nominal

Speed 600 rpm

Audit log · every call, every decision

Simulated twin of a real controller. The same MCP calls drive real hardware through mcp-broker. Safety limits live in the device and the hardware, never in prompt text.