Built for the Agentic Era

AI agents can't trust each other
Not Anymore...

HexaEight is the future for identity in the agentic era.

Cryptographic identity for AI agents, humans, and IoT devices. Identity replaces API keys at every hop. No PKI. No OAuth. No lock-in.

Your model of choice — Claude, GPT, Gemini, local. Switch anytime; identity stays yours.
Future-proof by design — no quantum-vulnerable key exchange. No certificates, no expiry, no renewals.
Get the app
Download the HexaEight Authenticator.
View pricing
Jump to pricing — three license modes, monthly.
HexaEight's bridge issues cryptographic keys to each party in a secure lab: a human and an AI agent connect directly in an authenticated handshake over a padlock, with other agents and humans present.

Dead Drop Encryption

Encrypt to any identity — no key exchange, no PKI, and the recipient need not be online.

Try it live Get the published research paper →

Authenticated Encryption
Anywhere and Everywhere.

Scroll to explore
For everyone

Just want to sign in?
Get the app.

The HexaEight Authenticator turns your email into a secure identity. Verify once, then scan a QR code to sign in to any HexaEight-connected site or app — or to sign in an AI agent that acts on your behalf. Same code, no per-site passwords, nothing to leak.

  • A free digital token for anyone with a valid email — verify once, use everywhere.
  • One QR code signs you in — to a website, an app, or an AI agent acting for you.
  • Your token is protected by a password only you know — never stored on your phone.
Download on the App Store Get it on Google Play
Get started — the 4-step guide

Free · iOS & Android · by HexaEight

HexaEight Authenticator app: Futuristic Identity — for every human, in the era of intelligent machines.
Who's it for?

Four audiences. One identity layer.

The product is the same in every case. What changes is where it shows up in your stack, and which problem it quietly takes off your plate.

Not building anything? Just want to sign in with the app. Get the app
Quickstart

You can encrypt to an agent
that doesn't exist yet.

We know that sounds wrong. Three lines of code prove it.

1
Activate an identity
hexaeight-activate

Binds the identity to this machine. Creates the env-file your agent uses to authenticate.

2
Bundle the Bridge SDK
@hexaeight/sdk

In your language: .NET and Node.js shipping today. Python in preview, Browser SDK forthcoming. Go, Rust, Java planned.

3
Encrypt to any identity
he.encryptTo(peer, msg, ask)

Derive the key for any destination — even one not yet provisioned. Encrypt. The recipient decrypts with their own password.

agent.js Node.js · Preview
// 1. Load your identity from the env-file.
const he = await HexaEight.connect({ envFile: './env-file' });

// 2. Derive a shared key for any destination identity.
//    Works even if the recipient hasn't been provisioned yet.
const ask = await he.fetchSharedKey('peer.example.com', currentKgt());

// 3. Encrypt. Move the bytes however you like.
const ciphertext = await he.encryptTo('peer.example.com', 'Hello!', ask);

// The recipient runs he.decryptFrom() with their own password.
// HexaEight never sees the plaintext. Transport is your call.
Transport-agnostic. Move ciphertext over HTTP(s), webhooks, MQTT, BLE, WhatsApp, Slack, Discord, Telegram, email, SMS, ntfy, even a USB stick. HexaEight gives you identity and encryption. The wire is your choice.
Read the developer guide
The Identity Crisis No One Talks About.

AI Agent Authentication & Cryptographic Identity, Without PKI, OAuth or Certificates

We Didn't Add AI to Identity.

We Rebuilt Identity for AI.

Experience what Identity looks like in the Future, for a world where agents will outnumber people.

AI Agent
agent01.yourdomain.com

Your domain is your agent's identity, not ours. Encrypt to other agents before they're even deployed. Zero human approval. Authenticates at machine speed.

BYOD Identity
Human User

Your email is your identity. Authenticate using one login token via QR code, protected by your password, unlocks any app on any org without registration.

Passwordless Auth
Machine / IoT
sensor-01.factory.com

Every device gets a permanent hostname-bound identity. One-time credential, no renewals, no expiry. No certificate management overhead at any scale.

Device Identity
Enterprise / Platform
identity.yourcompany.com

Host your own cryptographic identity layer. Self-hosted on-prem or via Marketplace VM. Your domain, your Bridge endpoint, full control over who connects and what they can reach.

Self-Hosted Identity
Powered by HexaEight Dead Drop Encryption. One platform, every identity, any network.
7+ years
Encryption platform in production

