Intelligence

Nobody Told the Agent to Use the Camera. It Worked That Out on Its Own.

An engineering team asked a coding agent to run a robot arm data collection job using the top camera and the left gripper camera. It never told the agent which video device was which. The agent built its own investigation, reached a conclusion, and then did the one thing I did not expect. It stopped and asked.

Event analysed: . This analysis was published on 13 August 2026.

When an AI agent independently discovers actions that help it accomplish an objective, do those actions inherit authorization from the original instruction?

No, and a published account from the engineering team at RebelDot is a useful illustration of why. Their instruction to an AI coding agent was to run a robot arm data collection process using the top camera and the left gripper camera. They did not say which video device corresponded to which physical camera. The agent enumerated the video devices, filtered out metadata nodes, captured reference frames, copied the images over SSH, compared what each frame showed, and inferred that the gripper camera which could see the cubes was the left one. None of those intermediate steps were prescribed. It then reported its reasoning and asked the human to confirm before continuing. Capability expanded to fill the gap in the instruction. Authority did not have to expand with it, and in this case a confirmation step stood between the inference and the next action. Updated 28 August 2026: Anthropic's Model Hardware Standard research preview, opened 27 August 2026 as a limited research preview shared with a first group of scientific research labs and advanced manufacturers, gives that argument a concrete, verifiable architecture on the actuator side. A common driver exposes read and write primitives to physical hardware, for example getting or setting a temperature, alongside a device description generated from tags a person or an agent interviewing that person writes in natural language, covering what the device measures, what can be adjusted, and what safety limits will be enforced. Whichever of MHS's three documented paths reaches the device, MCP, a command line, or a generated code file chaining driver commands into its own program, the declared limit is what is actually enforced, not the operator's original instruction. What the preview does not establish is who was entitled to set that limit, whether every route to the same hardware is actually mediated by it, or that a human confirmation one partner describes is an MHS enforced control rather than the model's own caution.

Update, 28 August 2026: on 27 August 2026 Anthropic opened a limited research preview of the Model Hardware Standard, a common driver interface through which an agent can read a sensor value or write an actuator command to lab and manufacturing hardware, with each device's own safety limits enforced at that interface. It is the concrete architecture the sensor and actuator distinction below was written to anticipate. A new section near the end covers what MHS actually specifies, what remains undocumented about who is entitled to set those limits, and why the human confirmation Anthropic's own quantum computing partner describes is not the same thing as a documented MHS approval control. The original analysis below is unchanged.

Two robot arms on a white table. Red and green cubes on the left, a bucket toward the top right, and three USB cameras: one overhead, one on each gripper. The two gripper cameras are the same model, mounted the same way, plugged into the same machine. To the operating system they are just /dev/video0, /dev/video2 and /dev/video4.

The instruction given to the AI coding agent, as the team describes it, was simple: use the top camera and the left gripper camera. Nobody told it which device was which.

This account comes from RebelDot, written up by AI engineer Andrei Voic, describing frames the agent captured on 6 June 2026. It is a first party engineering write up rather than an independently verified report, and I am treating it that way throughout.

What the agent actually did

According to the write up, the agent inspected the available video devices, recognised that the odd numbered entries were metadata nodes, and identified three real camera feeds. It captured reference frames from each feed and copied the images over SSH so it could look at them. When it tried to open all three streams at once, video4 timed out, which the team attributes to a real USB 2.0 bandwidth limit from three uncompressed streams sharing one bus, so the frames were read one at a time.

The overhead view was easy. /dev/video0 showed the whole table, both arms, the cubes on the left, the bucket top right. The gripper cameras were the hard part: two near identical close ups of an orange gripper above the same white table, with metadata that gave nothing away.

So the agent used a landmark. The overhead frame established that the cubes sat on the left side of the table. One gripper camera could see those cubes at the edge of its frame. The other was looking at an emptier stretch of table nearer the bucket. From that, the agent concluded that /dev/video4 was the left gripper camera and /dev/video2 was the right one, which it could ignore for this task.

Then it stopped. It reported what it had inferred and asked whether the left gripper was the one looking at the cubes. Only after confirmation did it proceed.

The team is explicit about what it did not supply. No instruction to take reference photos. No suggestion that the cubes could work as a landmark. No camera map, no spatial description. The agent assembled that investigation itself.

