Abstract
A modern robot is a software supply chain on legs. Its behavior may depend on firmware, drivers, ROS packages, perception models, agent frameworks, prompts, policies, configuration and cloud services. Updating any one of these components can change what the machine can perceive or do. Traditional endpoint inventory is therefore insufficient: the control plane needs to know which artifact was approved, which was deployed and whether the runtime still matches.
This note proposes a desired-state architecture combining artifact identity, cryptographic digests, provenance metadata, deployment approvals, robot-reported state and audit evidence. The goal is not to claim that a hash proves software is safe. A hash proves identity of an artifact; governance must still decide whether that artifact should be trusted and deployed.
1. The robot software bill of materials
A robot AI bill of materials should include the components that materially affect autonomy and perception, not only traditional packages. The minimum inventory can include models, agent runtimes, perception pipelines, middleware components, safety-related policy configuration and the firmware/OS boundary relevant to the deployment.
Name, version, publisher and immutable digest.
Repository, build pipeline, approval source and signer.
Capability, data access and potential physical consequence.
Allowed robot class, site, role and environment.
The version the management plane expects to be installed.
The version/digest the robot says it is actually running.
2. Desired state versus reported state
The core security control is a comparison. The control plane records an approved desired state. The robot edge agent reports its observed state. A mismatch becomes an operational event rather than a hidden configuration drift.
The response to a mismatch should depend on risk. A low-risk package may create an alert. A high-risk perception or autonomy component may cause the robot’s enterprise credentials or integrations to be quarantined until the state is reviewed.
3. Cryptographic evidence
Cryptography can make the chain of evidence harder to falsify. Artifact digests bind approvals to exact bytes. Digital signatures can identify an authorized publisher or deployment approver. Hash-linked audit records can expose later tampering with management history. Hardware-backed keys or attestation can strengthen claims about where evidence originated.
4. Zero Trust for robot software
A Zero Trust approach assumes that network location alone does not make a robot or software package trustworthy. Sensitive enterprise access can require a current robot identity, acceptable passport status, approved software state and recent edge evidence. Long-lived credentials should be minimized and high-risk privileges should be revocable without physically recovering the robot first.
5. Rollback and recovery
Software governance is incomplete without a safe recovery path. Every production rollout should define the previous known-good state, rollback conditions, evidence retained before rollback and the person or service authorized to initiate it. The robot’s safety controller remains independent; the management plane governs the software lifecycle around it.
6. Toward chain-style provenance
Each artifact, approval, deployment and runtime report can form an ordered evidence history. The first implementation can be a centralized signed and hash-linked ledger. Later, selected checkpoints can be committed to a transparency service or independent witness network. A public blockchain is optional: it becomes relevant only when multiple parties need a shared anti-tamper anchor without relying on one operator.
7. Research direction
Further work should explore standardized robot AI manifests, SBOM/model-BOM convergence, in-toto/SLSA-style provenance for robotics pipelines, remote attestation for edge runtimes, secure over-the-air deployment patterns and policy languages that can express robot-specific constraints such as location, task, health and human supervision.