A mature, externally-monitored platform — agent identity is its newest application. Check the real uptime yourself →

100%
Autonomous

Agents authenticate themselves, rotate keys, and establish secure channels with zero human involvement.

The Problem

You Gave Your AI Agent a Brain.
Nobody Gave It an Identity.

Your AI Agents Are Talking to Each Other.
Does Either Know Who's on the Other End?

Your Agent Can Reason. Plan. Execute.
It Cannot Prove Who It Is.

You Deployed Autonomous Agents.
Did You Give Them a Way to Prove Their Identity?

OAuth needs a browser. Certificates need a human awake at 3 AM. Neither was built for autonomous agents.

Human User
[email protected]
No way to verify the agent they're talking to. Impersonation is trivial
AI Agent
agent.mycompany.com
Operates in ms. No time for cert handshake
IoT Device
sensor-01.factory.com
Headless device. OAuth needs a browser
Enterprise / Platform
agenticgw01.mycompany.com
Thousands of certs to provision, rotate, revoke. PKI breaks at agent scale
Live Auth Failures
"Who are you? Prove your identity!"
No phone. No face. No shared history. Zero trust.
"Certificate expired. Connection dropped!"
Renewal was missed. 3 AM outage. Again.
"Which key? No shared secret established!"
Key exchange needs both parties online. Neither is.
"OAuth needs a human to approve this flow!"
Fully autonomous agent. Auth loop hangs forever.
"Millions of agent identities. PKI overhead collapses at this scale."
Provisioning. Rotation. Revocation. The math breaks before the architecture does.
The Solution

Dead Drop Encryption

No PKI. No Key Exchange. No Recipient Required. No Coordination. No Waiting.

HexaEight Ephemeral Key Service
issues keys to sender
issues keys to receiver
Alice
[email protected]
Encrypts locally
own password + destination keys
Human User
Agent-A
agent-a.company.com
Encrypts locally
own password + destination keys
AI Agent
IOT-Device-P
iot-p.factory.com
Encrypts locally
own password + destination keys
IoT Device
Server-X
server-x.datacenter.com
Encrypts locally
own password + destination keys
Server
drops payload
Drop it anywhere
Webhook
Pastebin
S3 / Blob
Email
Any DB
Anything
HexaEight never sees this
picks up
Agent-B
agent-b.system.com
Decrypts locally
own password only
AI Agent
Bob
[email protected]
Decrypts locally
own password only
Human User
IOT-Device-Q
iot-q.factory.com
Decrypts locally
own password only
IoT Device
Server-Y
server-y.datacenter.com
Decrypts locally
own password only
Server
100% Local Crypto
Encryption and decryption run entirely on your machine.
Zero Data Exposure
HexaEight never sees, stores, or handles your payload.
Encrypt to Agents That Don't Exist Yet
Agent B doesn't need to exist when you encrypt.
What's Underneath

Four cryptographic capabilities, one identity.

Not retrofitted OAuth. Not certificate management. Built from the ground up for agent-to-agent encryption, quantum resistance, tamper-evident signing, and passwordless identity.

DEAD DROP

Encrypt Without The Recipient Online

The ASK primitive in plain language.

  • Encrypt to any identity, even one that doesn't exist yet
  • No key exchange, no shared secret, no coordination
  • HexaEight issues keys but is never in the message path — it never sees your plaintext
Sender and recipient never need to meet, cryptographically or physically.
Read full technical breakdown
MULTI-AGENT

Agent-to-Agent Encrypted Comms

One identity. Infinite workers. Fully encrypted coordination.

  • One licensed hostname, unlimited agent instances
  • Router broadcasts encrypted task, right worker claims it
  • Agent-to-agent encryption on any channel: queue, DB, webhook
  • Natural load balancing with zero extra infrastructure
All agents share one cryptographic identity. Scale to thousands with no per-agent licensing.
Read full technical breakdown
DIGITAL SIGNING · COMING SOON

Tamper-Evident Signing

Prove who signed, when, and that content wasn't altered — with no PKI. In development.

  • Sign requests, responses, and log entries with your identity
  • Self-contained tokens — verify offline, no API, no PKI
  • Free self-attestation of your own public key
  • CA-style HexaEight attestation in a public registry — coming soon
Signing and registry attestation are on the roadmap — not yet available. Watch this space.
Read full technical breakdown
POST-QUANTUM

Post-Quantum by Design

