Tunnel Command

Where the organization exercises authority, and only authority.

Tunnel Command is the native environment in which an organization governs its own communication: who is enrolled, which devices are trusted, which missions exist, who may communicate with whom, and when that permission ends. It governs the authorization structure the customer created. It is not a window into what people say.

  • Native desktop
  • Customer-controlled
  • No content access
  • Signed distribution

Functions

What an administrator does here

Command exists so that the answer to 'who decided this person may communicate?' is a record inside the customer's own domain.

01

Organization administration

Roles, separation of duties and the administrative boundaries that determine who may exercise which authority.
02

Operator enrollment

Bringing people into the deployment under the organization's own authority, with an auditable record of who authorized it.
03

Device enrollment and replacement

Binding a device to an operator, and replacing a device without re-establishing the operator's standing.
04

Mission and compartment administration

Creating missions, defining compartments and setting the operational boundaries within which communication is permitted.
05

Communication-authority issuance

Issuing directional, capability-scoped, time-limited authority for a specific operational context.
06

Device revocation

Withdrawing a device's authority independently of the operator's other devices.
07

Credential expiration

Authority that ends on its own, so that permission is not something the organization has to remember to remove.
08

Policy and transport policy

Which capabilities are enabled, which transports are permitted and under what conditions communication may be carried.
09

Relay administration

Configuring custody behavior, priority classes, retention and expiration enforcement on the relay infrastructure the organization operates or subscribes to.
10

Controlled audit review

Reviewing the administrative record of who issued, changed or withdrew authority, and when, within the customer's own audit domain.
11

Incident coordination

Acting on a lost device, a compromised operator or a mission that must be closed, and confirming that the action took effect.
12

Signed software and policy distribution

Distributing signed application builds and signed policy under the organization's control, including where the deployment is offline.

The boundary

Command governs communication. It does not read it.

This is the invariant the whole architecture is built to hold. The mission authority signs assertions about who may communicate. It holds a signing key, and a signing key cannot produce a key agreement.

  • The mission authority holds an Ed25519 signing key. It has no key-agreement or decapsulation surface at all.
  • Payload keys are derived on the endpoints from an X25519 agreement combined with an ML-KEM-768 encapsulation. The issuer of an authorization contributes no input to that derivation.
  • Adding a signed authorization to a bundle changes what a relay may refuse to carry. It never changes what a relay may read.
  • No administrator, Command instance or operator of the platform gains a plaintext capability by issuing or enforcing authority.

The authority that permits communication does not possess the keys required to decrypt communication.

Authority model

Permission is scoped, directional and finite.

Authority in Tunnel is issued for a mission, in a direction, for a capability, for a period. Nothing about it is ambient, and nothing about it is permanent by default.

Mission-scoped communication authorityAn operator holds a separate mission-scoped pseudonymous identity in each mission. Authority to communicate is directional and issued per edge: authority to reach one counterpart in one mission does not create authority to reach a different counterpart, or the same counterpart in a different mission. Each device learns only its own edges, never the mission topology.MISSION AOperatorpseudonym A-1Counterpartpseudonym A-2two directional grantsexpires with the missionMISSION BSame operatorpseudonym B-1Counterpartpseudonym B-4one directional grantno reply authority issuedThe same person in two missions is two unrelated operational identities.Neither mission's authority carries into the other.The mission authority signs who may communicate. It holds no key-agreement material and cannot derive payload keys.
Authorization is scoped to a mission, a direction, a capability and a validity window. It expires on its own, and it can be revoked.

Accountability

Customer-controlled, and therefore answerable to the customer.

In a sovereign deployment the administrative record lives in the customer's own audit domain. The organization does not have to ask a vendor what its own administrators did.

How Mobile, Command and Relay relateTunnel Command issues signed authority to devices: enrollment, mission membership and communication authority. Tunnel Mobile encrypts content on the endpoint and hands sealed bundles to Tunnel Relay. Relay carries and delivers bundles without holding payload decryption keys. Command does not receive message content and holds no payload keys.Tunnel CommandMission and device authoritysigned authoritysigned authorityTunnel MobileSender endpointTunnel MobileRecipient endpointTunnel RelaySealed custodySECURE MISSION BUNDLE · SEALED IN TRANSITPayload keys are derived on the endpoints only. No Command instance or relay contributes key material.
Authority flows down from Command. Content flows across between endpoints. The two paths do not meet: the authority that permits communication does not possess the keys required to decrypt it.

Next step

Walk through Command with your governance model in front of you.

A private briefing covers role separation, mission structure, the authority lifecycle and how the administrative record works in your deployment.

Request a Private BriefingTunnel Relay