TrustLink

This is not a sales document.

It is a short note for the people who carry responsibility for an intelligence service's operational security — the directors and senior officers who decide what a field officer may carry in their hand, and on whose infrastructure the Agency's most sensitive coordination runs.

It argues one idea in three movements. That the ground has shifted: in an era when a voice, a face, or a document can be manufactured on demand, recognising something as authentic is no longer the same as proving it. That the answer is architectural, not cosmetic — trust that can be demonstrated, on infrastructure the Agency owns end to end. And that a sovereign composition already exists to deliver it, honestly described, including where it is still maturing.

The capability detail, the deployment model, and the assurance posture live in the accompanying Product Brief. This note is for the decision, not the specification.

The ground has shifted.

For two decades, operational security on mobile devices rested on a quiet assumption: that a trained officer, looking at a message, a caller, or an application, could tell the real from the false. Recognition was the last line of defence, and for a long time it held.

It no longer does. The same generative tools that have entered ordinary life have entered the adversary's toolkit. A superior's voice can be cloned from a few seconds of audio. A trusted correspondent's face can be reconstructed in a video call. A phishing lure, once betrayed by clumsy language, now arrives in fluent, context-aware prose. A protected application can be reverse-engineered at a speed that used to require a team and now requires a prompt. The officer who once recognised the fake is now, increasingly, being shown something indistinguishable from the real.

When anything can be manufactured, recognising authenticity is no longer proof of it. The question is no longer "does this look real?" but "can this be proven — cryptographically, and on our own terms?"

There is a second shift, particular to this country and this moment. The wave of intrusions against national systems in recent years turned data sovereignty from an abstraction into a felt institutional wound. For an intelligence service the lesson is sharper still: a capability that depends on a foreign cloud, or routes ciphertext through foreign code, is not merely a commercial dependency. It is an intelligence exposure — a channel the Agency does not control, cannot fully audit, and could one day be denied.

These two shifts compound. The threat environment now demands proof rather than recognition, and the geopolitical environment demands that the proof be generated on infrastructure the nation owns. A solution that answers one but not the other answers neither.

The principle: proof, not recognition.

The response is not a better filter or a longer list of things to be suspicious of. Asking officers to be more vigilant against threats engineered to defeat vigilance is a strategy that fails by design. The response is to move the basis of trust from human recognition to cryptographic proof — and to hold the machinery that generates that proof inside the Agency's own perimeter.

In practice this means a device does not get to assert that it is trustworthy; it must prove it, continuously, to hardware the Agency controls. An application does not carry its own keys and hope they are not extracted; the keys are never present on the device without a live authorisation the Agency issues. A correspondent on the other end of a channel is not trusted because they sound right; they are trusted because the channel itself is bound, cryptographically, to a verified device and an authenticated identity. The human is relieved of a judgement they can no longer reliably make, and the burden is shifted to a system that can.

Sovereignty here is not a badge on a datasheet. It is an architectural property: no foreign cloud in the path, no foreign code in the ciphertext path, and the keys, the audit, and the authority all resident where the Agency can reach them.

This is a demanding standard, and it is worth being plain about why it matters more for an intelligence service than for any commercial buyer. A bank that suffers a breach loses money and reputation, both recoverable. An intelligence service that loses control of its officers' communications, or of the trust anchors on their devices, loses sources, methods, and sometimes lives. The asymmetry justifies an architecture that a commercial buyer might consider excessive: on-premises by default, capable of operating disconnected, with the proof machinery owned outright rather than rented.

The response: a sovereign composition.

TrustLink is the name for that architecture assembled into one deployable whole. It is not a single product but a sovereign composition of two: Sentinel beneath, establishing that a device and the identity on it can be proven and that keys are released only under live authority; and Enclave above, carrying the Agency's command and coordination traffic through channels bound to those proven devices and authenticated identities. Both run inside the Agency's own perimeter, with the key-management authority sovereign and no foreign code in the ciphertext path.

Beneath the device layer, Sentinel treats trust as something re-earned on every launch: hardware attestation gates a zero-trust authentication, which in turn gates the delivery of keys that never rest on the device unprotected. Above it, Enclave carries messaging and coordination with a policy model — allow, step up, restrict to read-only, or block — that maps naturally onto the clearance and command structure an intelligence service already runs. Around both sits the sovereignty posture that makes the composition suitable for this buyer at all: sovereign key management, on-premises deployment, and an architecture designed to be operated without reaching for anything outside the national perimeter.

Two honesties belong in a note like this, because their absence would be its own warning. First, TrustLink's sovereignty claims are architectural and can be demonstrated today; several formal certifications, by contrast, are in progress rather than held, and the honest posture is to lead with the architecture and place the dated certification matrix on the table under NDA. Second, intelligence-specific requirements — formal classification handling, cross-domain rules, air-gapped enclave operation at the highest tiers — are matters to be confirmed against a technical evaluation, not asserted from a brief. A vendor who claims otherwise is telling you something useful about the vendor.

The invitation that follows from this note is not "buy." It is "test." The right next step is a technical architecture briefing and, in time, a proof-of-concept inside a single operational unit — come and try to break it, on your infrastructure, before anything is committed.

The specification, the layer-by-layer architecture, the assurance posture, and the commercial envelope are set out in the accompanying Product Brief. What this note asks for is narrower and more important: agreement on the principle. In this era, for this institution, trust must be proven rather than recognised — and it must be owned.

Owned, proven, and sovereign.

The full capability specification, deployment model, and assurance posture are available in the TrustLink Product Brief and under NDA.

Trust an intelligence service can prove — and own.

