The Hub Never Sees Plaintext

When most MFT vendors say "encrypted," they mean TLS. The connection between your agent and the server is encrypted in transit. The server decrypts at the boundary, reads the payload, stores or forwards it, then re-encrypts for the next hop.

The server sees everything. It has to — because it's responsible for routing.

MFTPlus Phase 1 shipped a different model. The source agent encrypts before the data leaves the machine. The hub relays ciphertext. The destination decrypts. The hub is a dumb pipe: it never holds a key and never sees content.

How the encryption works

Key agreement uses X25519 ECDH. Each transfer session negotiates a shared secret between source and destination agents directly. The hub is not part of that negotiation.

Payload encryption is AES-256-GCM via RustCrypto, streaming. Files are encrypted as they leave the source agent, not after they arrive at the hub. The hub receives and forwards authenticated ciphertext.

This matters for compliance in a specific way. Under SOC 2, HIPAA, and PCI-DSS, the question isn't only whether data is encrypted in transit. It's whether the vendor can access the data at all. "We use TLS" means the vendor's infrastructure sees every file that passes through it. "The hub never sees plaintext" means the vendor is architecturally excluded from the data.

An auditor can review a security policy. They cannot review what a vendor actually does with your files after decryption. Architecture is the answer to that question — not documentation.

Protocol bridging: the shortest path wins

Alongside the encryption work, Phase 1 shipped agent-to-agent direct transfer. Agents attempt a direct connection first. If that fails, they fall through to hub-pipe with 64KB chunked streaming.

No store-and-forward. Data is not written to disk on the hub, even as ciphertext. The hub is a relay, not a staging area.

For most enterprise transfers, direct agent-to-agent means the data never touches the MFTPlus infrastructure at all. Hub fallback exists for network topologies where direct connections aren't possible — NAT, firewalls, isolated segments. When it's used, the hub sees only ciphertext it can't read.

Phase 1 by the numbers

Phase 1 covered protocol bridging, the encryption pipeline, agent model migration (all 4 agents moved to OpenCode multi-provider runtime, 20x token efficiency on common operations), and the ops-lead coordinator that ran the engineering workstream autonomously.

Dispatch, review, merge: the engineering loop ran 11 full cycles without a human in the path. Human review only enters for auth changes, billing, and security decisions. Everything else, the machine runs.

What this means for Phase 2

The encryption and bridging work in Phase 1 is the foundation for the audit chain released in the same period. A transfer that's end-to-end encrypted and never stored in plaintext on the hub still generates a full SHA-256 audit chain. The chain records the transfer without recording the content.

Privacy-preserving audit: you can prove a transfer happened, who initiated it, when, and that the record hasn't been altered — without the audit trail containing the files themselves.

That's the architecture we're building toward. Verifiable transfers where the vendor is not in the trust chain at any point.