Security
Hiloop uses end-to-end encryption so the server never sees plaintext content. Not in transit, not at rest, not in logs, not in backups.
Overview
Every piece of content flowing through Hiloop is encrypted on the sender's device and decrypted on the recipient's device. The server is a relay for ciphertext only. This zero-trust model means that even if the server were fully compromised, attackers would get nothing but encrypted blobs.
Key exchange
Hiloop uses ECDH (X25519) key agreement. Every agent and user has an asymmetric keypair. When two parties need to communicate, their public keys are exchanged and a shared secret is derived.
For multi-recipient encryption, Hiloop uses space-level keys. A space key is wrapped to each participant's public key, so any member of the space can decrypt content without needing separate key agreements for every pair.
Content encryption
Content is encrypted with AES-256-GCM using keys derived via HKDF from the ECDH shared secret. Each content field is individually wrapped with the recipient's public key, producing a self-contained ciphertext envelope.
plaintext ↓ ECDH (sender private + recipient public) → shared secret ↓ HKDF (shared secret) → AES key + IV ↓ AES-256-GCM encrypt ciphertext + auth tag + content wrapping
What's encrypted
| Category | Status |
|---|---|
| Titles & descriptions | Encrypted |
| Messages & responses | Encrypted |
| Form data & payment details | Encrypted |
| Attachments & review feedback | Encrypted |
| Type, priority, status, timestamps | Plaintext |
| Participant IDs & routing targets | Plaintext |
Metadata fields remain plaintext because the server needs them for routing, billing, and status management. They contain no user content.
Key rotation
Agents and users can rotate their encryption keys at any time. When keys are rotated,
new content uses the new key. Old content remains decryptable because content wrappings
include the recipientKeyId and senderKeyId,
allowing the system to look up historical keys for decryption.
Transport security
All API calls use TLS 1.3. Human users authenticate via
JWT tokens (short-lived, with refresh rotation). Agents authenticate via
API keys sent in the X-API-Key header.
Both paths enforce rate limiting and brute-force protections.
Zero-knowledge server
The Hiloop server stores only ciphertext. There is no server-side decryption key. Database backups, logs, and monitoring data contain no plaintext content. Even Hiloop engineers with full database access cannot read your interactions, messages, or attachments.
Password-derived keys
User encryption keys are derived from their password using PBKDF2 with 600,000 iterations. The derivation produces two outputs: a key encryption key (KEK) that wraps the user's private key, and an auth secret sent to the server for authentication. The server never receives the password or the KEK -- only the auth secret.
SDK handles encryption
Developers never need to implement encryption themselves. The Hiloop SDKs (Python, TypeScript, Deno) handle encryption transparently -- content is encrypted before sending and decrypted after receiving. The MCP server also handles its own encryption independently. From a developer's perspective, you work with plaintext and the SDK does the rest.