Security & encryption

Helmora keeps agent execution on your machine. When the managed relay is in the path, protocol payloads are encrypted at the endpoints and the relay sees routing metadata and ciphertext.

This page also names the limits. Some of them are unflattering; they are here because a security page that only lists strengths is not a security page.

Local by default

The bridge, your agent credentials, your working directories, and the agents’ own history stay on your machine. The bridge binds loopback only — it does not publish plaintext protocol traffic on your LAN. A same-machine session never leaves the host.

Trust your own machine accordingly: the bridge can reach your local agents, your file system, and your API keys, exactly like the CLIs it drives. Treat it as a developer tool with your permissions, because that is what it is.

The relay, and what it sees

To reach a paired bridge from another network without running your own tunnel, the app uses Helmora’s managed relay. It forwards an opaque envelope.

What the relay cannot do:

Decrypt frames. Payload keys live on the client and the bridge, never on the relay.
Read prompt or message contents out of a valid encrypted envelope.
Accept a user envelope with an empty ciphertext field. Relay-owned presence and reachability control frames are the documented exception.
Route a frame outside the authenticated user’s device map — the signed connection identity must also match the envelope’s sender.

What the relay can still observe: account and device routing identifiers, timing, connection state, and frame sizes. The relay is proprietary and its source is not published.

Cryptography

Session establishment. The app verifies the bridge’s signed prekey against the authenticated bridge device record, then establishes a per-device session using X3DH. A missing or changed bridge identity pin fails closed and requires repair or re-pairing rather than silently downgrading.

Ongoing messages. A Double Ratchet derives per-message keys, and AES-256-GCM authenticates each payload together with its identity and channel binding. Ratchet state is sealed locally on both endpoints. Legacy shared-secret frames are rejected — there is no fallback path to the old scheme.

Implementation. Runtime-neutral TypeScript primitives, using Web Crypto where available and a compatible cryptographic backend on native. Helmora does not claim libsignal interoperability.

Limits we have not closed

The account service is a trusted directory, and it stores operational metadata in plaintext. Specifically: device and agent records; session titles and status lines, which include folder names and todo text; and notification titles and bodies, because push delivery requires them. Your prompts and the agents’ output are not in that set — but the metadata above is real, readable content about what you are working on.
Message padding is not implemented. Frame sizes are visible to the relay and leak some information about message length.
Voice transcription sits outside the encrypted envelope path. It is an optional, separately authenticated call that sends captured audio through the relay to the transcription provider you select. If that matters to you, do not use it.
No independent security assessment. Everything above describes the implementation as it exists. It has not been audited by a third party, and we will say so until it has.

Trust model, stated plainly

Trust your own machine. The bridge runs as you.
Do not entrust payload plaintext to the relay. The encryption is designed so the relay never needs message keys.
Do not trust the network. Cellular, hotel wifi, coworking — frames are encrypted before they leave the device.
Trust the account directory deliberately. It authenticates device records and serves public prekeys. That is a real trust dependency, and the plaintext metadata above lives there.

Related: Architecture for where each piece sits, Remote access for avoiding the relay entirely.