Agent Name Service v2 makes an agent prove it owns its name

What it does

When agents talk to each other, the first question is who is speaking. Agent Name Service gives an agent a verifiable name and a way to prove control of it, using ordinary public-key cryptography rather than a trust-me identifier.

Identity bindings are real Ed25519 signatures with a pinned issuer and an expiry. The registry is SQLite with unique names, capacity bounds and durable revocation, so a withdrawn name stays withdrawn.

What changed

Commit 0565783, merged as pull request #4 on September 10, replaces a 2025 prototype with a v2 alpha: signed bindings, the registry, audience-bound subject signatures with single-use server challenges, a local CLI, an SDK 2 MCP verification surface with a policy resource, and validation covering tampering, expiry, replay and persistence.

The historical TypeScript in src/ and the sparc-agent prototypes are unsupported. The supported API is v2/identity.mjs and nothing else.

Get started

Node 24, plus Python 3.12 for the Guardrail dependency:

git clone https://github.com/ruvnet/Agent-Name-Service.git
cd Agent-Name-Service
npm ci
npm test
npm run benchmark

Expected result: the test suite passes, including the tampering, expiry and replay cases. That suite is the actual demonstration — there is no hosted demo.

The agent interface runs from the harness runtime:

npm ci --prefix .harness/runtime
node .harness/runtime/cli.mjs status
node .harness/runtime/cli.mjs mcp

This is a local identity library. It is not X.509, not DNS, not a public certificate authority and not Nostr identity. Production issuance needs operator-managed keys and a private database, which installation does not provide.

Use it today

Practical case: a fleet of internal agents that must not be able to impersonate one another. Input is a name and a key pair. Workflow is register the binding, issue a challenge, verify the audience-bound response. Output is a yes or no you can log.

Acceptance test: replay a previously successful challenge response. Verification must fail, because challenges are single use. If a replay succeeds, the whole scheme is decorative.

Push it further

Experimental commentary. Pairing these bindings with the Ruflo federation's per-participant keys is the interesting direction: a name that resolves to a key, and a relay that only accepts events signed by the key that authenticated.

Limitation: nothing here distributes trust. A binding is only as good as the issuer you pinned, and this release does not solve issuer distribution. Falsifiable test: expire a binding, then verify it. It must be refused on expiry alone, without needing revocation.