When an AI Agent Moves a Machine, What Can the Network Prove?

An AI agent asks a machine to act. A second later, a robot stops, a cell faults, a part is misplaced, or an operator sees behavior nobody expected. The incident question sounds simple: what did the agent do?

The evidence question is harder. A packet capture can preserve a network request, a device exchange, timing, retries, status fields, and the response visible at one observation point. It usually cannot prove what happened inside the model, controller, safety system, drive, actuator, or physical mechanism.

That distinction is not a weakness in packet evidence. It is what makes the evidence trustworthy.

Anthropic's MHS preview makes the evidence question immediate

Anthropic's August 2026 Model–Hardware Standard research preview describes a shared interface through which AI agents can discover and operate programmable instruments. The preview covers laboratory and manufacturing equipment, including liquid handlers, plate readers, microscopes, robotic arms, and other devices. It describes standardized drivers with read and write primitives, device characteristics and limits, plus control through MCP, command-line interfaces, and code APIs.

The examples make the opportunity concrete. An agent can sequence instruments, react to reported state, adjust parameters, and package learned steps into deterministic code. The same examples also expose the boundary this article addresses: reported device state, camera feedback, driver commands, local files, controller behavior, and physical effects may occupy different evidence systems.

MHS is a research preview, not a generally available PacketSafari integration or a formal relationship. PacketSafari does not currently claim MHS compatibility. The preview is relevant because it shows why investigators will need to reconstruct an agent-to-device chronology without pretending that one network capture contains the whole physical event.

The packet record proves observation, not intention

Start with the narrowest defensible statement: these bytes crossed this capture point at this time.

Depending on protocol visibility, the record may also establish:

• source and destination endpoints
• connection and stream relationships
• request and response timing
• decoded methods, services, fields, identifiers, and status values
• retransmissions, gaps, resets, reachability failures, or repair traffic
• whether an expected peer or exchange was absent from the captured boundary

None of those facts proves why the AI agent selected the action. A prompt, plan, tool-selection trace, policy decision, or model output may exist only in application logs. Even when a network request contains a human-readable command, the packet record shows what was transmitted, not whether the model originated it independently, repeated an operator request, or passed through another service's decision.

Use three labels throughout the investigation:

A network-visible command is not proof of movement

Consider a captured service call followed by an OPC UA write. The sequence can support a strong chronology:

09:41:18.208  agent service sends request
09:41:18.224  OPC UA client sends mapped node operation
09:41:18.231  server response carries observed status
09:41:18.410  application reports machine-state change

The first three lines may be packet observations when the relevant payload is decoded. The fourth may come from an application or controller log. Even together they do not automatically prove that the operation caused physical motion.

The missing links can include controller task scheduling, interlocks, safety logic, drive state, fieldbus segments outside the capture, local I/O, mechanical coupling, sensor truth, and operator intervention. Time correlation is useful, but temporal proximity is not a mechanical causal proof.

The appropriate conclusion might be: “The captured OPC UA operation preceded the reported movement by 179 ms and received the observed status. The capture does not include the controller-to-drive path, safety state, or independent position evidence.”

That is far more useful than either “the AI moved the robot” or “the network is innocent.”

OPC UA can add meaning, but only where the mapping is known

OPC UA is important for robotics because it combines network communication with an information model. The official OPC UA for Robotics specification describes motion-device systems, controllers, axes, motors, operational data, condition data, and remote-operation concepts.

Stable identifiers and companion models can make a captured NodeId more meaningful. But an investigator must still distinguish four situations:

1. the NodeId and value are decoded, and an authoritative model or site mapping gives them meaning
2. the NodeId is decoded, but its operational meaning is not mapped
3. the payload is encrypted or otherwise unavailable
4. the relevant device exchange is outside the capture point

PacketSafari's current OT workflow recognizes OPC UA and can use operator-authored mappings for NodeIds and security policies. It can preserve mapped node evidence, transport and policy fields, selected status flags, coverage, and packet pivots where those facts are exposed. It does not currently claim a complete generic OPC UA service chronology, session reconstruction, request/response pairing, or OPC UA Robotics companion-model interpretation.

That boundary matters. A protocol name in a capture is not the same thing as qualified semantic depth.

DDS and RTPS reveal communication mechanics before application meaning

ROS 2 commonly relies on a middleware implementation beneath its client libraries. The official ROS 2 internal-interface documentation explains that the underlying DDS or RTPS implementation handles discovery, publish and subscribe mechanics, request-reply mechanics, and serialization.

At the network layer, a qualified RTPS investigation could answer questions about participants, discovery, locators, writers and readers, sequence behavior, acknowledgements, repair, fragmentation, and timing. Those are valuable questions when a robot disappears from discovery, a subscriber misses data, or delivery becomes unstable.

