Skip to content

Security infrastructure for physical AI

After compromise, what can you trust?

Autonomous machines depend on more than secure code. They rely on shared maps, models, connected services and decisions that can remain affected long after an incident.

Driviny is developing SafeHarbor to investigate those dependencies, verify recovery conditions and help engineering teams understand what can be trusted again.

Explore SafeHarborJoin the Research Pilot

Built for autonomous delivery robots, mobile robot fleets and the next generation of physical AI.

Architecture concept
Illustration of nine robots that depend on a map service, a model registry and fleet control. The map service is compromised. Four robots that consumed it are traced. An independent verifier clears three of them in simulation and one stays unresolved.Model registryMap serviceFleet controlIndependent verifier

01 Normal operation. Robots pull shared maps, models and instructions.

  1. 01

    Secure.

    Understand what was compromised and contain it.

  2. 02

    Verify.

    Check recovery against evidence from an independent source.

  3. 03

    Recover.

    Rebuild the states and caches that depended on it.

  4. 04

    Rejoin.

    Restore capabilities one at a time, only after checks.

The problem

A rollback doesn't erase every consequence.

Modern autonomous systems build decisions from connected data sources. A robot may consume:

  • Navigation maps
  • Shared perception data
  • AI model outputs
  • Firmware or software updates
  • Fleet instructions
  • Cached route plans
  • Remote configuration
  • Local sensor observations

If an upstream dependency is compromised, downstream decisions may remain affected even after that dependency is replaced.

Illustration · one compromised input

  1. Compromised map revision

    Compromised

    A shared map revision is altered upstream.

  2. Updated route data

    Affected

    Route tiles are rebuilt from the altered revision.

  3. Robot decision cache

    Affected

    Robots cache routes computed from those tiles.

  4. Navigation task

    Affected

    Tasks are planned against the cached routes.

  5. Fleet-wide operating consequence

    Affected

    The effect spreads to every machine that used them.

Restarting everything is expensive.

Trusting everything is dangerous.

Teams handle incidents in many different ways. The open question is how to tell, with evidence, which parts of a fleet were touched and which were not.

What is SafeHarbor?

Recovery is a verification problem.

SafeHarbor is a proposed security platform for analysing the relationship between compromised components, dependent robot behaviour and evidence required for restoration.
  1. 01

    Investigate

    Understand the incident and affected technical components.

  2. 02

    Trace

    Explore which data, decisions and robot capabilities depend on compromised sources.

  3. 03

    Verify

    Evaluate recovery evidence against defined requirements.

  4. 04

    Rejoin

    Help determine which capabilities may be candidates for selective restoration.

These are intended capabilities and research architecture. They are not features proven in production.

Introducing RejoinProof

Don't restore what you haven't verified.

RejoinProof investigates a dependency-selective recovery process for autonomous robot systems.

Instead of assuming every component is trustworthy after a reboot or rollback, the proposed method examines which downstream states are affected and what independent checks may be required before individual capabilities are restored.

Read about RejoinProof

Scenario: 100 simulated delivery robots. One compromised shared map revision. Choose a stage.

Shared map revision

Illustrative numbers. 100 simulated robots, not a real fleet.

Before incident

100 simulated robots share one map service.

Each robot pulls map revisions and builds route caches from them. Nothing is known to be wrong yet.

  • 100No incident known

Interactive lab preview

Try the idea on a synthetic fleet.

Pick a compromised upstream node, see what depends on it, then run a simple deterministic revalidation simulation. Everything here runs in your browser on made-up data.

RejoinProof lab preview

Synthetic research demonstration — not a safety-certified recovery system.

1. Select a simulated compromised upstream node

10 downstream nodes are on a dependency path from it.

2. Inspect cached decisions

3 of 5 cached decisions depend on shared map revision: R-01 cached routes, R-02 cached routes, R-03 obstacle priors.

3. Run a deterministic revalidation simulation

Upstream sources

Shared data and services

Robot decision caches

Robot capabilities

Each layer depends on the one above it. Tap a node to inspect its dependencies.

  • Selected as compromised
  • Requires revalidation
  • Replaced (assumed known-good)
  • Verification completed in simulation
  • Dependency unresolved
  • Waiting on unresolved upstream
  • Requires manual review
  • Not on a dependency path

Inspector

R-02 cached routes

Layer:
Robot decision caches
Depends on:
Route tile service, Zone speed policy
Synthetic evidence:
No evidence
Depends on the compromised node?
Yes. Shared map revision → Route tile service → R-02 cached routes

Simulation results

Run the simulation to see which nodes clear in simulation and which stay unresolved.

How the demo finds dependencies

  • The graph is synthetic: 17 made-up nodes in four layers. Each node lists what it depends on.
  • A node is affected when you can reach it by following those links downstream from the node you picked. That is plain graph reachability.
  • The inspector shows one shortest dependency path, so you can see why a cached decision is affected.

How the simulation decides, and what it assumes

  • The compromised node is assumed to be replaced with a known-good version. The demo does not check this.
  • Every node carries an invented evidence label. Independent evidence clears a node in simulation. Self-reported or missing evidence leaves it unresolved. Conflicting evidence goes to manual review.
  • A node cannot clear while anything it depends on is still unresolved.
  • No real verifier runs here. A result in this demo says nothing about the safety of any real robot.

