Executive security briefing
The trust model, the deployment boundary and the evidence behind each claim, with an engineer present.
Tunnel Sovereign
Communication authority for contested environments.
Tunnel Sovereign gives an organization control of its infrastructure, enrollment, mission relationships and device authority. Message keys stay on authorized endpoints.
Encryption protects the communication. Tunnel Sovereign governs the authority to communicate.
Available for Controlled Evaluation
Review the current assurance and evidence state on Assurance.
System signature: four security domains and the boundary between them
01AUTHORITY
- HOLDS
- Signing key. Decides who may reach whom, in which direction, until when.
- CANNOT
- Cannot derive a payload key. Holds no agreement or decapsulation surface.
02ENDPOINTS
- HOLDS
- Agreement and decapsulation keys. Derive the payload key locally.
- CANNOT
- Cannot issue authority to themselves or to anyone else.
03RELAY
- HOLDS
- Ciphertext, a routing alias, a size and a time.
- CANNOT
- Cannot read content. Never receives the authorization graph.
04OPAQUE CUSTODY
- HOLDS
- The property the three above produce together.
- CANNOT
- No single party can both permit a conversation and read it.
Authorization is a signature. Content confidentiality comes from a key agreement. They are different key roles, on different curves, with different lifetimes, and holding the first can never produce the second.
The authority gap
Encryption protects the message. It does not govern the authority to send it.
Modern systems encrypt well, and this one does not claim otherwise. The separate question is who decides which devices exist, who may reach whom, under which identity, and for how long. In most deployments those decisions are properties of the vendor's platform rather than of the organization using it.
Which device may participate
A credential that works on any handset is a credential an adversary can move.
Who may reach whom
A directory that can be searched is a relationship map someone else can read.
What holds after compromise
A permanent account outlives the operation it was issued for.
Tunnel Messenger is the communication plane. Tunnel Sovereign is the authority plane that governs whether a communication is permitted at all, and it is a separate control plane rather than the messenger renamed. The distinction is set out on Company.
Incident Response Reserve
When your enterprise is compromised, your incident-response communications should not depend on the enterprise being investigated.
A serious incident can place email, identity, messaging, VPN, managed endpoints and collaboration infrastructure inside the boundary being investigated. Tunnel Sovereign supports a separately governed response environment, prepared and exercised before the incident rather than assembled during it.
Installing Tunnel Sovereign does not by itself create failure-domain independence. That property depends on deployment architecture, provisioning, devices and administrative separation, and it is scoped with the customer.
What changes for your organization
The authority moves to you. The content stays out of the infrastructure.
OUTCOME
YOUR ORGANIZATION HOLDS THE AUTHORITY
Enrollment, mission authority and the cryptographic roots sit inside your domain, not with a vendor.
OUTCOME
ADMINISTRATORS HOLD NO PAYLOAD KEYS
The environment that decides who may communicate cannot decrypt what they say. This is a property of the key types, not a setting.
OUTCOME
RELATIONSHIPS ARE MISSION-SCOPED
Authority is issued for a mission and expires with it, instead of accumulating as a permanent contact graph.
OUTCOME
A LOST DEVICE IS WITHDRAWN ON ITS OWN
That device's authority is withdrawn without re-enrolling the operator or rebuilding the organization.
OUTCOME
DEPLOYMENT RUNS IN YOUR INFRASTRUCTURE
Managed to begin, or sovereign infrastructure you operate under your own jurisdiction and audit domain.
The product, in operation
See sovereign communication authority in action.
One authority plane governing Android, iOS and macOS. Tunnel Command grants, limits and withdraws authority, and each endpoint answers on its own screen.
1:43 · Command + endpoints in a controlled deployment · Not the outstanding two-endpoint physical acceptance.
Tunnel Sovereign operates across Android, iOS and macOS. Assurance evidence is platform-specific: physical verification currently covers Device Authority on one Android handset model and the operator ceremony at Command, while physical acceptance of the application path is tracked separately and remains outstanding.
The current platform
One platform for the complete mission communication lifecycle.
Four components under one authority model. What separates them is not packaging: each holds something the others cannot reach.
TUNNEL SOVEREIGN
One platform. One authority model. One bundle format.
Tunnel Mobile
Native mobile
Operator surface. Content sealed on the endpoint, keys held there.
Tunnel Command
Native desktop
Governs authority. Holds no key that can decrypt mission content.
Tunnel Relay
Linux · sovereign infrastructure
Carries sealed traffic. No payload key, no authorization graph.
Secure Core
Shared foundation
Cryptography, identity, authorization, delivery and recovery, used by all three.
PROFILE
Tactical Profile
Operating profile of the same platform
DEPLOYMENT
Sovereign Deployment
Customer operates it and holds the authority
DEPLOYMENT
Managed Deployment
Tunnel-operated, defined operational controls
Command is not a payload relay. Relay is not the policy authority.
Control
Four decisions that belong to the organization.
Each is a separate boundary, with its own enforcement.
Infrastructure
- Controlled by
- You, or Tunnel under a managed agreement
- If held elsewhere
- Traffic transits infrastructure you do not govern
- Enforced by
- Deployment artifact separation at build time
Enrollment
- Controlled by
- Your enrollment authority
- If held elsewhere
- A device you never admitted can exist in the deployment
- Enforced by
- Device-bound credentials
Mission authority
- Controlled by
- You, per mission and per direction
- If held elsewhere
- A relationship you never authorized can form
- Enforced by
- Signed, directional, expiring authority
Message keys
- Controlled by
- Authorized endpoints only
- If held elsewhere
- Someone other than the endpoints can read content
- Enforced by
- Key derivation on the endpoint
EPOCH
Policy epoch
Advances when the rules governing a mission change. Authority issued under an earlier policy no longer applies.
EPOCH
Delivery epoch
Rotates the addressing under which material is carried. Aliases from a previous epoch stop resolving.
EPOCH
Identity epoch
Advances when a device's standing changes, including replacement and withdrawal.
The three advance independently and are always labeled separately, so an operator can tell which one moved.
Under compromise
What holds when something is taken.
A security claim is only useful if it survives a bad day.
Control over who may communicate stays separate from the ability to read what they communicate.
If the relay is seized
Stored traffic is ciphertext and the infrastructure holds no payload decryption key. It never receives the authorization graph, so it cannot reconstruct who could reach whom.
If a device is captured
Its credentials are specific to it and are withdrawn without disturbing the operator’s other devices. Authority is bound to the device it was issued to, so a copy fails elsewhere.
If the network is hostile
Content and mission context stay inside the sealed section. Source address, timing and size remain observable at the network layer.
An adversary holding an unlocked device with content on screen has defeated the cryptography, and a disconnected device cannot apply a revocation it has not received.
Compartmentation
Authority to communicate creates no permanent relationship.
Authority can be constrained by mission context, relationship, capability, device and time. Authorization is directional, bound to the device it was issued to, and expires on its own.
Evidence today
What has been demonstrated, what has been tested, and what has not.
Thirteen properties, each published with the limit that qualifies it. Two carry physical evidence within a stated scope. Three are outstanding and are named rather than omitted.
Physically verified
Demonstrated on real hardware, through the path the property describes. Each one carries the scope that bounds it, because a demonstration on one handset model is not a device compatibility matrix.
- Device identity is hardware-backed and non-exportableOne handset model, on Android. Not a device compatibility matrix, and no equivalent on iOS or macOS.
- Operator authentication by physical security keyProves the operator step. Not a device key, not an organization root, not any payload key.
Verified
Automated, adversarial and structural evidence supports the property on the application's real paths. This is not physical endpoint verification, and it is not independent assessment.
- Authority enforcement on the application's real pathsPhysical two-endpoint acceptance is outstanding, on every platform.
- Directional and per-capability authorityA grant one way leaves the reverse leg unauthorized. Physical pending.
- Queued work is re-authorized before it movesWithdrawn authority stays withdrawn through a later grant. Physical pending.
- Secure Mission Bundle verifies through the authority chainEngine-level. Not application-path physical verification.
- Governance receipts are signed and minimalThe receipt signing key is software-protected in application-private storage. Device Authority uses a separate non-exportable hardware-backed key. Receipts are not hardware-attested.
- Federation between independent organizationsControl plane. The endpoint path for federated traffic is not physically verified. Not a certified cross-domain solution.
- Duress persists before it takes effect, with no in-application undoThe physical gesture and the canary delivery are pending verification. No wipe, destruction, concealment or decoy is performed, by design.
- Authority survives restart and reboot without resurrectingResists restart, reboot, clock rollback and provisioning replay. Not resistance after compromise of the platform's protected application storage.
Outstanding
Named, not omitted. These are the gates that would move application-path properties up the ladder, and none of them is claimed until it exists.
- Reboot persistence demonstrated on handsetsPending the physical acceptance procedure, which is tracked separately from automated and controlled-environment verification.
- Two-endpoint acceptance of the application pathOutstanding on Android, iOS and macOS alike. This is the item that would move application-path properties from VERIFIED to PHYSICALLY VERIFIED.
- Independent external assessmentEvery suite behind this page was written by the implementation's own authors.
EXTERNAL ASSURANCE
Not held, and not in progress.
No independent assessment, penetration test, cryptographic implementation review, certification or government approval is held, and none is in progress. The sequence that would produce them is published, with the stage this program is actually at.
The full register, the platform-by-platform evidence table and the assurance sequence are on Assurance.
The assurance path
External assessment is an engineering gate, not a marketing milestone.
An independent assessor examines a frozen, reproducible baseline. That is the sequence this program follows, and this is the stage it is at.
01 · CURRENT
Internal verification
02
Application and physical acceptance
03
Independent security assessment
04
Remediation and retesting
05
Deployment-specific certification
Current stage: controlled evaluation readiness and internal verification. Independent external assessment and deployment-specific certification remain planned assurance milestones.
Beyond Tunnel
One authority model. Multiple communication transports.
Tunnel Sovereign governs its own communication plane today. The gateway extends that authority beyond it, and the transport never gains the decision.
In development
Delivered
Tunnel Native
Messaging, files and native voice and video, governed end to end today.
In development
Collaboration
Channels an organization already runs.
In developmentEmail
Correspondence under the same grant.
In development
External voice and video
Approved third-party real-time media.
Tunnel-native voice and video are part of the current platform. The Governed Communications Gateway extends the same authority model to approved external transports.
Controlled Evaluation applies to the native Tunnel authority platform.
The transport may change. The authority does not.
How engagement works
From a first briefing to a deployment you operate.
Each step ends with a decision and a written output.
Controlled evaluation
Your devices, your compartments, your network conditions, under written scope and success criteria.
Technical and security review
Your architects examine the trust boundary and the evidence directly.
Commercial scope
Deployment posture, operator population and the terms that govern them.
Managed or sovereign deployment
Tunnel-operated to begin, or infrastructure you operate under your own jurisdiction.
Expansion
Additional compartments, operators and postures inside the same authority model.
Executive briefing
A technical review, conducted under your constraints.
The briefing covers the trust model, the deployment boundary and the evidence behind each claim, with an engineer present.