They still do not reveal the physical meaning of an opaque serialized sample without the matching type information and application context. A sequence gap is not automatically a missed actuator command. Repair traffic is not automatically a machine fault. A visible participant is not automatically authorized.

PacketSafari does not currently market qualified robotics-specific DDS/RTPS discovery, topic, QoS, sequence, or repair triage. Current evaluation should treat decoder-visible packet fields and surrounding IP, UDP, timing, and infrastructure evidence as case-specific inputs, not as a claim of full ROS 2 support.

MHS and agent protocols create another evidence boundary

An agent-to-device architecture may include a model, orchestration service, tool protocol, gateway, middleware, controller, and machine. Some legs may be ordinary network traffic. Others may never touch a capturable interface.

The MHS preview names MCP, command-line interfaces, and code files as control mechanisms. Those mechanisms do not create one uniform packet trail. The official Model Context Protocol transport specification defines stdio and Streamable HTTP transports. Streamable HTTP may create network-visible request and response evidence at the right capture point. Local stdio does not. Command files, shared memory, USB, serial, device-internal buses, and embedded control loops create similar blind spots.

This is why “MCP-compatible” or “agent-aware” cannot be inferred from observing generic HTTP. It requires a qualified decoder, stable identifiers, representative traffic, and an acceptance question. PacketSafari does not claim current MHS compatibility, and a network capture cannot recover local control activity that never crossed the observed interface.

Build the investigation around transitions

A useful robotics incident timeline follows changes in responsibility and trust:

The earliest divergence is often more useful than the loudest error. If the agent request never left the service, start there. If the gateway transmitted the expected operation but the controller rejected it, move ownership to that boundary. If every captured exchange completed and the fault appeared later, stop blaming the observed network without additional evidence.

Capture at ownership boundaries

One PCAP rarely sees the entire path. Before reproducing the event:

1. Write the acceptance question in operational language.
2. Draw the agent, service, gateway, controller, robot, safety, and external-system path.
3. Mark which legs use Ethernet or IP and which are local, serial, fieldbus, shared-memory, or internal.
4. Choose capture points where ownership changes.
5. Record interfaces, clock source, filters, snap length, drops, encryption, and time synchronization.
6. Capture a successful comparison run when possible.
7. Preserve the controller, safety, application, and operator records needed to corroborate physical claims.

Passive capture does not make the investigation a safety procedure. Reproduction, control actions, and access to production systems remain under authorized operational and safety processes.

Four honest outcomes

A reviewable investigation should finish with one of four outcomes:

• Network evidence supports a cause. A reproducible captured sequence explains the communication failure inside the observed boundary.
• Network evidence supports a contribution. Loss, timing, discovery, reachability, or protocol behavior contributed, but another subsystem remains involved.
• No captured network fault. The relevant exchange completed within view, moving the next check to software, controller, safety, or physical evidence.
• Inconclusive. The decisive direction, payload, mapping, time window, or capture point is missing, encrypted, unsupported, or outside view.

“No captured network fault” is not “the network is perfect.” “Inconclusive” is not a failure. Both prevent the team from turning absent evidence into a confident story.

What PacketSafari contributes today

PacketSafari investigates supplied captures after the event. Its deterministic Core Engine and Triage workflow prepare protocol, connection, timing, anomaly, coverage, and exact packet evidence. Agent can investigate a bounded question and explain the evidence, while Verification and the later Final Report remain distinct milestones.

For robotics and automation cases today, the defensible product scope is:

• correlate supported OPC UA and surrounding network evidence with exact packet pivots
• apply operator-authored OT mappings where the site can supply authoritative semantics
• investigate transport, infrastructure, remote-access, identity, and security evidence around the event
• keep protocol coverage, mapping coverage, encryption, capture gaps, and unsupported depth visible
• hand controls, robotics, network, OEM, integrator, and safety teams one reviewable chronology

PacketSafari is not a continuous OT monitor, robot data platform, controller, safety system, MHS integration, or proof of physical root cause. Robotics-specific DDS/RTPS depth and richer OPC UA service or companion-model interpretation require representative captures and explicit qualification before they become product claims.

The Robotics Network Investigation use case provides the evaluation boundary and capture plan. It sits under PacketSafari's broader Industrial and OT work because the customer job is still bounded, passive packet investigation: establish what crossed the network, where the evidence diverged, and which team owns the next check.

The network is a witness, not the whole scene

When an AI-operated system affects the physical world, the temptation is to make one evidence source explain everything. Network packets should not be asked to do that.

Use them for what they do exceptionally well: preserve an independent, timestamped record of observed communication. Join that record to agent traces, application logs, controller state, safety records, device diagnostics, and physical measurements. Keep every inference labelled.

Then the final report can say exactly what the network proved, what another source corroborated, and what remains unknown. That is the standard an AI-operated physical system deserves.