Concept

The problem we solve

AI Assistants and Agents need to communicate securely with users, with one another, and with the services they orchestrate. The existing identity stack does not handle this cleanly. This page describes the gap. The next page describes the HexaEight approach to closing it.

What developers need

A modern agent-based application typically requires four capabilities:

1. Authenticated messaging. Every message that reaches a recipient must come with proof of who sent it.
2. Confidential messaging. Only the intended recipient can read the content of any given message.
3. Authorisation. A configurable rule set determines whether a particular sender is allowed to send a particular message to a particular recipient.
4. Multi-instance coordination. A logical agent may run as multiple processes on multiple machines; they need to share state securely.

What the existing stack offers

Today these capabilities are typically delivered through a combination of:

• Public-key infrastructure (X.509 certificates, certificate authorities, CRLs) for identity
• TLS for transport confidentiality and integrity
• OAuth 2.0 or OpenID Connect for user authentication and delegation
• Mutual TLS or shared API keys for service-to-service authentication
• Some form of policy engine (custom code, LDAP, RBAC implementations) for authorisation
• A central key directory or service mesh for cross-component coordination

Each of these is mature in isolation. Together they require substantial integration work, ongoing operational effort, and produce a system in which the security properties of any one component depend on the correct configuration of several others.

Where the existing stack falls short

Identity is fragmented

A user authenticates against an OAuth provider and is identified by a JWT. An agent authenticates against another agent using mutual TLS and is identified by a certificate. A service authenticates against a database using a connection string. These three identity systems are independent; correlating an action across them requires custom code or a separate audit trail.

Certificates are operationally expensive

Issuing, renewing, and revoking certificates requires running a CA or paying for one. Each agent that needs to talk to another needs a certificate. As the number of agents grows, the certificate fleet grows with it, and so does the operational burden of keeping it healthy.

OAuth was designed for a different problem

OAuth is designed to delegate a user's authority to an application. It assumes a small number of trusted issuers, browser-based redirect flows, and human consent screens. Adapting it to agent-to-agent communication requires multiple workarounds (client credentials grants, machine-to-machine tokens, custom audience handling). The result is workable but cumbersome, and the operational model still requires a central token-issuing service in the critical path of every request.

The authorisation layer is application-specific

Authentication tells you who the caller is. Authorisation — who is allowed to do what — is left to the application. Every team ends up writing some variant of role-based access control on top of the identity layer. Across services, those implementations diverge, and policies cannot be shared.

Scaling an agent across machines is hard

Running the same logical agent on multiple machines is a common need (horizontal scaling, failover, geographic distribution). Each instance needs the same secrets, the same policy, and the ability to coordinate work — typically requiring a custom orchestration layer on top of the identity system.

What a better starting point would look like

If we could redesign the identity and messaging layer from scratch, with modern agent applications as the explicit target, it would have these properties:

1. One identity model for users, agents, and services — not three.
2. No certificates, no certificate authority, no certificate rotation.
3. A lightweight platform role at runtime — used only to derive shared keys per recipient pair (typically once per 15-minute window, then cached). No long-lived bearer tokens, no token refresh cycles, no token-issuer in the critical path of every message.
4. End-to-end encryption by construction — the platform cannot read the messages, even in principle.
5. A built-in authorisation layer with a simple rule format and no external dependencies, replaceable with an existing system (LDAP, OAuth, OPA) when needed.
6. Native support for running the same agent on multiple machines with shared, encrypted state and distributed coordination.

The next concept page, The HexaEight approach, describes how HexaEight provides these properties.