Introducing the Aethyr Agent Registry: Cryptographic Identity for Autonomous AI
Every autonomous AI agent in production today has the same identity infrastructure as a shell script with a cURL command: a shared API key and a prayer.
That changes today. The Aethyr Agent Registry is live.
The Problem in Three Questions
Every major framework (LangChain, CrewAI, AutoGen, OpenAI Assistants) ships agents into production with no verifiable identity, no portable credentials, and no cryptographic audit trail. The default trust model of the agent economy in 2026 is a shared API key in an environment variable.
When an agent connects to a service, that service cannot answer three basic questions: Who is this agent? What is it authorized to do? Can I prove it performed this action?
The answer to all three is currently "no."
What the Registry Does
The Aethyr Agent Registry issues cryptographic identity to autonomous AI agents. Not API keys. Not session tokens. Verifiable, portable, standards-based credentials that any service can validate offline.
The Process
1. Register. An operator registers their agent: name, organization, framework, capabilities, and tier selection. This creates a binding between the agent and a responsible operator.
2. Receive. The registry issues a signed credential containing:
- A decentralized identifier (DID):
did:aethyr:<namespace>:<identifier> - The agent's declared capabilities
- Operator binding
- A post-quantum digital signature (ML-DSA-65, NIST FIPS 204)
The DID is the BLAKE3 hash of the agent's ML-DSA-65 public key. Self-certifying. No blockchain. No vendor dependency.
3. Present. The agent carries its credential and presents it at service boundaries: API gateways, MCP servers, tool endpoints, inter-agent communication channels.
4. Verify. Services validate the credential locally using the @aethyrai/ssi-verify npm package. One function call. No network request. No account required.
import { verifyCredential } from '@aethyrai/ssi-verify';
const result = await verifyCredential(credential, issuerPublicKey);
// result.valid → true | false
// Offline. Zero dependencies. ~0.5ms.
The verification library is 3.8 kB with zero dependencies. It runs anywhere JavaScript runs: edge functions, embedded systems, air-gapped networks.
Why Post-Quantum
Classical digital signatures (ECDSA, Ed25519) will be broken by cryptographically relevant quantum computers. The timeline is debated. The direction is not.
Agent credentials are long-lived artifacts. A credential issued today may need to be verified, or its audit trail validated, years from now. Signing with a scheme that has a known expiration date is architectural negligence.
ML-DSA-65 (formerly CRYSTALS-Dilithium) is the NIST-standardized post-quantum signature scheme finalized in FIPS 204. It provides 128-bit post-quantum security. The signature is 3,309 bytes. The public key is 1,952 bytes. Verification takes approximately 0.5 milliseconds.
Every credential the registry issues is signed with ML-DSA-65. Every audit trail entry is quantum-resistant from day one.
Why Offline Verification Matters
Most identity systems require a network call to verify a credential: check a token against an auth server, call an OIDC provider, hit a revocation endpoint. This creates three problems for agent infrastructure:
Latency. Agents operating at machine speed cannot wait for round-trip network calls at every service boundary. Sub-millisecond local verification removes identity as a bottleneck.
Availability. Air-gapped environments, edge deployments, and contested networks cannot rely on external verification services. An agent operating on a disconnected device still needs to prove its identity.
Trust. Network-dependent verification means trusting the verification service. Offline verification means trusting math. The signature either checks against the public key or it does not. There is no middleman to compromise.
This is why the @aethyrai/ssi-verify package exists as a standalone, zero-dependency library. Verification is not a service. It is a function.
Access
The registry is designed to make evaluation frictionless and enterprise-grade identity available where the stakes demand it.
| Tier | Access | What You Get |
|---|---|---|
| Evaluation | Self-serve, no charge | Agent DID + signed credential, 1-year validity, operator-initiated revocation, ML-DSA-65 signature |
| Enterprise & Government | Provisioned per engagement | Organization verification (DNS domain proof), agent identity integrated with Aethyr platform governance and audit, air-gapped deployment options, hardware attestation roadmap |
Evaluation access exists because the barrier to trying agent identity should be zero. Every agent, from a weekend project to a defense deployment, deserves a cryptographic identity.
Enterprise and government provisioning adds the layers regulated programs actually need: proof of organizational control, governed issuance, and verification that works where there is no network at all.
Standards
The registry implements three open standards:
- W3C Verifiable Credentials 2.0: the credential format
- W3C Decentralized Identifiers: the identifier scheme
- NIST FIPS 204: the signature algorithm
These are not proprietary protocols. Any system that implements the W3C VC and DID specifications can issue, hold, and verify Aethyr credentials. The registry is an issuer, not a gatekeeper.
What This Enables
Cryptographic agent identity is infrastructure. It enables capabilities that are impossible without it:
Service-level access control. An API gateway can enforce that only agents with valid credentials and specific capability claims can access specific endpoints. Not by checking a database, but by verifying a signature.
Inter-agent trust. When Agent A delegates a task to Agent B, Agent A can verify Agent B's identity and capabilities before sharing context. Multi-agent orchestration moves from "hope the coordinator routed correctly" to "cryptographically verified delegation chain."
Tamper-evident audit trails. Every action signed by an agent's private key creates an unforgeable record. Compliance, forensics, and incident response get cryptographic proof instead of database rows.
Sovereign deployment. Organizations operating in air-gapped, ITAR-restricted, or data-sovereign environments can verify agent identity without any external network dependency. The math works the same on a submarine as it does in a data center.
Get Started
The registry is live at registry.aethyr.cloud.
The verification library is on npm and GitHub.
The API documentation covers registration, credential retrieval, revocation, and the issuer's public DID document.
Register an agent. Verify a credential. The identity layer for autonomous AI is here.
For defense and critical infrastructure deployments requiring sovereign DID namespace registration or air-gapped credential provisioning, contact Aethyr Research directly.