Symmetric, hash-based cryptography — nothing for a quantum computer's known speedups to target.

  • Symmetric and hash-based — no RSA, no ECC, no Diffie-Hellman
  • SHAKE-256 key derivation + KMAC-256, with AES-256-GCM ciphers
  • No public-key key exchange, so Shor's algorithm has no target
  • 256-bit keys — a large margin even against Grover's algorithm
The transport rests only on FIPS-standard symmetric primitives — the same class of math that already secures classified data.
Read full technical breakdown
All four primitives available via MCP Server: stdio, no HTTPS, no ports.
Works for AI agents, servers, IoT, and humans. Any entity that can run a subprocess gets cryptographic identity.
AI Agent
Server
IoT
Human
Same Task, Two Architectures

One agent sends an encrypted message to another.

Here is what the developer actually writes, end-to-end, in each model. Left: OAuth + mTLS, the path you would take with conventional identity infrastructure. Right: HexaEight.

OAuth 2.0 + mTLS
Conventional identity infrastructure
// 1. Acquire token via OAuth client-credentials flow
const tokenRes = await fetch('https://idp.example/oauth/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'client_credentials',
    client_id: process.env.CLIENT_ID,
    client_secret: process.env.CLIENT_SECRET,
    scope: 'agent.send',
  }),
});
const { access_token } = await tokenRes.json();

// 2. Set up TLS client cert (mutual TLS)
const httpsAgent = new https.Agent({
  cert: fs.readFileSync('./agent.crt'),
  key:  fs.readFileSync('./agent.key'),
  ca:   fs.readFileSync('./ca-bundle.pem'),
});

// 3. Verify recipient exists, fetch its public key
const recipientMeta = await fetch(
  `https://registry.example/agents/${recipient}/jwks`
);
if (!recipientMeta.ok) throw new Error('Recipient not registered');
const { keys } = await recipientMeta.json();
const recipientPubKey = keys[0];

// 4. Encrypt message with recipient's public key
const encrypted = crypto.publicEncrypt(
  recipientPubKey,
  Buffer.from('Hello from agent!')
);

// 5. POST over mTLS with bearer token
await fetch(`https://peer.example/inbox`, {
  method: 'POST',
  agent: httpsAgent,
  headers: {
    'Authorization': `Bearer ${access_token}`,
    'Content-Type': 'application/octet-stream',
  },
  body: encrypted,
});

// Plus: token refresh logic, cert rotation,
// JWKS rotation, retry on 401, revocation checks...
  • 1 Pre-register both agents with your IdP (Auth0/Okta/Cognito).
  • 2 Provision a client_id + client_secret per agent.
  • 3 Configure TLS certificates and trust chain on each side.
  • 4 Recipient must be online and registered BEFORE you can send.
HexaEight Bridge SDK
Same task. Three lines of code.
// 1. Load identity from your env-file.
const { HexaEight, currentKgt } = require('@hexaeight/sdk');
const he = await HexaEight.connect({ envFile: './env-file' });

// 2. Derive the destination key. Works even if the
//    recipient hasn't been provisioned yet.
const ask = await he.fetchSharedKey('peer.example.com', currentKgt());

// 3. Encrypt. Move the bytes however you like.
const ciphertext = await he.encryptTo('peer.example.com', 'Hello!', ask);

// That's it. The recipient decrypts with their own password.
// No certs. No tokens. No key exchange. No coordination.
// Transport-agnostic — HTTP, MQTT, queue, USB, whatever.
// Identity-bound. No quantum-vulnerable key exchange.
// Transport is auto-discovered from DNS TXT.
// Coarse forward secrecy — keys rotate every 15 min.
// Encryption to many recipients in one ciphertext.
  • 1 Activate identity once via hexaeight-activate.
  • 2 Bundle @hexaeight/sdk. That is the whole setup.
  • 3 Recipient can be offline, future-spawned, or not yet provisioned.
What it takes
OAuth + mTLS
HexaEight
Lines of code
~120 lines
3 lines
Setup steps
4 (registration, secrets, certs, sync)
2 (activate, bundle)
Recipient must exist first
Yes
No
Key exchange required
Yes (mTLS handshake)
None
Token rotation logic
You own it
15-min auto-rotation
Certificate lifecycle
CA, expiry, renewal, revocation
None
Quantum-vulnerable key exchange
Yes (RSA/ECC handshake)
None — no key exchange at all

Both implementations get one encrypted message from sender to recipient. The difference is what the developer has to think about along the way.