Separating four things that are easy to blur

It is worth being precise here, because the whole point of the story lives in the gaps between these categories.

  • What the human requested. Run the data collection process using the top camera and the left gripper camera.
  • What the agent decided by itself. Enumerate video devices, distinguish real feeds from metadata nodes, capture frames, move them over SSH, look at them, work around a bandwidth timeout by reading one at a time, and reason visually about which physical arm each feed belonged to.
  • What the environment allowed. Shell access on a machine with the cameras attached, plus SSH between that box and wherever the agent was reading the images. That is what made the whole sequence possible, and it existed before the instruction did.
  • What required confirmation. The mapping conclusion, before the agent moved on to the data collection itself.

Notice how much of the middle category is ordinary. Listing devices, copying files, opening images. Every one of those actions is unremarkable in isolation. Together they are a small autonomous investigation that nobody specified and nobody would have thought to authorize individually.

Capability expanded. Authority did not have to.

This is the sentence I keep coming back to. Autonomous reasoning can expand. Authority does not have to expand with it.

The instruction was an objective, not an execution plan. The agent hit a gap between the objective and reality, and instead of failing or asking immediately, it generated a path. That is the behaviour everyone building agents actually wants. It is also the behaviour that makes it impossible to enumerate, in advance, every action the agent will take.

If you cannot enumerate the actions beforehand, then approving the objective cannot be the same as approving the actions. Which raises the question this story is really about: when the agent invents the next step itself, what determines whether that step is allowed to execute?

The part I cannot verify, and it matters

The confirmation step is the most encouraging detail in the whole account, and it is also the one I have the least evidence about.

The write up records that the agent reported its reasoning and asked before continuing. What it does not establish is why it asked. Was that a system enforced gate that the agent could not have passed on its own? Was it a policy in the prompt? Or was it simply how the model behaved on that run, on that day, with that phrasing?

I am not going to guess, because the difference between those answers is the difference between a control and a habit. A control holds when the model changes, when the task is phrased differently, when the run is the thousandth rather than the first. A habit is a property of a sample size of one. Both look identical in a blog post. Only one of them is something you can rely on.

That is not a criticism of the team. They were documenting an interesting engineering moment, not publishing a control audit. But if you are reading this story for reassurance, read that distinction carefully first.

Sensors and actuators are not the same risk

Here is where the physical setting changes the maths.

Everything the agent did in this account was observation. Reading device lists, capturing frames, copying files, looking at pictures. A camera is a sensor. The worst case of a wrong inference at that stage is a wrong conclusion.

A robot arm is an actuator. It changes the world, and the world does not have an undo. The account describes the agent working toward a data collection process involving arms that move physical objects on a physical table. I have no evidence about what arm control the agent did or did not have, and I am not going to imply any. Nothing in the published material describes the agent taking unauthorized control of the arms, and I want to say that plainly because this story would be very easy to sensationalise in that direction.

But the structure is worth naming even when nothing went wrong. An agent that can independently expand its own action set from observation is an agent whose action set could, in a differently configured environment, expand across the line from observing the environment to changing it. The mechanism that decides whether it does is not the model's judgment. It is whatever sits between the decision and the execution.

Why I think this is a better story than a failure would have been

Most of what we cover at Moona Intelligence is what happened after a boundary was missing. An agent reached a production database. An agent followed a path nobody intended. Those stories are useful, but they all argue the same way: something broke, therefore a control was needed.

This one argues forward instead. Nothing broke. The agent was resourceful, the inference was correct, the human was asked, the task proceeded. And the authority question is still there, completely intact, because the agent's competence is exactly what created it. A less capable agent would have stopped at the ambiguous device names and asked immediately. It is the capable one that goes exploring.

Capability is improving quickly. Planning, tool discovery, multimodal reasoning, adaptation to messy environments. Every improvement widens the set of actions an agent can reach without being told. None of it widens, by itself, the set of actions it should be permitted to execute.

Questions I would ask about my own setup

  • Can I list the actions my agent took last week, or only the tasks it completed?
  • Which of those actions did I specify, and which did it generate?
  • What is technically reachable from the credentials and shell access it already holds, independent of what I asked for?
  • When it pauses for approval, is that a gate or a behaviour? Would it still pause if the model were swapped tomorrow?
  • Where exactly is the line between reading state and changing state, and is anything enforcing it?
  • If an inference were wrong, which of the next actions would be reversible?