Recovery should be selective

Understand the blast radius. Preserve what remains trustworthy.

Conventional broad recovery (illustration)

  1. Suspected fleet compromise
  2. Large-scale suspension or rebuild
  3. Full-system revalidation

RejoinProof research direction

  1. Incident identified
  2. Dependency graph analysed
  3. Recovery obligations determined
  4. Affected capabilities tested
  5. Selective restoration candidates identified

The goal is to keep what can be shown to be unaffected and to check what cannot. We make no claim that this is faster or cheaper. That needs benchmarks, and we have not run them yet.

CSTP · Cyber-Safety Transition Protocol

A cyber response must respect the physical world.

When a robot encounters a suspected cybersecurity incident, abruptly removing communications or disabling software may affect functions required for safe operation.

CSTP explores ways to coordinate security containment with independently verified physical fallback capabilities.

CSTP is in the research roadmap. It is not a certified vehicle controller. It does not replace emergency-stop systems, manufacturer safety controllers or applicable regulatory requirements.
Suspected compromise
Security dependencies
Physical fallback requirements
Transition verification
Authorised containment or independent safety response
Research concept. Not validated on public roads or commercial vehicles.

Use cases

Designed for machines that move through the world.

  • Autonomous delivery robots

    Investigate shared navigation data, compromised fleet instructions and dependent route decisions.

  • Warehouse mobile robots

    Explore security incidents affecting shared operating maps, task queues and fleet orchestration.

  • Autonomous logistics fleets

    Research selective service recovery where multiple machines depend on connected infrastructure.

  • Robotaxis and future mobility

    Explore long-term integrations for complex autonomous vehicle ecosystems.

Research directions only. No compatibility with any named manufacturer or platform is claimed.

Engineering architecture

Built around evidence, not assumptions.

A proposed public architecture in five layers. Evidence flows up from robots and simulators. Recovery decisions only use what the layers below can support.
  1. 05

    Fleet engineering and security interfaces

    Views and exports for engineering and security teams.

  2. 04

    Recovery obligations and validation

    What must be checked, with which independent evidence, before a capability returns.

  3. 03

    Causal dependency analysis

    Which states, caches and decisions were built from which inputs.

  4. 02

    Software and data provenance

    Which maps, models, firmware and config each machine used, and when.

  5. 01

    Robot / simulator events

    Logs, state changes and incident signals from robots or from simulation.

This is product communication, not a technical specification. Internal methods are not published here.

Security and trust

Security signals are not proof of physical safety.

Three principles shape the research. They are deliberately conservative.
  1. 01

    Independent evidence

    A compromised component should not be the sole source verifying its own recovery.

  2. 02

    Explicit uncertainty

    Missing or contradictory evidence should remain unresolved rather than being silently classified as trustworthy.

  3. 03

    Safety boundaries

    Independent, validated safety systems remain authoritative for physical vehicle control.

Research roadmap

Building toward trustworthy autonomous recovery.

Every stage below is research or planned work. None of it is complete, and we have not set dates.

  1. 01

    Research

    Dependency Lab

    Model robot-to-service and data-to-decision dependencies.

  2. 02

    Research

    Incident Simulation

    Generate synthetic shared-compromise scenarios.

  3. 03

    Planned

    Recovery Verification Research

    Test selective revalidation methods.

  4. 04

    Planned

    Controlled Robotics Pilot

    Explore integration with a willing robotics engineering partner in a controlled environment.

  5. 05

    Planned

    Extended Fleet Integration

    Potential future investigation for larger autonomous fleets.

Built for robotics engineers

A security layer for the teams building autonomy.

Driviny is exploring how robotics developers and security teams can investigate compromise propagation and make recovery decisions with better technical evidence.

Discuss a Research Pilot

Potential integration surfaces

  • ROS 2 research environmentsExploring
  • Robotics simulation platformsExploring
  • Robot fleet management APIsExploring
  • Security monitoring pipelinesExploring
  • Software and model update systemsExploring
  • Robot state and provenance recordsExploring

None of these are built. They are places we expect a research integration could connect.

A future city as a trust networkLine drawing of a city street with delivery robots on the pavement, autonomous vehicles on the road and mobile robots in an industrial yard. Each machine is linked to shared services. One link is marked compromised and two are being verified.Map serviceModel hubFleet operations

Autonomous world 2050 · Concept illustration

When machines run the world, recovery becomes infrastructure.

The next generation of physical AI will depend on interconnected models, sensors, machines and services.

As those systems become more autonomous, security will need to address not only intrusion prevention, but how trust is established again following a compromised dependency.

Driviny is exploring the infrastructure required for that future.

Research pilot and partnerships

Help shape the next layer of autonomous security.

We are looking for robotics teams, security researchers and others who want to work on recovery after compromise. Tell us a little about your work.

  • We only use your details to reply to this enquiry.
  • We do not sell or share your details.
  • Please do not send confidential incident details here.

Prefer email? [email protected]

I am a

Company

Building trust for the autonomous world.

Driviny is an emerging technology initiative focused on autonomous mobility security and recovery. SafeHarbor, RejoinProof, CRVP and CSTP are at the research and development stage.

Driviny started with research on human driver readiness. That work is kept on the earlier research page as a possible future direction. To get in touch, email [email protected].