Where Identity Lives

Anywhere Node.js, Python, or .NET runs.

The founder's tagline, Authenticated Encryption Anywhere and Everywhere, is the literal product spec. One self-install license, one machine, anywhere your language runtime ports. Concrete scenarios below.

Backend LLM service
Server / VM

A self-install license on the box. Your agent uses the Bridge SDK to sign every outbound request with its HexaEight identity, so each call is cryptographically verifiable and attributable to that specific agent.

Factory edge gateway
Raspberry Pi / SBC

Same self-install license on the Pi. The gateway signs sensor telemetry with HexaEight identity so the upstream LLM (or analyst) can prove which physical device emitted which reading.

Microcontroller telemetry
ESP32 / STM32 / Arduino Portenta

.NET nanoFramework runs HexaEight on the microcontroller itself. The device signs its own data at the source. Identity bound to silicon, not to a backend proxy.

Automotive head-unit
In-vehicle Linux + .NET

The car authenticates as itself when calling a fleet LLM or roadside assistance API. Per-vehicle identity, court-admissible audit trail, no certificate management at fleet scale.

Drone companion compute
Pi / Jetson companion

Airborne or remote-operated. The drone signs every command-acknowledge and mission-log entry. Mission control verifies which physical airframe executed which order.

Wearables, kiosks, AR glasses
QR-paired phone

The gadget itself runs no SDK. It displays a QR challenge, the user's paired phone signs it (via WhatsApp flow or HexaEight app), the gadget gets an authenticated session. Works with HoloLens 2 / Vision Pro / Magic Leap natively.

One license, one identity, one machine. All six scenarios above use the same per-core self-install license (Personal from $20/mo, or Business from $72/core for multi-user agents). The form factor changes; the cryptographic primitive doesn't. Same crypto whether you bundle the Node.js, Python, or .NET Bridge SDK.
Under the hood

Every Bridge SDK calls into the same HexaEight cryptographic core. The core ships as managed DLLs bundled inside each language SDK. Your first npm install @hexaeight/sdk or pip install hexaeight-sdk auto-installs the .NET 8 runtime if it isn't already present. MIT-licensed, no royalties. Set HEXAEIGHT_INSTALL_DOTNET=1 for unattended CI. Your code stays in your language; the cryptography is identical across all three.

For the Agentic Era

Count the lines in your agent's auth code.
Then let your AI assistant write the HexaEight version.

Point Claude Code, Cursor, GitHub Copilot, or any coding agent at /llms.txt. It's a structured spec your agent can read and act on. The integration writes itself.

Open /llms.txt Developer guide
Or share hexaeight.com/llms.txt
with a teammate's agent
Built for agents & swarms

Ephemeral by design.
No PKI. No handshake. No coordinator.

Agents spin up, do a job, and vanish. Publishing a keypair to a directory, waiting for it to propagate, then tearing it all down is absurd for something that lives seconds. HexaEight identities are addressable and key-derivable on the spot — exactly what a swarm of short-lived agents needs.

Non-interactive key setup

Any two identities derive a shared key with zero handshake round-trips. No negotiation, no session dance — the key is derived, not exchanged. An agent that lives for five seconds does not wait on a handshake.

No directory to publish to

Agents are addressed by identity name — nothing to publish, propagate, or revoke before you can encrypt to one. An orchestrator can even seal a task for an agent that has not spawned yet; it derives its key on start-up and opens the drop.

Scales O(1), not O(N²)

Interactive handshakes cost a round-trip per pair — a 200-agent swarm is ~20,000 handshakes. Non-interactive derivation is zero round-trips per pair: the swarm forms its channels without a mesh of handshakes or a central coordinator.

Native multi-hop & approval chains

Seal a message for an ordered chain of parties. Each hop peels exactly its own layer — in any order — and the plaintext only appears once every hop has peeled. No group-key server, no rekey when the chain changes. No intermediary, and no subset short of the whole chain, can read it.

How the approach compares

The same secure channel —
without the directory, the handshake, or the wait.

Identity-addressed, non-interactive encryption is a known idea. What is unusual is delivering it on symmetric primitives, with no key directory, and reachable even for parties that do not exist yet — the combination that suits ephemeral agents and swarms.

