Sometime in the last year, the question “should an AI agent be allowed to operate a physical instrument?” quietly changed from a debate into a deployment. Agents now run thermal cyclers, focus lasers, drive robot arms, and re-lock optical cavities at two in the morning. The engineering that made this possible is genuinely impressive: a shared state dictionary that unifies a rig’s devices behind one interface, natural-language reference files that tell an agent what each device measures, what it can adjust, and what limits it enforces, and several “doors” — tool protocols, command lines, code files — through which agents reach the hardware.
What that engineering does not include, by its own account, is an authority model. The published safety story is two-part: the device enforces its physical limits, and a human approves risky actions. Everything between those two — which agent may issue which command to which device, for how long, on whose behalf, and who can prove it afterward — is left to the environment the agent happens to be running in. This essay is about that gap: why it exists, why the two-part story cannot close it, and what the missing piece looks like. It uses the current lab-automation standards as the worked example, but the argument is not about any one of them. It is about the seam that every agent-operated system has, and about the one discipline that closes it.
The problem has a name, and it is old
Every system that lets software act on the world has to answer one question: what may this program do? There are two families of answers. In the first, a program’s authority is whatever its environment happens to grant — the API key in its configuration, the session it inherited, the permissions of the account it runs under. Security researchers call this ambient authority, and it has been recognized as the root cause of a large fraction of all software compromise since the 1970s. The confused-deputy attack, privilege escalation, credential theft, and most of what is now called “supply chain” risk are the same failure in different clothing: a program held more authority than the task required, and something — a bug, an attacker, a prompt injection — used the surplus.
In the second family, authority is explicit: a program may act only through unforgeable tokens it was deliberately handed, each naming exactly what it permits. These are capabilities, and systems built on them have a property the first family cannot have — the authority a program holds is visible, bounded, and never larger than what someone chose to give it.
Agent-operated hardware today lives almost entirely in the first family. An agent that can reach the device layer through any door has, in practice, the authority of that door: whatever the tool server may do, whatever the shell may do, whatever the file system may do. When an agent writes itself a deterministic script and leaves it running overnight — a celebrated and genuinely useful pattern — that script runs with whatever the process had. Nobody attenuated it, because there was nothing to attenuate with. Nobody set an expiry, because access does not expire. And if it does something wrong, the log will say what happened; it will not say under whose authority, because no authority was ever named.
Floors: what the device refuses
The first half of the current safety story is real and necessary. A well-designed instrument enforces limits in firmware: the lid will not exceed its rated temperature, the laser will not exceed its rated power, the arm will not move faster than its joints allow. The reference file that accompanies each device states these limits so an agent can read them. Call these floors — the constraints that come up from the device, that no command can breach, that exist whether or not anyone is watching.
Floors are indispensable and they are structurally incomplete, for a simple reason: a floor cannot tell agents apart. The lid’s maximum temperature is the same for the principal investigator, the overnight script, the summer intern’s experiment, and a prompt-injected agent that has been talked into running someone else’s protocol. Floors bound physics. They say nothing about permission. A device that enforces every floor perfectly will still do exactly what any reachable agent tells it to, up to the floor.
Ceilings: what the agent is allowed
The missing half comes down from the grant. A ceiling is a limit attached to a specific agent’s authority: this agent may command this cycler, using these protocols, at temperatures no higher than this, until Friday, with the grant revocable at any moment by the person who issued it. Ceilings distinguish agents. They are what a lab director actually means when they say “the overnight run is allowed” — not “the lid may reach 110 degrees” (that is the floor) but “this run may go to 95, and only this run, and only tonight.”
The permitted envelope for any action is the intersection: below the ceiling the grant set, above the floor the device enforces. Neither layer can express the other’s half. Floors cannot be made agent-specific without turning the firmware into an access-control system it was never designed to be. Ceilings cannot stop physics; a grant that forbids 120 degrees does nothing if the firmware would allow it and the grant is bypassed. The safety statement for an agent-operated device is complete only when both halves are present — and today, in most deployments, only one is.
Why the two-part story cannot close the gap
“The device enforces floors, and a human approves risky actions” sounds complete. It fails in three places.
First, human approval is a ceiling that expires the moment it is given. An approval is a decision at a point in time; what runs afterward runs on the authority of the environment, not of the approval. There is no artifact that carries the approval’s scope forward, narrows it for the sub-task, or withdraws it at midnight.
Second, the doors multiply the surface. A tool-protocol server can be given a scope; a command line cannot; a code file that an agent wrote and scheduled has the permissions of wherever it runs. Whatever discipline exists at one door is bypassed at the next. Any authority model that does not govern all doors governs none of them, because an agent — or an attacker — will use the ungoverned one.
Third, there is no receipt. When something goes wrong at 2 a.m., the questions that matter are: which agent acted, under what authority, derived from which grant, and was that grant still valid? Logs answer the first. Nothing answers the rest, because the rest was never recorded, because it was never represented.
The missing piece: a reference monitor with receipts
The fix is a structural pattern with a fifty-year pedigree — the reference monitor — applied at a specific place: the actuation surface.
A reference monitor is a component through which every access to a protected resource must pass, which cannot be bypassed, and which is small enough to be verified. In agent-operated hardware, the protected resource is the device layer’s write surface: the point where a command becomes a change in the physical world. The pattern says: one component owns that surface, every door terminates at it rather than passing through it, and it admits a command only when the command arrives with a capability that permits it.
The word “owns” is doing real work. It is not enough to place a checker beside a shared-memory dictionary that any process can map; that checker is decoration. The dictionary must stop being shared: it lives in the monitor’s private memory, the device drivers run inside the monitor’s trust boundary, and the doors receive a client interface where every request carries its authority. The same transition that turned shared database files into database servers — nobody bypasses a server’s permission checks by editing its pages, because the pages are not reachable — is the transition agent-operated hardware needs. How strongly “private” holds is a ladder: ordinary process isolation, then mandatory access control and sandboxes so that agent-authored scripts have no system path to the instrument except the monitor’s interface, then network segmentation so the monitor is the only host with a leg on the instrument network, and eventually verification in the device firmware itself. Each rung shrinks what must be trusted. None of them requires the instrument to change.
Once every door terminates at the monitor, three properties make ceilings real:
Attenuation. A capability can be delegated only narrower. The director holds authority over the lab; the agent’s session receives a slice; the overnight script receives a smaller slice still — one protocol, one device, one invocation. The invariant is simple to state and mechanically checkable: the authority that comes out of a delegation is a subset of the authority that went in. The 2 a.m. script cannot hold more than it was handed, because holding more is not representable.
Expiry and revocation. A capability carries its own lifetime and can be withdrawn. “Until Friday” is a property of the grant, not a calendar reminder. When a grant is revoked, the monitor refuses the next command — in seconds, not at the next audit.
Receipts before actuation. Before the monitor lets a command reach the device, it records who acted, under what capability, derived from which grant, expiring when — as a signed, attributable, tamper-evident record. A refusal is typed: it names the missing authority rather than failing silently. The log no longer says only what happened; it says what was permitted, by whom, and whether the permission was valid at that moment.
With those three in place, the human-approval workflow does not disappear — it becomes a grant ceremony. The director’s “yes” produces a capability with a scope, a lifetime, and a receipt, instead of a message in a chat channel that the environment promptly forgets.
The second seam: the driver supply chain
There is a quieter place where the same discipline is needed, and it is created by the very feature that makes agent-operated hardware attractive. Agents are now good at writing device drivers: point one at an undocumented instrument and it will probe, learn, and emit a driver plus a description. Multiply that across a community and the result is a registry of thousands of drivers — privileged code that speaks directly to lasers, pumps, and cyclers — much of it written by agents, some of it modified since.
A driver is an executable artifact with authority. The questions are the same as for the agent that uses it: who signed this, what may it touch, can I install it with less than everything? The answers are the same too — signed provenance, authority injected at load time rather than inherited from the host, and the four-gate rule for native code that any serious plugin system applies. The driver factory is a genuine advance. Without artifact discipline it is also the fastest way ever devised to distribute privileged code with no provenance at all.
What this is not
This is not an argument against agent-operated hardware; the deployments are real, the science is real, and the productivity is real. It is not an argument for slowing them down. And it is not an argument that floors are insufficient — floors are the half of the safety story that already works. It is an argument that the other half is missing, that human approval cannot substitute for it, and that the missing half has a known shape: a reference monitor at the actuation surface, capabilities that attenuate, expire, and revoke, and receipts before every physical act.
The standards for agent-operated hardware are young, and their authors have said plainly that the authority model is on the roadmap. That is the right time to say what the model needs to be — before the convenient default arrives. The convenient default is always the same one: an access token, inherited by every door, with the permissions of whoever set it up. The industry has run that experiment for fifty years on software. It should not run it again on lasers.
PolyCap is Affectron’s authority substrate: capabilities that attenuate, expire, and are receipted, on a wire that runs on ordinary MQTT 5. This essay describes the discipline, not the product; the discipline is older than either.