Concept

The HexaEight approach

Applies to: All SDKs Last updated: 2026-06-11

HexaEight starts from a single cryptographic primitive and builds the rest of the identity and messaging model around it. The result is one identity system that covers users, AI Assistants and Agents, and services; an encryption layer with no certificates; and a built-in authorisation layer that works the same way across all SDKs. The HexaEight platform participates at runtime — primarily to issue per-recipient shared keys (cached after the first call within a 15-minute window) — but never holds plaintext, never issues long-lived bearer tokens, and is not in the data path of the encrypted messages themselves.

The primitive: Dead Drop Encryption

HexaEight is built on a cryptographic primitive called Dead Drop Encryption (DDE). DDE allows two parties who have HexaEight identities to derive a shared encryption key without ever exchanging public keys, without any certificate, and without any prior introduction.

The platform issues each party their half of the shared key at the moment they need to send or receive a message. The two halves are mathematically related so that one decrypts what the other encrypted. Neither half alone is enough to read the message. The platform never sees the plaintext.

Four properties that follow from DDE

1. No certificates

There is no certificate authority, no certificate signing request, no renewal cycle, no certificate revocation list. An agent activates once, receives a credential, and is ready to communicate with any other identity on the platform.

2. No public-key directory

The sender does not need to look up a recipient's public key. The platform issues both halves of the shared key on demand, based on identity name alone. To send a message to [email protected], you address the message to that name; the platform supplies the key material.

3. The platform issues keys, never sees plaintext, never carries messages

The HexaEight platform participates in two places: at activation time (once per machine), and when an identity needs to derive a fresh shared key for a recipient (typically once per 15-minute window per recipient pair; results are cached client-side). The platform never holds plaintext and never carries the encrypted messages themselves — those flow over whatever transport your application chooses (HTTP, message queue, file, ntfy). For sessioned conversations, both sides pin the shared key once and exchange messages thereafter without further platform calls until the session ends.

4. End-to-end encryption is the default

The platform supplies key material but never holds the messages. There is no point at which the platform could decrypt traffic between two identities, even in principle. This property is structural — it is not a feature that can be enabled or disabled.

Identity: users, agents, services — one model

HexaEight has two identity types: user identities (anchored to an email address and the HexaEight Authenticator mobile app) and agent identities (anchored to a hostname and a specific machine). Both are first-class citizens of the platform and use the same cryptographic primitive.

A service is just an agent identity. There is no separate "service account" concept. The same authentication, the same encryption, the same authorisation rules apply.

Read the Identity model page for the details, including how identities are issued, how machines bind to them, and the rules about which identity types can communicate with which.

Authorisation: built in, replaceable, the same everywhere

Every SDK ships with a small authorisation engine. The default engine reads a CSV policy file with rules of the form: 

p, <sender>, <destination>, <realm>, <direction>, <effect>

These rules are evaluated automatically on every message the SDK encrypts or decrypts. The model has four levels of rules (the realm column) to cover increasingly specific cases — default rules, app-specific rules, session-specific rules, and user-specific rules — but for most agents, default-level rules are sufficient.

If you have an existing authorisation system (LDAP, OAuth, OPA, Azure RBAC, AWS IAM), you can replace the built-in engine with your own implementation of a small interface. The rest of the SDK does not change.

Read The authorization model for the design rationale and How-to: Allow a specific sender for a hands-on starting point.

Scaling: the swarm model

Running the same logical agent across many machines (for throughput, redundancy, or geographical distribution) is handled by the SDK's swarm mode. All instances activate under the same identity name on their respective machines and then agree on a shared secret called a Swarm Key.

Once swarm mode is enabled, every instance reads and writes a shared, encrypted policy file at a location the application designates (a network file share, cloud storage). The SDK provides a distributed lock primitive for any other resource the swarm needs to coordinate on (task queues, work distribution, audit logs).

Read The scaling model (swarm) for the details.

What this gives a developer

Concretely, integrating HexaEight removes the following from your application:

What remains is your application code, the SDK, and a single text file of authorisation rules.

See also