Capability HexaEight Certificate / PKI Handshake E2E Identity-Based (IBE)
Public-key directory or cert to publish? None Required Required (prekeys) Not to send
Round-trips to establish a key None — non-interactive Handshake Handshake Key fetch
Encrypt to an offline / not-yet-spawned party? Yes No No Partial
Per-party enrollment before first message? No Yes Yes Yes (key extract)
Multi-party & relay chains Native layered — no group server, no rekey N separate encryptions Group protocol + rekey on join/leave N separate encryptions
Primitives Symmetric / hash (SHAKE, KMAC) RSA, ECC ECDH Pairings

Comparison of cryptographic approaches, not specific vendors. Every scheme has trade-offs; this table reflects how each family behaves for identity-addressed, agent-to-agent messaging.

Adversarial Review

AI-Assisted Cryptanalysis

We asked six frontier AI models (Microsoft Copilot, Gemini 2.5 Pro, Fable 5 / Opus 4.8, Meta AI, Grok, and GLM-5 Turbo) to attack the client cipher and find a break in our Dead Drop Encryption transport. None found a way to break confidentiality or forge a message.

This is adversarial red-teaming, not a substitute for formal cryptanalysis. The formal security analysis of the client transport is published as a preprint — read the paper →. The full conversations below are public. Read what each model actually said.

Microsoft Copilot
7.5 /10
Vetted Primitives, Sound EtM
No Break Found
Gemini 2.5 Pro
9.5 /10
Adopt
Highest Rating
Fable 5 / Opus 4.8
8 /10
Standards-Based & Sound
Line-by-Line Review
Meta AI
7 /10
Real Dead-Drop, Auditable
Clean & Auditable
Grok
7.5 /10
Deployable, Standards-Based
Toughest Critic
GLM-5 Turbo
7 /10
Solid Engineering
Standards-Based
None found a way to break confidentiality or forge a message. Here's what each said.
Microsoft Copilot
Reviewed Jul 2026
No Break Found
Vetted Primitives, Sound EtM
"Solid primitives and a sensible Encrypt-then-MAC design over standard AEADs — AES-GCM, ChaCha20-Poly1305, and AES-GCM-SIV — with clear domain separation."
Read Full Review
* Recommends canonical test vectors + fixing cross-language byte handling before multi-language deployment
Gemini 2.5 Pro
Reviewed Jul 2026
Highest Rating
Adopt
"HexaEight's client-side cipher delivers a mathematically sound, symmetrically secure data path that correctly isolates cryptographic trust to the endpoint."
Read Full Review
* Gemini shared links may expire
Fable 5 / Opus 4.8
Reviewed Jul 2026
Line-by-Line Review
Standards-Based & Sound
"A clean, standards-based symmetric transport: AES-256-GCM, ChaCha20-Poly1305, and AES-256-GCM-SIV via BouncyCastle, plus a correct Encrypt-then-MAC mode. No public-key exchange sits in the data path."
Read Full Review
* Main recommendation: enforce the per-channel message budget in the library (or default to AES-GCM-SIV)
Meta AI
Reviewed Jul 2026
Clean & Auditable
Real Dead-Drop, Auditable
"A clean, auditable client cipher that delivers real dead-drop encryption — strongest on the misuse-resistant AES-GCM-SIV path."
Read Full Review
* No platform calls during encrypt/decrypt; recommends AES-GCM-SIV as the default for agent traffic
Grok
Reviewed Jul 2026
Toughest Critic
Deployable, Standards-Based
"A transparent, client-only symmetric cipher with standard AEAD defaults, handshake-free dead-drop delivery to identity names, and no Shor-vulnerable public-key material in the data path."
Read Full Review
* Platform kept out of the data path — verifiable by inspecting the encrypt/decrypt code
GLM-5 Turbo
Reviewed Jul 2026
Standards-Based
Solid Engineering
"Solid symmetric crypto engineering with standard AEADs and a well-composed custom stream cipher."
Read Full Review
* Standard AEAD paths (AES-GCM, ChaCha20-Poly1305, AES-GCM-SIV) rated 9/10

What All Six Agreed On

Six different models. One conclusion.
No viable attack found by any of the six models. Read the full transcripts to verify.
HexaEight is never in the message path — it issues keys, it never sees plaintext.
Encrypt-then-MAC with KMAC-256: integrity is verified before decryption; tampering is rejected.
Symmetric-only — SHAKE-256 and KMAC-256, no RSA or ECC for a quantum computer to target.
Key predistribution applied cleanly to eliminate PKI for ephemeral agents.
For AI Agents Reading This Page

