One tunnel per application. One address realm per owner. By design, no path between them without the owner's authorization.

Enrol once

Each application on the device is a client with its own cryptographic key and its own tunnel to the service — a per-application tunnel. Each tunnel terminates in its own isolated per-client routing domain inside the service.

Identity is the key. Addresses can change; identity does not. The design lets a device whose address changes keep its enrolment (shown in emulation only).

When a device is enrolled, its tenant can present a licence identifier; it is validated and recorded before the device's addresses are assigned, and a licence already held by another device is refused. The service keeps a record for each device: the owners it is authorized to reach, its address inside each, and the owner hosts it can reach there. Access to another owner is added when the device's tenant requests it and that owner approves, and can be revoked without disturbing the device's other paths. Whenever the record changes, the service notifies the device over its own tunnel, and the device fetches its updated addresses.

Owners decide

Each owner's network is an owner address realm with its own isolated place inside the service. A tenant requests access for a client; the design allows only the owner to authorize it. The service operator cannot authorize access.

• Authorizations. An authorization connects one client's routing domain to one owner's address realm. Without one, the design creates no path between them.
• NAT binding policy. For hosts on its side that the service has not seen before, each owner chooses dynamic, approval-gated, or static-only bindings.
• Revocation. When access is revoked, it is removed and checked before it is recorded as revoked.
• Operator limits. The operator can tighten an owner's policy but not loosen it, and cannot create NAT bindings on the owner's side. Every operator action is recorded.

Owners and tenants act through a mutual-TLS API and an owner portal. Decisions are made under certificate identity; a name in a message is not treated as an identity.

Addresses stop colliding

The service keeps its own private address realm. Every address in it is unique within the service. Translation happens as packets enter and leave the service, on both source and destination addresses, in both directions.

• Owner hosts. Each owner realm has its own place in the service's address realm, and each host in it receives a unique service address — when the host is first seen in traffic from that owner's gateway, within the ranges the owner declared (dynamic policy); after the owner approves it; or by static configuration. The packet that reveals a new host is dropped while its address is assigned; traffic flows from the next. Owner A's 192.168.1.10 and owner B's 192.168.1.10 are therefore two different addresses inside the service.
• Clients. A client keeps one service address — one IPv4, one IPv6 — across every owner it reaches, and appears inside each owner's network under an address from a small pool that owner chose.
• Which gateway. The service ties every assigned address to its owner gateway. Inbound, it identifies the gateway a packet came from by the gateway's public address; outbound, the packet's service addresses tell it which gateway the packet is for.
• What each end sees. Applications on the device see only service addresses. Hosts in an owner's network see only that owner's private addresses — never the device's identity or its carrier address.

Protocols that carry IP addresses inside their payload are not translated there; applications should address owner hosts by the service addresses they are given.

IPv4 and IPv6. Inside the service, realms and hosts can be IPv4 or IPv6; the carrier side is IPv4. IPv6 is translated exactly as IPv4 is: the service has its own unique local /48 with a pseudo-random global ID, each owner realm gets its own /64 from it, and owner hosts are reached through service addresses there. Owners' IPv6 ranges can therefore duplicate one another without colliding.

Owner's side. The design requires no changes inside an owner's network: the service connects to the owner's existing VPN gateway as a standard peer. The service peers with gateways that speak WireGuard, or IPsec with IKEv2 and a pre-shared key.

Links change; records keep their order

The device carries all traffic on one link at a time. Its link policy fails over from cellular to satellite when the active link stops reaching the service, and returns to the preferred link when it recovers. Each traffic class lists the links it may use: store-and-forward data in a class is held while the active link is not one of them, and sent when it is. Link health is judged by reachability to the service, not by link quality. No command or control traffic class is defined.

Data captured out of coverage is hash-chained and signed on the device at capture, with a key the service does not hold. It is stored on the device and delivered in order when a link returns. The service records the head of each chain as a checkpoint in its own append-only log, and the owner can verify the chain, its signatures and its checkpoints.

Emulation only to date None of this has yet been run over a real cellular or satellite link.

On the device: payload kept apart

An on-board isolation policy blocks clients from reaching each other, the device's router and the flight controller. Every blocked attempt is counted and logged.

Together with the absence of any command or control traffic class, this is designed to keep payload applications off the flight controller. MSL-aaS is not a command-and-control link.

A record that shows its own edits

Every enrolment, authorization, decision, revocation and checkpoint is written to a hash-chained audit log, under the identity that made it. Each owner can read the part of the record that concerns it.

The head of the audit log is time-stamped by an RFC 3161 time-stamping authority, on demand or on a schedule; removing records from before the latest time-stamp is detected. Records written since then are protected by the hash chain alone until the next time-stamp.