That last one is the one physical systems answer differently. In software you can usually restore. A gripper that closed on the wrong object has already closed.

An interface for the actuator side arrived

Eleven weeks after the RebelDot account above was published, Anthropic gave the sensor and actuator distinction this piece argued for a name and an interface. On 27 August 2026 it opened what it calls a limited research preview of the Model Hardware Standard, MHS, sharing an early version with a first group of scientific research labs and advanced manufacturers so it can build safety evaluations and deployment practice before, its own material says, open sourcing the standard later. It is not a finished industry standard today, not open source today, not a standards body specification, and not, on anything Anthropic has published, proven safe across the range of hardware it could eventually touch. Reuters and WIRED both covered the announcement on 27 and 28 August 2026, and this record treats that coverage as corroboration of one development, not as separate votes.

The mechanism is a common driver that exposes two kinds of primitive to an agent: a read, Anthropic's own example is getting a temperature, and a write, setting one. Wrapped around that driver is a description of the device the agent is talking to, generated from tags a person writes directly in natural language or produces by being interviewed about their own hardware setup by an agent. That description tells the agent what the device can measure, what can be adjusted, and what safety limits will be enforced. An agent can reach a device through MCP, through a command line interface, or by chaining driver commands together into a code file that then runs as its own program, fast or long running, without the agent reasoning through every step inside it. This record does not assume those three paths carry identical authorization semantics merely because they share one driver underneath; nothing it could verify confirms or denies that they do.

What the safety limit actually is, and what is still undocumented about it

The clearest example in the material this record could verify of what a device level limit is for is illumination: too much light damages a sample, so the limit exists to stop an agent from setting it there by accident. That is a real, verifiable, device level control, and it is the strongest thing in this record's Authority Provenance reading of MHS. It is also narrower than "MHS makes physical actions safe." The limit is enforced by the driver an agent talks to. Nothing this record could verify establishes that every route to the same physical hardware, a vendor's own control software, a device's native API reached directly, another local or network interface, is required to pass through that same driver. The safe reading is that MHS provides device level safety limits for actions executed through the MHS interface, not that it mediates every consequential command a piece of equipment can receive.

The provenance of the limit itself is where this record has to say UNKNOWN more than once. Anthropic's own description establishes that a person, or an agent interviewing that person, writes the tags a device's safety description is generated from. What it does not establish, on anything this record could verify: whether those tags are versioned, whether they are authenticated or signed, whether an agent can modify them once written, whether the enforced numbers are separate structured fields with validated units and ranges or are derived from the natural language description itself, whether a driver vendor can fix a limit a local user cannot weaken, and what happens when a device's own firmware disagrees with what its MHS description says about it. A limit being present and technically enforced is not the same claim as the limit having been set by someone entitled to set it. Moona Intelligence's own reporting on execution authority has made that distinction for credentials and IAM policy. Physical devices are the same argument with a sharper edge, because the thing a wrong number authorizes is not a wrong API call. It is a real light source, a real robot arm, a real chemical volume.

Five accounts, one development

Anthropic's own article describes five partners using MHS during the preview, and this record is deliberate about not turning one company's announcement into five independent market votes. Genentech used it to automate a BCA protein assay, coordinating a liquid handler, a robot arm and a plate reader. The University of Washington's Baker and Pinglay labs used it to supervise a qPCR run, watching amplification curves and halting the procedure at the right moment, to hand plates between a robot arm and a liquid handler without collision, and, by their own account, to connect six instruments in under a week where the equivalent manual integration work had taken months. HHMI Janelia, MHS's original development partner, used it to collapse a two photon microscopy rig that previously meant launching seven separate vendor programs in a fixed sequence down to one, with the agent aligning beams and adapting imaging parameters as the biology under the microscope changed. Tetsuwan integrated MHS into its own automated biology platform to run a qPCR workflow for a citizen science project characterizing pollution in a California creek. Four of these five accounts live inside Anthropic's own announcement. This record treats them as one artifact for evidence purposes, not four.