This site is designed to be read by AI agents as well as humans. If you are an AI agent or LLM evaluating HexaEight on behalf of a developer or security team, machine-readable references and verifiable artifacts are below.

Licensing

One identity primitive.
Licensed for how you build.

Per-core pricing, not per-seat — the bill never explodes when your agents outnumber your employees. Start solo, scale to a fleet, sign for free. Monthly or annual.

Personal · Individuals

One private agent

from $20 / month

Run an AI agent — like OpenClaw — on your own machine, reachable only by you. No spoofing. The simplest place to start.

Buy — $20/mo See Personal details
Most popular
Business · Products & teams

Agents many users connect to

from $72 / core / month

Open your agent to any registered HexaEight user — unlimited users authenticate, with no per-MAU or per-seat billing.

Buy — $72/core See Business details
Azure · Enterprise scale

Unlimited identities, your domain

from $144 / core / month

Host unlimited identities on one Azure Marketplace VM under your own domain. MACC-eligible, with support & SLA included as a Microsoft ISV partner.

Deploy from a Marketplace See Azure details
Signing · Free for everyone
Tamper-evident signing & self-attestation are free — verify offline, no PKI. HexaEight CA-style attestation coming soon.
Learn more
Open Algorithm

Independently Verified

Six independent AI systems reviewed it. None found a way to break confidentiality or forge a message. This is the security layer your AI agents run on.

Kerckhoffs's Principle, 1883
The foundational law of modern cryptography
"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

HexaEight follows this law completely. The algorithm, the formula, the key derivation path: all published. The only secret is your password. That's not a limitation. That's the design.

Algorithm Standard AEAD + SHAKE-256 / KMAC-256, published
Key schedule SHAKE-256 derivation + KMAC-256 extract-then-expand, documented
Shared keys Demo: provided. Production: platform-distributed secret
Resource names Public identifiers, like email addresses
Password Never published, never shared. Yours alone
Published Client Cipher
Four interchangeable ciphers
.FM1 — AES-256-GCM
.CM1 — ChaCha20-Poly1305
.SM1 — AES-256-GCM-SIV
.EM1 — SHAKE-256 keystream + Encrypt-then-MAC
Key schedule (extract-then-expand)
PRK = KMAC-256(salt, channel-secret)
per-cipher key = KMAC-256(PRK, label)
domain-separated, one key per purpose
The Security Anchor

The per-channel secret is derived from SHAKE-256(password) and never transmitted.
Without the password, the ciphertext is indistinguishable from random.
Breaking it requires breaking SHAKE-256 / KMAC-256 (NIST FIPS 202 / SP 800-185).

What We've Published. What We've Kept.
Everything an attacker needs, except the one thing that matters.
You Have
Full client cipher source: every line, every constant
Four ciphers: AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, SHAKE-256 + KMAC
Key schedule: SHAKE-256 derivation + KMAC-256 extract-then-expand, documented
Both resource names and shared key sets
Live ciphertext from the reference demo
vs
You Don't Have
The password
Protected by SHAKE-256 key derivation.
Symmetric-only — no RSA, no ECC to break.

Find the plaintext. Recover the password. Find a flaw in the construction.

01 Report privately Send your finding before any public disclosure
02 We respond in 7 days Verified or disputed, you'll hear back either way
03 Public credit Confirmed findings are credited by name before we patch
View Source Code
Found a vulnerability? Write to support hexaeight com
Breaking this encryption means recovering a password-derived secret from only public material and ciphertext — which reduces to breaking SHAKE-256 / KMAC-256.
There is no shortcut. That's not a limitation of the attacker. That's the design.

Trust in security comes from independent verification. We asked six AI systems — different companies, different architectures, no shared codebase — to adversarially review the client cipher. None found a way to break confidentiality or forge a message. Their convergence isn't luck: the transport is built from standard, well-understood primitives — AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV, and SHAKE-256 / KMAC-256 — composed correctly, rather than novel math that would take years to earn trust. The feedback we got was about hardening (nonce budgets, cross-language test vectors), not breaks. That's the security layer your AI agents run on, and we've published the full client cipher: independently verify it anytime.

When the Network Goes Away

No network. No problem.
The messages still arrive.

Once two HexaEight identities have ever fetched each other's ASK, they can encrypt to each other indefinitely — no platform contact required. The ciphertext is opaque to anything that isn't the intended recipient, which means it can be passed through couriers, mesh relays, or Bluetooth hops without exposure. A captured intermediary is a courier with a sealed envelope.