TrustLink exists to give an intelligence service two things at once: devices, identities, and communications whose trustworthiness can be proven cryptographically rather than judged by eye, and the assurance that the machinery generating that trust sits inside the national perimeter, under sovereign control.

An intelligence service runs its most sensitive coordination on the same class of devices as everyone else, against adversaries who are better resourced than anyone else. Two pressures now converge on that reality. Generative tools have made a superior's voice, a correspondent's face, and a plausible message cheap to manufacture, so the officer's own recognition can no longer be the last line of defence. And the recent history of intrusions against national systems has made any dependence on foreign cloud or foreign code a live intelligence exposure, not merely a commercial one.

This brief sets out what TrustLink is, the full capability set across its seven integrated areas, how each works, how it deploys, what it does not yet do, and what it costs — written for the technical evaluator who will test the claims, not only the executive who will weigh them.

One sovereign platform for mission collaboration under zero trust.

TrustLink is a sovereign composition delivered as a single Secure Collaboration Platform. Beneath sits Sentinel, establishing that a device and the identity on it can be proven and that keys are released only under live authority. Above sits Enclave, carrying the Agency's command and coordination traffic across channels bound to those proven devices. Around both runs an operational layer for field support and real-time intelligence. All of it is deployed inside the Agency's perimeter, with sovereign key management and no foreign code in the ciphertext path.

Only healthy, verified devices and users can act; everything else is coached, limited, or blocked.

The platform's capabilities are organised into seven integrated areas, each detailed in the sections that follow:

Proof, not recognition.

The organising principle is that authenticity must be proven, not recognised. Where a defence depends on a human — or a heuristic — noticing that something looks wrong, a generative adversary can engineer something that looks right. TrustLink anchors trust in cryptographic proof and controlled key release rather than appearance.

Securing the mobile frontier.

The device is the frontier. Mobile Endpoint Security establishes, continuously, that the handset in an officer's possession is healthy, unmodified, and operating in a trustworthy environment before it is allowed to act.

Twelve layers on Android, eight on iOS.

Beneath the capability view above sits the layered protection architecture. Its defining property is the gating chain: hardware attestation gates a zero-trust authentication, which in turn gates the delivery of keys that never rest on the device without a live authorisation the Agency issues. Each layer is independent and additive; the ordering is the advantage.

The full twelve-layer Android catalogue and the eight-layer iOS profile — the latter built on App Attest / DeviceCheck and Secure Enclave key protection, with the platform's narrower instrumentation surface — are provided in the Sentinel technical documentation under NDA. iOS carries fewer layers by virtue of the platform, not by omission.

App launch to key delivery, in six steps.

Only verified users and devices may access.

Access is never assumed. Every session is re-evaluated against the state of the device, the strength of the authentication, and the risk of the moment, and is continuously re-checked for as long as it lasts.

Know when identities are exposed.

An officer's exposed identifier is an operational liability. Identity Monitor watches for that exposure and turns it directly into a tightening of access — sovereignly, without handing anything to an outside broker.

Pre-click protection against phishing and malware.

The most dangerous moment is the instant before a link is tapped or a file is opened. This layer reaches that moment — analysing what an officer is about to act on, without reaching into private content.

Operational comms with enforced security.

Enclave carries the Agency's messaging and coordination across channels bound to devices Sentinel has proven and identities Zero-Trust Access has authenticated. Confidentiality rests on end-to-end encryption keyed through the sovereign key manager; a channel is never trusted merely because the correspondent sounds or looks right.

Field support with emergency-grade response.

For officers operating away from fixed infrastructure, the platform provides both routine support and a genuine emergency capability — reachable even where connectivity is thin.

The panic capability transmits sensitive location and sensor data by design; its activation model, retention, and authorisation should be configured to the Agency's operational and legal policy during technical scoping.

Empowering field teams with insight and rapid reporting.

Sovereign by architecture — and integrated by design.

For this buyer, sovereignty is the first requirement, not a feature among many. TrustLink's sovereignty is an architectural property that a technical review can verify directly.

A word on certification, stated plainly because its absence would be a warning: TrustLink's sovereignty and architecture claims can be demonstrated today, but several formal certifications are in progress rather than held. The honest posture is to lead on the architectural claims — which a technical evaluation can verify directly — and to place the dated certification matrix on the table under NDA rather than imply badges the platform does not yet carry.

Inside the perimeter, on the Agency's terms.

TrustLink is deployed on-premises, inside the Agency's infrastructure, with the sovereign key manager and control plane resident. Consistent with standard practice for a software platform, the underlying infrastructure — servers, storage, hardware security modules, load balancing, firewalling, and network links — sits with the Agency; Nexilis provides a reference architecture and sizing so the true Year-1 envelope can be planned rather than discovered.

The value case: one sovereign stack against many.

TrustLink is priced as a sovereign tier, and its commercial case rests less on a line-item comparison than on what an Agency would otherwise have to assemble: secure communications, unified endpoint management, mobile threat defence, identity and zero-trust access, duress and crisis tooling, field reporting, and an intelligence feed — six to eight vendors, integrated and audited in-house, most of them foreign. TrustLink delivers those as one integrated, sovereign platform.

On a like-for-like basis the assembled stack runs roughly materially higher than TrustLink — before the unpriced cost and risk of integrating and auditing many foreign vendors inside a sovereign perimeter.

Come and test it — on your infrastructure, before anything is committed.

The right first step is a technical architecture briefing, followed by a proof-of-concept inside a single operational unit. The layer-by-layer specification, the assurance and certification matrix, and the full cost model are available under NDA.