Should robotics programmes treat AI safety and cybersecurity as separate disciplines?

Why Robotics Programmes Should Treat Safety and Cybersecurity as One Operating Problem

Robotics programmes should not split ai safety from cybersecurity into separate silos, because the same system can fail by accident or be steered by an adversary. The practical boundary is not “safety versus security”, it is whether the robot’s sensing, planning, control and update paths can be trusted under both fault and attack conditions. Once digital inputs can change physical motion, the disciplines converge.

That convergence matters most in the layers where a robot forms beliefs and takes action. A sensor spoof, a poisoned model update, a compromised API, or an abused operator account can all produce unsafe movement, but the response is different only at the last step, not at the level of system design. The security question is whether the trust chain into perception and actuation is controlled well enough to preserve the safety case.

Robotics teams therefore need to think in terms of assumptions, not labels. Safety engineering still owns fail-safe behavior, hazard analysis, and graceful degradation. Cybersecurity owns authenticity, integrity, authorization, and monitoring for the components that feed the robot decisions. When those responsibilities are separated too sharply, the team can certify a safe machine on paper while leaving the actual decision path open to manipulation.

That is why the security programme has to cover the robot’s external dependencies, including remote management channels, software updates, telemetry pipelines, and third-party integrations. A robot that behaves safely when isolated may still become hazardous if an attacker can alter inputs, issue commands, or replace the logic that mediates action. For a broader operating view, NHIMG’s AI Governance Guide is useful where robotics programmes need governance, roles, and oversight rather than only technical controls.

Where the Safety Case Breaks First

The failure mode is usually not a dramatic “AI gone wrong” event. It is a normal-looking control flow that has been quietly contaminated: a false perception, a tampered input, a compromised credential, or a tool call that now has more authority than it should. In robotics, that can turn a minor integrity issue into a physical hazard because the output is not a text answer, it is motion, force, or state change in the real world.

Adversaries are attracted to this convergence because they do not need to defeat the entire robot, only the trust boundary that influences it. If the robot accepts remote commands, external perception data, or model artifacts from systems that are not strongly authenticated and monitored, an attacker can create unsafe behavior without touching the mechanical subsystem. NHIMG’s Microsoft Azure OpenAI abuse by Storm-2139 shows how leaked API keys can be used to bypass guardrails and turn an AI service into an abuse platform.

There is also a governance failure mode. If safety teams only review mechanical hazards and AI teams only review model behavior, nobody may own the combined path from digital manipulation to physical impact. That is the gap that makes robotics programmes vulnerable to “safe in test, unsafe in deployment” outcomes, especially when the robot depends on external software, cloud services, or remotely updated policy logic. For threat-oriented AI testing, the MITRE ATLAS adversarial AI threat matrix helps teams reason about manipulation, poisoning, and tool abuse as attack paths rather than abstract model risk.

What a Unified Robotics Control Model Should Look Like

The right operating model is a shared control view of the robot, not two parallel assurance tracks. Safety cases should identify the physical hazards, while cybersecurity reviews should map the digital trust relationships that can alter perception, planning, control, or maintenance. If a digital pathway can change robot behavior, it belongs inside the assurance boundary even when the consequence is physical rather than informational.

That means programmes should verify who can change code, who can issue commands, what data the robot trusts, and which dependencies can alter behavior without local operator awareness. It also means treating updates, remote access, and evaluation sandboxes as production-relevant assets, not convenience features. NHIMG’s AI Guardrails and AI Firewalls Guide is relevant where the robot’s decision layer depends on runtime filtering or tool-call checks.

Robotics programmes should also decide how much autonomy is acceptable under degraded or untrusted conditions. The useful question is not whether the robot is “safe” or “secure” in the abstract, but whether it should stop, slow, request human approval, or enter a constrained mode when inputs, identities, or dependencies lose trust. That is the same design problem whether the failure comes from a bug, a misconfiguration, or active interference.

Practitioner Guidance

What to prioritise: Put the combined sensing-to-actuation path under one assurance owner, even if safety and security teams remain distinct. The first priority is to identify which digital inputs can affect physical output and which of those are externally reachable.

What to verify: Confirm that the robot can prove the integrity of model artifacts, command channels, update sources, and remote administration paths before allowing autonomous action. If that trust cannot be demonstrated, the system should operate in a reduced or supervised mode rather than on a full autonomy assumption.

Decision rule: If a compromise of a digital interface can change the robot’s physical behavior, treat cybersecurity findings as safety findings too, and escalate them into the safety case instead of handling them as separate tickets.

Practitioner takeaway: Robotics programmes should not ask whether safety or cybersecurity owns the problem; they should ask whether any untrusted digital path can still influence motion, because that is where both disciplines become operationally inseparable.

Related resources from NHI Mgmt Group

• Should organisations treat AI safety and cybersecurity governance as separate programmes or one combined risk function?
• Should organisations treat AI model risk and NHI risk as separate programmes?
• Should organisations treat AI model safety and access control as separate problems?
• Should organisations treat AI recovery and identity governance as separate programmes?