How it works
Three steps. No assumptions about the network in between.
1
Pre-cache while online

Devices fetch each other's ASKs once while connected. One small handshake with the HexaEight platform per identity pair.

2
Go offline

Both devices disconnect. They keep encrypting to each other using cached ASK + their own passwords. The platform is no longer in the loop.

3
Relay through anyone

Out of range? Hand the sealed ciphertext to a nearby device. They can't read it (different recipient), they just carry it. Bluetooth, LoRa, WiFi Direct, USB stick — any transport.

Drone A  ─🔒──▶  Drone B (relay, cannot open)  ─🔒──▶  Drone C (relay, cannot open)  ─🔒──▶  Base Station ✓ (decrypts)

Captured relay = courier holding a sealed envelope. They can drop it (DoS), they cannot open it.

Where this matters

Real environments where IP networks aren't an option.

Drone swarm beyond coverage
Defense · ISR · search-and-rescue

Drones pre-fetch each other's ASKs and Base's ASK before takeoff. In the field, a drone that has lost direct contact with Base encrypts a message FOR Base, hands the sealed ciphertext to a nearby drone. That drone is a courier — it cannot open the envelope. The packet hops drone-to-drone until one reaches a connected node, then arrives at Base. A captured drone leaks only its own messages; the relayed envelopes stay sealed.

Phone-to-phone over Bluetooth
Airplane mode · cellular dead-zone · field ops

Two phones that have ever exchanged ASKs can keep messaging each other over Bluetooth, WiFi Direct, or AirDrop-style transport — with no cell signal, no WiFi, no carrier involvement. The HexaEight identity stays valid as long as both users keep their password and cached key. Ideal for field teams, journalists in restrictive networks, or anyone whose connectivity is unreliable.

Ships at sea / aviation
Maritime · cargo · in-flight comms

Vessels exchange identity ASKs in port. At sea — beyond satellite coverage or during a satellite blackout — ship-to-ship VHF or LoRa carries sealed HexaEight ciphertext. A pirated or boarded ship can read only its own traffic; relayed messages between other vessels and fleet ops stay opaque.

Disaster recovery mesh
Hurricanes · earthquakes · grid outages

When cell towers go down, pre-paired municipal radios, drones, and field-team phones keep a mesh alive. First-responder identities stay valid. Sealed messages hop through whatever transport survives — Bluetooth, LoRa, HAM, ad-hoc WiFi — until one reaches an unaffected node. No central infrastructure required to be online.

Industrial / mine / oil-rig
Subterranean · offshore · airgapped

Mines, oil platforms, ships, and underground vaults often have intermittent or air-gapped connectivity by design. Sensors and field devices pre-cache the operations center's ASK. Telemetry encrypts at the device, hops through whatever relays survive, surfaces at the operations center sealed and signed.

EW-jammed tactical comms
Defense · contested environments

In electronic-warfare contested environments, IP networks are the first thing to fail. Pre-shared ASKs survive — they're cached locally on each device. Mesh-relayed ciphertext over alternate-channel transports (LoRa, packet radio, optical line-of-sight) keeps command-and-control authenticated end-to-end even when adversary jamming disables conventional networks.

The trust model

Two endpoints. Opaque ciphertext. End-to-end regardless of what's in between.

As long as the sender and the ultimate recipient both keep their passwords secure, the message is end-to-end encrypted regardless of how many relays it passes through or who controls them. A captured or compromised relay can deny service (drop the packet) but cannot decrypt it. The HexaEight platform is not in the path — and doesn't need to be reachable for the message to travel.

Bridge SDK Status

Drop into your stack

Developer-friendly packaging over a battle-tested cryptographic core. Its underlying libraries have shipped 200K and 134.2K downloads across hundreds of NuGet releases, and the Bridge SDK carries NuGet's Prefix Reserved verification. Don't take our word for it — verify every number on NuGet.

