# The One-Way Enclave: A Trust Architecture for Air-Gapped Data Fusion **Project 82 technical white paper — for security architects and technical evaluators** ## Executive summary Data-fusion platforms concentrate value: they pull records out of the systems your organisation trusts least to expose, join them, and put the result in front of operators who act on it. That concentration makes the platform itself the most attractive target on the network — and most platforms respond by asking you to extend trust to them: inbound firewall rules, credential vaults on a central server, agents that will do whatever the server tells them. Project 82 takes the opposite position. The platform is designed so that you do not have to trust its central components with anything they do not strictly need, and so that the compromise of any single component — including the control plane itself — has a bounded, enumerable blast radius. Three invariants carry that position, and this paper examines each in depth: 1. **Remote components speak outbound-only, to exactly one URL, over 443.** Nothing ever connects into your network segments; connector agents traverse forward and TLS-inspecting proxies, and no client certificates or bearer secrets travel on the wire. 2. **Every job is signed.** Work an agent executes is Ed25519-signed by the platform key and addressed to that specific agent's device identity. A compromised control plane cannot mint work, and cannot redirect an agent's output to an unpinned destination. 3. **The enclave never exfiltrates.** In air-gapped deployments the only bridge to the internet is the Airlock, and the Airlock is architecturally import-only: signed bundles of reference data, model artefacts, and platform updates, pulled by the enclave over GET-only mutual TLS. We then walk the full lifecycle that these invariants govern — agent enrolment, the data path from source system to versioned dataset, and controlled writeback — and close with a threat-model walkthrough: what an attacker actually obtains from compromising the control plane, the network path, or a single agent, and why each outcome is contained by design rather than by operational vigilance. ## 1. The problem: fusion platforms invert the trust gradient The systems a data-fusion platform must reach — ERP databases, file shares, OT historians — typically sit in the most restricted segments of a network, behind layers of firewalls that permit no inbound connections. A conventional integration architecture fights that posture: it asks for inbound rules, VPN tunnels, or a credential store on a central server that can log into everything. Each of those concessions moves trust in the wrong direction. The central platform — the component with the largest attack surface, the internet-adjacent one, the one running the most code — accumulates the credentials and the network reachability of every source system it touches. Compromise the centre and you hold the periphery. Project 82's architecture is built to keep the trust gradient pointing the right way: the periphery (agents beside your source systems) holds the sensitive material and verifies everything it is told to do; the centre coordinates but cannot coerce. ## 2. The shape of the system ``` CUSTOMER NETWORKS (no inbound access) SINGLE HOST (or enclave) ┌──────────────────────────────┐ 443 only ┌──────────────────────────────────────┐ │ ERP DB files OT hist │ │ Caddy (TLS, two hostnames) │ │ │ │ │ │ │ ├─ agent plane → control plane │ │ ┌┴────────────┴────────┴─┐ │ outbound WSS │ └─ operator plane → console SPA │ │ │ connector agents │──┼──── one URL ─────►│ │ │ │ (Go static binaries) │ │ │ control plane (API + gateway) │ │ └────────────────────────┘ │ │ engine (runner + query workers) │ └──────────────────────────────┘ │ Postgres (RLS) segment store │ │ │ AIRLOCK (air-gapped installs) │ ingests bundles: reference data, │ ┌──────────────────────────────┐ signed bundles, │ model artefacts, platform updates │ │ the ONLY internet-connected │──enclave pulls,──►│ │ │ box: collect / sign / serve │ GET-only mTLS └──────────────────────────────────────┘ └──────────────────────────────┘ ``` Connector agents are single static binaries installed next to your source systems. The platform itself is a single host (or an enclave built around one): TLS termination, a control plane holding all state of record, a data engine holding versioned datasets, and an operator console. For air-gapped installs, one additional appliance — the Airlock — sits on the connected side and is the sole point of contact with the outside world. ## 3. The three invariants ### 3.1 One URL, outbound only Every remote component of Project 82 — which in practice means every connector agent — makes outbound connections to exactly one URL, on port 443, and accepts no inbound connections of any kind. There are no listening ports on the agent, no inbound firewall rules to request, no VPN or tunnel infrastructure to stand up, and no second endpoint for bulk data (no presigned-URL side channel to punch through your proxy estate). The agent's transport is deliberately proxy-safe: it speaks standard server- authenticated TLS on 443 and survives forward proxies and TLS-inspecting middleboxes. That constraint has a security consequence worth dwelling on: because the platform cannot assume an end-to-end confidential channel through an inspecting proxy, **no secret that matters travels on the wire**. There are no client certificates for the proxy to demand or mishandle, and no long-lived bearer secrets whose interception would yield access. Agent authentication is an application-layer signature protocol (§4), so a network position between agent and platform — even one that terminates TLS — never observes a reusable credential. For your network team the invariant reduces to one allow-list entry: this agent, this one destination, outbound 443. Everything the agent does — control traffic, job delivery, bulk dataset upload — is multiplexed over that single channel. ### 3.2 Signed work The second invariant governs what an agent will do once connected. Every job an agent executes — a sync job, a transform order, a writeback — is signed with the platform's Ed25519 key and addressed to that agent's device identity. Before executing anything, the agent verifies both: the signature over the canonical job payload, and that the job's device id is its own. Signed job payloads also carry an expiry, bounding replay of stale work. The consequence is the one that matters for your threat model: **a compromised control plane cannot make agents do arbitrary things.** The control plane is the delivery channel for jobs, not the authority for them. An attacker who owns the control-plane process but not the platform signing key cannot mint valid jobs, cannot re-address a legitimately signed job to a different agent, and cannot redirect an agent's output to an unpinned destination — the agent only ever speaks to its single pinned URL, and only acts on work signed for it specifically. The same key discipline extends outward: the platform key signs jobs, and an offline release signer signs update artefacts and Airlock bundles. The private halves never leave the control plane and the offline signer respectively. ### 3.3 The enclave never exfiltrates The third invariant is the air-gap posture. In an air-gapped deployment the enclave has exactly one external channel: the Airlock. It is a separate appliance on the connected side that collects, signs, and serves bundles; the enclave pulls from it over mutually-authenticated, pinned TLS, using GET requests only. Bundles are Ed25519-verified before ingest, with a monotonic sequence number defeating replay of old bundles. Where policy demands physical enforcement, the transport can be swapped for a data diode without changing the model. The Airlock is import-only *architecturally*, not by configuration. There is no upload handler to misconfigure, no "export mode" to enable, no reverse path that a policy flag guards. What crosses it inbound is a small, enumerable catalogue: reference datasets (sanctions and PEP lists, GeoNames, currency tables, CVE/KEV feeds for OT customers), on-prem model weights, and signed platform and agent updates. What crosses it outbound is nothing. The same principle governs the platform as a whole: no phone-home, no licence pings, no telemetry, no CDN-loaded assets. Version checks arrive as Airlock bundles like everything else. If your organisation ever requires cross-domain export from the enclave to a lower side, that is deliberately a separate, human-reviewed appliance and approval flow — never the import path run in reverse. ## 4. Agent enrolment and session lifecycle An agent's identity is established once and proven on every connection. **Enrolment (once, over HTTPS).** An operator mints an enrolment token in the console. On the agent host, the agent generates an Ed25519 keypair locally — the private key is created on the host and never leaves it. The agent posts its public key together with the token, and receives back an opaque credential and the platform's public key, which it persists in its local identity file. The token is the only shared secret in the lifecycle, it is operator-issued, and its job ends at enrolment. **Session (every connect, over WSS).** The agent dials its single URL and upgrades to a WebSocket. It presents its credential in a hello, and the platform responds with a nonce challenge; the agent answers by signing the nonce with its private key. Possession of the key — not of anything that travelled on the wire — is what authenticates the session. An observer of the channel, including a TLS-inspecting proxy, sees an opaque credential and a one-time signature over a nonce: nothing replayable, nothing that authenticates a second session. The platform's public key, delivered at enrolment, is what the agent subsequently uses to verify every signed job (§3.2). Enrolment therefore pins both directions of trust in one exchange: the platform learns which key speaks for this device, and the device learns which key is allowed to give it work. ## 5. The data path: extraction at the edge, credentials that never move Project 82's connectors invert the usual credential architecture. **Extraction runs on the agent host**, next to the source system. Source credentials — database logins, API keys for internal services, file-share access — are stored agent-side, in the operating system keystore or an encrypted file, and are referenced *by identifier* in sync jobs. The control plane never stores, transmits, or sees them. A job says "extract from source `s-17` per this spec"; only the agent can resolve `s-17` into an actual login, and only on its own host. This is the trust gradient of §1 made concrete. The component holding your database credentials is a static binary on a host you control, inside the segment where the database already lives, reachable by nothing. The internet-adjacent centre holds references, not secrets. Extracted data returns as **chunked binary segment frames multiplexed over the same single WSS channel** as control traffic — the protocol envelope carries a stream identifier, with stream 0 reserved for control (hello, challenge, jobs, acknowledgements) and numbered streams carrying dataset uploads. Each segment upload is resumable by offset and hash-checked on completion, so flaky links and proxy resets cost retransmission of a chunk, not a dataset. There is no second ingress URL and no presigned-URL side channel: the single-URL guarantee of §3.1 holds for bulk data, not just for signalling. On the platform side, uploaded segments land as immutable, versioned datasets: ordered Parquet segments plus a manifest recording schema, row counts, content hashes, the producing job, and parent versions. Every dataset version is content-hashed and traceable to the signed job that produced it — the integrity story runs end to end, from signed instruction to hashed artefact to queryable lineage. ## 6. Writeback: acting on source systems without handing over the keys A fusion platform that lets operators *act* — flag a record, update a status in the source ERP — creates an obvious hazard: a channel by which the centre executes writes against your systems of record. Project 82 constrains that channel twice over. First, writeback is a signed job like any other: it is subject to the full §3.2 verification — platform signature, device addressing, expiry — before the agent touches anything. Second, and more restrictively, **writeback jobs may only invoke allow-listed statement templates**. Free-form SQL from the server is never executed, under any circumstances. The set of statements an agent will run against a source system is fixed and reviewable in advance; a job selects a template and supplies parameters, and anything outside that set is refused regardless of who signed it. Even an attacker holding the platform signing key — the strongest position in the model — cannot turn the writeback channel into arbitrary SQL execution against your sources. ## 7. Threat-model walkthrough The test of a trust architecture is not whether compromise is impossible but whether each compromise has a boundary you can state in advance. Three positions cover the interesting ground. ### 7.1 The attacker compromises the control plane This is the scenario the architecture is most explicitly built for, because the control plane is the natural crown jewel: internet-adjacent (via the single ingress), rich in state, running the most code. What the attacker gets: the platform's state of record — registry metadata, dataset manifests, ontology definitions, audit rows — and, to the extent the signing key is resident for job signing, potentially the ability to issue signed jobs. That is a serious position, and it is why the surrounding controls exist. But observe what it does *not* yield: - **No source credentials.** They live on agent hosts and were never uploaded (§5). Owning the control plane does not grant a login to a single source system. - **No arbitrary code or SQL on agent hosts.** Jobs are structured: extraction specs against declared sources, and writeback only through pre-agreed statement templates (§6). The job vocabulary itself bounds what even validly signed work can do. - **No redirection of data.** Agents dial one pinned URL and nothing else; there is no job type that changes an agent's destination. Data can be pulled *into* the compromised platform — where tenant row-level security, marking ceilings, and the append-only audit trail still constrain and record access — but agents cannot be turned into exfiltration proxies pointed at attacker infrastructure. - **In an air-gapped install, no exfiltration at all.** The enclave's only external channel is import-only (§3.3). A fully compromised control plane inside the enclave has no route by which to send anything out. If the signing key is *not* resident to the attacker — the compromise is of the process or database but not the key material — the position degrades further: the attacker can read platform state and disrupt scheduling, but cannot issue any valid work at all. ### 7.2 The attacker owns the network path Assume a position between agents and the platform: a malicious proxy, a compromised middlebox, or an inspecting device that terminates TLS. What the attacker gets: traffic visibility (to the extent TLS is terminated) and the ability to drop or delay connections — a denial-of-service position. What they do not get: - **No credentials to steal.** Session authentication is challenge/response over the agent's Ed25519 key; the wire carries an opaque credential and one-time signatures, never a replayable secret (§4). There are no client certificates or bearer tokens to harvest. - **No jobs to forge or tamper with.** Job authenticity is an application-layer signature verified by the agent, independent of transport. A modified job fails verification; an injected one was never signed. - **No sessions to replay.** The per-connect nonce makes each authentication exchange single-use, and job expiries bound the replay of captured work. - **No corrupted data accepted silently.** Segments are content-hashed; tampered uploads fail their checks rather than landing as datasets. The network path is treated as untrusted by construction — which is exactly the assumption a proxy-heavy, inspected enterprise network demands. ### 7.3 The attacker compromises a single agent An agent host compromise is the one position that yields real secrets, and its scope is precisely the point: what the attacker gets is what that host already had. - **That host's source credentials** — the logins the agent held locally for its declared sources. These credentials protected systems adjacent to the compromised host; the attacker in this position could likely reach them anyway. Nothing about the platform aggregated other credentials onto this host. - **That agent's identity key**, usable to authenticate as that one device and upload data attributed to it — a data-poisoning position against that agent's datasets, which immutable versioning, manifest provenance, and lineage make detectable and reversible rather than silent. - **No lateral platform access.** The agent's key signs challenges; it does not sign jobs. A captured agent cannot issue work to other agents, cannot impersonate the platform, and holds no credential valid for any other device. - **No inbound surface to pivot through.** The agent listens on nothing; owning it grants no new network reachability that the host itself did not confer. The blast radius of an agent compromise is, deliberately, the blast radius of the host compromise that enabled it — the platform adds nothing to it. ## 8. Closing: trust as architecture, not assurance Each control described here is structural. The single outbound URL is not a firewall recommendation but the only transport the agent possesses. Job verification is not a policy but a precondition of execution. The Airlock's import-only nature is not a setting but the absence of any export path. Statement-template writeback is not a review process but the limit of the agent's vocabulary. For an evaluator, that distinction is the useful one: these properties can be verified from the design and the protocol contract, and they hold on a bad day — under misconfiguration, under partial compromise, under an operator's mistake — because there is no configuration in which they do not. That is what Project 82 means by a one-way enclave: a platform your most restricted networks can host because the questions that matter — who can reach in, who can order work, what can ever leave — are answered by the architecture itself.