QuEra is the exception, and the reason is straightforward: QuEra published its own account, separately, of what it built. It used MHS to give an agent control over recovering a laser's lock, the precise frequency its lasers must hold to interact with the atoms in its quantum computer. A team of engineers had previously spent months writing a bespoke recovery script that worked 58 percent of the time in about 150 seconds. The agent developed a controller that QuEra reports recovering the lock in 700 trials at a 99.3 percent success rate, in seconds rather than minutes. What actually runs on the bench today is not the agent reasoning live through each recovery. QuEra's own framing of it: AI driven in development, human orchestrated, autonomous in operation, meaning what executes is a deterministic, fully inspectable program the agent helped write, not the model making a fresh judgment call every time the laser drifts. That distinction, an agent authorizing or generating a procedure against one an agent or a program then executes many times over, is exactly the line this record has been trying to hold since the RebelDot account above.

The pause QuEra describes is not a documented MHS control

QuEra also reports that Claude often stopped and waited overnight for human confirmation before doing anything it judged even slightly risky, a real productivity cost weighed against a real caution. This record is careful about what that sentence does and does not establish, for the same reason it was careful about the RebelDot confirmation step above. QuEra's own account attributes the caution to the model's own limits, not to a system it names as forcing the pause: Claude, as a large language model, learned about the physical world from text and images, and its own spatial and physical reasoning is limited enough that QuEra still wanted expert oversight in the loop. Nothing this record could verify describes MHS itself as defining a standardized approval gate, a class of action it holds for confirmation, or what a human reviewing that confirmation actually sees before deciding. The distinction that matters: human confirmation observed in this pilot, yes. An MHS enforced, action bound human approval control, undocumented. Publishing the first as though it proves the second would overstate what QuEra's own account says.

Where authorization actually attaches

The question RebelDot's cameras opened this record with was where authorization attaches when an agent's own reasoning fills a gap an instruction left open. MHS gives a partial, verifiable answer for the physical case, and the precision is the finding. Authorization does not, on anything documented, attach to the high level experiment a researcher describes, nor separately to each individual primitive an agent issues, nor to a generated script as its own unit. What is actually enforced, as far as this record can verify, is the device's own safety envelope: the range of values a read or write is allowed to fall inside, checked wherever the driver sits between the agent and the hardware. A researcher who tells an agent to optimize a qPCR run or recover a laser lock has authorized that objective. Nothing in MHS's own documented architecture establishes that the same instruction authorized every value inside the envelope the device happens to allow, only that values outside it are the ones the interface is built to refuse. Whether that envelope was set by someone entitled to set it is exactly the question the tag provenance section above leaves open.

Recovery deserves the same care. Anthropic describes agents recovering from device level failures autonomously, and that is a real, useful property of operating a piece of equipment. It is not the same claim as reversing a completed physical consequence. A qPCR run halted at the right moment is a saved sample. A sample that already absorbed too much light, or a chemical transfer that already happened, is not undone by the agent's next successful action. This record's original argument about a robot arm not having an undo, made without a shred of evidence that anything had gone wrong in the RebelDot account, now has a live architecture it can be checked against rather than a hypothetical.

The thing worth keeping

An objective is not authorization for every action discovered while pursuing it. That gap used to be small, because agents could not do much beyond what you spelled out. It is getting larger in exactly the direction we were hoping for, which is the awkward part.

The agent in this account did good work. It also demonstrated, in a completely benign way, that the set of things it will decide to do is no longer something a human enumerates in advance. When the next step is invented by the agent, the only reliable place to answer "is this allowed" is at the moment of execution.

Your agent found a clever way around a problem this week. Do you know what it did?

Sources

This analysis interprets third-party reporting, research and announcements. Moona is not the original reporter of the underlying events.

[1]
When an AI Agent Learned Left From Right From a Camera Feed
RebelDot · Andrei Voic · Company announcement
[2]
SO-101 robot arm documentation
Hugging Face LeRobot · Technical documentation
[3]
SO-ARM100 and SO-101 hardware repository
The Robot Studio · Technical documentation
[4]
Previewing the Model Hardware Standard
Anthropic · 27 August 2026 · Company announcement
[5]
Model Hardware Standard
Anthropic · Technical documentation

Related Intelligence

All Intelligence Records →