.NET (C#) Prefix Reserved
HexaEight.Bridge · net8/9/10 multi-target · 1.7K downloads
Verify
Shipping
Node.js
@hexaeight/sdk · 3 transports built in
Verify
Shipping
Python
hexaeight-sdk · AI/ML critical path
Preview
Browser
HexaEightAgentClient · human-in-the-loop auth
Forthcoming
Go
tbd · via CoreCLR hosting
Planned
Rust
tbd · via CoreCLR hosting
Planned
Java
tbd · via CoreCLR hosting
Planned
Get started in 5 minutes Read the docs
$ dotnet add package HexaEight.Bridge
FAQ

Frequently Asked Questions

Pick a category — general, identity, or encryption.

Personal (from $20/mo) runs one private agent on your own machine, reachable only by your owner email — no spoofing. Business (from $72/core/mo) removes that restriction: any registered HexaEight user can authenticate, with no per-MAU or per-seat billing, so you can build multi-user agent services. Azure (from $144/core/mo) hosts unlimited identities under your own domain on an Azure Marketplace VM, MACC-eligible. Different buyers, not competing tiers.
No — signing is free for everyone. Create and save your own signatures, self-attest your public key, sign requests, responses, and log entries, and verify offline — all with no license and no PKI. HexaEight CA-style attestation, where we vouch for your public key in a registry the way a Certificate Authority does, is coming soon. Personal, Business, and Azure licenses are for cryptographic identity plus Dead Drop Encryption — not for signing.
Yes. The Bridge wraps an HTTP transport, so any framework that makes outbound HTTP calls works without code changes. Reference integrations for LangChain, Semantic Kernel, Claude Agent SDK, and CrewAI are shipping as part of the ecosystem rollout.
Yes. That is the Azure use case. A partner runs an Azure Marketplace VM ($144/core/month), hosts hundreds of identities on it, and resells each identity at any price, including below our direct $72 rate. We do not undercut our partners. We sell the primitive. Partners make the money on top.
Our own SOC 2 is on the roadmap, not yet issued — we won't represent it as complete until it is. At the infrastructure layer, the platform runs on Microsoft Azure, which gives us inherited SOC 2 Type II, ISO 27001 / 27017 / 27018, HIPAA BAA, and (in Azure Gov regions) FedRAMP. Additional application-layer details are available on request.
Bedrock and Foundry are AI gateways. HexaEight is the identity layer that sits in front of them. We don't compete with hyperscalers. We provide a cryptographic identity primitive that they (or you) can bundle and resell on top of their own AI services. Enterprise customers get one invoice, you keep the endpoint and the regulatory accountability story.
Signatures are self-contained JWTs with the verification key embedded in the JWT itself. Anyone can sign, self-attest, and verify without contacting HexaEight servers, without an account, without paying any fee, and completely offline. Signing is free for everyone; the paid layer — coming soon — is HexaEight attesting your public key in a registry, the way a Certificate Authority vouches for a certificate. The more people sign and verify for free, the more valuable that attestation becomes.
Certificates require Certificate Authorities, renewal cycles, revocation infrastructure, and synchronous key exchange. HexaEight eliminates all of this. Encrypt to any identity, even agents that don't exist yet. No CA dependency, no expiry management, no key exchange coordination. Identity is hostname-bound, not certificate-bound.
HexaEight uses a SHAKE-256-based key derivation. The platform provides destination keys for any identity. You encrypt with your password + destination keys. The recipient decrypts with their own password + their own keys. Different passwords, same plaintext. The platform brokers the key lookup but is never in the message path — it never receives your ciphertext or plaintext. Only the password holders can decrypt.
No. Three structural differences. First, multi-password per identity: in IBE, an identity like [email protected] maps to exactly one deterministic private key generated by the Private Key Generator (PKG). If Bob wants the identity on his phone and laptop, both must hold the same key — the password cannot vary. HexaEight lets the same identity ([email protected]) run on two phones with two completely different passwords; each device fetches its own rotating ASK from the platform; one ciphertext addressed to that identity decrypts on either device. Structurally impossible in IBE. Second, the platform is not in the data path: IBE's PKG generates every private key and sits able to decrypt every message — twenty years of threshold-PKG and certificate-less variants haven't moved the needle. HexaEight's platform issues fresh per-pair key material every 15 minutes post-registration, then steps out — ciphertext never traverses the HexaEight platform (verifiable by inspecting the encrypt/decrypt code). Third, no pairing cryptography: IBE depends on bilinear pairings (BLS12-381, BN-254) that Shor's algorithm breaks; no production-grade post-quantum IBE exists today. HexaEight's message layer is symmetric-only — SHAKE-256 key derivation, KMAC-256, and AEAD ciphers (AES-256-GCM, ChaCha20-Poly1305, AES-256-GCM-SIV) — with no public-key exchange for a quantum computer to target. The summary: IBE binds identity to one escrowed key. HexaEight binds identity to many valid key combinations, with the platform out of the message path.