Concept

Overview

HexaEight provides cryptographic identity and end-to-end encrypted messaging for AI Assistants and Agents, humans, and machines. Every message your application sends or receives carries a verifiable identity, and every message can be authorised against a set of rules — without certificates, without OAuth, without a central key directory.

What you can build with HexaEight

Once you integrate the SDK, your application can:

• Exchange encrypted messages with any other party who has a HexaEight identity
• Cryptographically verify the sender of every message that arrives
• Enforce policy rules controlling who can talk to whom and in which direction
• Run the same logical agent on multiple machines with a shared, encrypted policy
• Relay messages through intermediate agents while preserving the original sender
• Build approval chains where a message must pass through multiple parties

How the documentation is organised

These docs are arranged for a developer learning HexaEight from scratch. Work through them in order if you are new; jump to the section you need if you are not.

Identity comes first

Every HexaEight integration begins with an identity. An identity is either:

• A user identity — an email address, authenticated by the HexaEight Authenticator mobile app
• An agent identity — a hostname bound to a specific machine via an activation process

Identities are issued once and remain valid for the duration of the underlying HexaEight license — for the term of a standalone license, or for as long as an Azure Marketplace VM remains running. Within that period, there is no certificate enrolment, no key rotation, no OAuth flow, and no re-keying cycle. See Identity model for the full lifecycle.

Authorisation is built in

The SDK does not stop at encryption. Every message that arrives is also checked against a set of policy rules before being delivered to your code. By default, the SDK is in a friendly bootstrap mode that lets every message through. As soon as you add your first rule, enforcement starts.

Rules describe who can send messages to your agent, who you can send messages to, and under what conditions. The model is small (four levels of rules), built around cryptographic identity, and has no external dependencies. If you have an existing authorisation system (LDAP, OAuth, OPA), you can plug it in instead.

One model, many languages

The cryptographic core is implemented in .NET. Other language SDKs wrap that core so the same identities and policies work everywhere:

Every page in this documentation that contains code shows examples in each SDK that is currently available.