Arken lets AI agents prove who they are to the tools they call

What Arken is

Arken is the cryptographic core of a larger project called ArkenForge, as github.com reported in the project's documentation. It is a library written in Rust, a programming language, that other packages build on. Its job is to let a server confirm which AI agent is knocking on the door.

The target is the growing set of agents that call MCP servers (the connectors agents use to reach outside tools and data) and ordinary web APIs. Today many of those connections rely on a shared secret, such as a password or key that several callers might hold. Arken replaces that with an identity that belongs to one agent.

The post appeared as a Show HN, a Hacker News format where makers present their own projects. When we saw it, it had 1 point, so almost nobody has weighed in yet.

How the handshake works

The flow is a challenge and response. An agent asks for a protected page and gets refused with a 401 error. The refusal comes with a one-time random value, called a nonce, plus a short statement.

The agent then signs that nonce using its private key, which only it holds. It repeats the request with the signature attached in an Authorization header. The server checks the signature and the nonce, and if both pass it learns the agent's identity and lets the request through.

Each nonce expires after 60s, so a stolen signature is of little use later. The signing method is ECDSA, a standard way to prove you hold a private key without revealing it, using a specific mathematical curve called secp256k1. Arken relies on a library named ethers-rs for the verification step.

What a did:key identity is

The identity an agent receives is a did:key. A DID, or decentralized identifier, is a W3C standard format for an identity that is not tied to one company's login system. With did:key, the identifier is derived directly from the agent's key pair, so there is no registry to sign up with.

That has a practical consequence. The same key always produces the same DID, so one agent keeps one identity across every server running Arken. For secp256k1 keys, the identifier starts with the letters zQ3s, which tells software which kind of key it is looking at.

The source says the core returns the agent's identity after verification and does not store anything about the agent itself. A server therefore does not need to keep a password database for its callers.

How developers plug it in

Arken compiles into a native shared library, the kind of file other programs load at run time. Higher-level packages reach it through an FFI, short for foreign function interface, which lets code written in one language call code written in another.

The library exposes three functions: one to generate a challenge, one to verify a full request, and one to check only the signature. Each writes its result as JSON, a plain text data format, into a buffer the caller supplies. Building it currently requires the Rust toolchain.

The limits, stated plainly

The project is candid that it is early. Its own list of caveats is worth reading before anything else:

• Not production-ready. It is described as an early-stage project.
• Nonces live in memory. They will not survive a restart, and they will not work across several server instances without a shared store.
• No key recovery. If an agent loses its private key, it loses access.
• Build friction. Prebuilt binaries are on the roadmap for version 1.0.

The authors invite security researchers to report flaws through a private advisory and promise a place in a Hall of Finders. Anyone who joins before December 15, 2026 is credited by name in the 1.0 README as a Founding Builder, and there are 10 design-partner slots for teams who want to shape the API. The code is under the Apache 2.0 license.

We have not tested the code or seen an independent security review, so treat the claims as the project's own.