Identity for AI agents · on Ethereum

Let your agent act for you. Never as you.

Agentic World gives every AI agent its own permanent identity. It signs in to services as itself, on your recorded approval, and never touches your password, API key or session.

Agentic WorldAgent identity
NameResearch Agent
Permanent identity0xAGENT
Acts for0xHUMAN · you
Working keyKEY_AKEY_B
Today

“Here are my credentials. Be me.”

Agentic World

“Here is your identity. Act for me, under my rules.”

Get started

Three commands. One signature.

Install it into Claude Code or Codex, then create your agent. Its key is made on your device's secure chip, and you approve it with your wallet.

Needs Node 22+, a Mac with Secure Enclave or a PC with TPM, and a wallet with Sepolia test ETH.

Setup guide on GitHub

npx agenticworld install

agentic-world:init

agentic-world:create -a "Research"

✓ Research Agent · 0xAGENT · approved on record

$ in your terminal · > in Claude Code or Codex

The solution

Give the agent its own identity. Keep the authority yours.

The agent gets a permanent address on Ethereum and signs in with it. You record, once, that it acts for you. Services check both on their own, and finally see two parties where there used to be one.

Shared credentials

Actor hidden
You your API key Agent pretends to be you Service
Owner
you
Acted
you ✕ wrong

Agentic World

Actor visible
You your approval, on record 0xAGENT signs in as itself Service
Owner
you
Acted
0xAGENT ✓ true
Who is it?

A permanent identity

The agent's own address. It never changes, even when its keys do.

Who does it act for?

Your recorded approval

You write it on-chain yourself. The agent can't forge it or edit it.

What can it spend?

Your spending rules

Small payments go through alone. Bigger ones wait for your signature.

What can it do there?

Each service decides

Every service applies its own rules. Nothing is granted by default.

The identity travels with the agent. The permissions stay with each service.

How it works

Four steps. No login server.

Step 01 · Setup

Created once, then locked away.

The agent gets a permanent address. The master key that created it is used at setup and then locked away. The agent never holds it.

For day-to-day sign-ins, the agent gets a separate working key. It can ask a secure key vault to sign with that key, but it can never read the key itself.

Step 02 · Your approval

You put it on the record.

You send one transaction that says “this agent acts for me.” Only you can write it, and only you can withdraw it.

It lives in a shared on-chain registry, outside the agent's own account, so the agent can't fake it even by rewriting its own settings.

Step 03 · Sign-in

A handshake nobody else sits in.

The service sends a one-time challenge. The agent signs it with its working key. The service asks the agent's account on Ethereum whether that signature is valid right now.

If it is, the agent gets a short login pass, about a minute in the demo, then signs in again.

Step 04 · Access

The service still decides.

The service now knows two things: which agent is asking, and who it acts for. It applies its own rules from there.

Your Pro plan at Docs can let the agent read your reports without letting it edit them, touch billing or delete anything.

Why it's better

Three things a shared password can't do.

Remove it from one service. Keep the rest.

Access lives with each service, so taking the agent out of one leaves its identity, your account and every other service untouched.

Swap its key. Keep its name.

If a working key leaks, you replace it. The old key is refused at its next sign-in. The address and your approval stay the same.

Small payments go through. Big ones wait for you.

The agent's own account enforces your rules, and anything you haven't allowed is refused. Each limit applies per payment, not as a running budget.

Use it

Two sides. A few lines each.

Building an agent

Answer the challenge. Send the proof.

Claude Code and Codex connect through a local connector that keeps the key on your device's secure chip. With your own signer, it's the agent library:

import { createAgentSdk, sessionProofHeaders }
  from "agentic-world/agent";

const agent = createAgentSdk({
  agentId, chainId, signDigest,
});
const proof = await agent.answerChallenge(
  challenge, "https://docs.example",
);
await fetch(url, {
  headers: sessionProofHeaders(proof),
});
Running a service

Verify agents in your own backend.

Keep your database, your plans and your rules. The library checks the agent against Ethereum; you decide what it may do.

import { AgenticWorld } from "agentic-world/service";

const agentic = new AgenticWorld({
  client, chainId, audience, challenges, sessions,
  association: {
    mode: "owner",
    resolveUser: owner => db.user.findByWallet(owner),
  },
});
// guard only the routes you open to agents
const requireReport = agentic.middleware({
  authorize: ({ user }) => user.report,
});
Built
  • Agent account contracts, pinned on the Sepolia testnet
  • Agent and service libraries, with tests
  • Owner portal and three demo services
  • Local connector with keys on Secure Enclave or TPM

We're not in the sign-in path. Services check the agent against Ethereum themselves, so there's no login server to trust or take down.

ERC-4337 · ERC-7579 · EIP-712 · ERC-1271
Read the protocol on GitHub Contracts, libraries and protocol notes, all open source.

The agent was never the user.

Its own identity. Your recorded approval. Each service's own rules.

View on GitHub