Skip to content

Driviny SafeHarbor · Proposed platform

Know what to trust again after an incident.

Driviny SafeHarbor is a proposed security platform exploring how autonomous systems can identify affected dependencies, determine recovery obligations, perform targeted verification and selectively restore capabilities.

SafeHarbor is under development. Nothing described here is a shipped product.

Join the Research PilotExplore RejoinProof
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.

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.

Potential capabilities

What SafeHarbor is designed to explore.

These are research areas for the platform. Some may change or be dropped as the research moves on.
  • 01

    Cybersecurity incident investigation

    Bring incident signals and technical context into one view of what happened.

  • 02

    Robot-state dependency analysis

    Map which robot states were built from which inputs.

  • 03

    Software and data lineage

    Explore where compromised software, maps or models travelled.

  • 04

    Recovery simulation

    Try recovery plans on synthetic or simulated fleets first.

  • 05

    Security-to-safety transition analysis

    Study how containment steps interact with physical fallback needs.

  • 06

    Selective capability revalidation

    Check capabilities one by one instead of all or nothing.

  • 07

    Fleet recovery visibility

    See which machines are affected, cleared or still unresolved.

  • 08

    Incident replay and recovery evidence

    Keep a record of what was checked, how and with what result.

How the pieces fit

One platform, one research module, two proposed protocols.

Driviny
The company and technology brand.
SafeHarbor
The proposed autonomous security and recovery platform.
RejoinProof
The first research module inside SafeHarbor. It studies which capabilities and dependent states need revalidation after an incident.
CRVP and CSTP
CRVP, Causal Recovery Verification Protocol, is a proposed interface for recording recovery dependencies, revalidation obligations and restoration evidence. CSTP is a separate future research direction. Neither is an adopted standard.

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.

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 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