Agentic World

Demo

About

Agentic World gives AI agents their own onchain identity, so they stop borrowing human credentials. Today, an agent that wants to use a service either gets its owner's password, API key or wallet, or it can't act at all. Agentic World replaces that with a separate account for each agent. The account is owned by a human, can be verified by any service, and the owner can limit what it does. Each agent is a smart account on Sepolia, created from a shared factory. Its signing key is a P-256 key held in the device's secure hardware: the Secure Enclave on macOS, or the TPM on Windows. The key never leaves the device, and the agent itself never sees it. When the account is created, the human's wallet is recorded as its owner. The owner can rotate or revoke the agent's key at any time and set an onchain spending policy: which contracts and functions it may call, up to what amounts, and which actions need the owner's own signature. Services integrate through our TypeScript SDK. A drop-in middleware protects any route. An agent that calls it gets a challenge back, signs it with its hardware key, and retries the same route with the proof attached. The service then checks the signature against the agent's account onchain and reads who owns it. Authentication tells the service which agent it is and whose it is. What the agent may do stays the service's own decision. No central Agentic World server sits in that path. Agents use Agentic World through an MCP server. It creates the identity, with the owner approving in their browser wallet; it signs service challenges; and it previews policy decisions. It only handles authentication, so it works with any service. To show real-world adoption, we integrated Agentic World into Curvegrid's Matsuri stablecoin demo, built on MultiBaas. AI agents sign in to Matsuri as themselves, never with a human's wallet or Matsuri's MultiBaas key. Owners connect MetaMask and switch each permission on or off for all their agents, or for just one. The permissions are: see balances and tickets, see history, buy vouchers, and redeem them. Matsuri prepares the exact transactions an agent may run. It's deployed on Vercel, with Upstash Redis holding sign-ins and permissions.

How it's made

Contracts. The agent account is an ERC-4337 smart account written in Solidity on OpenZeppelin 5's ERC-7579 account base, using the canonical EntryPoint v0.8 on Sepolia. - Factory: each agent is a minimal ERC-1167 clone of one shared implementation, which makes deploying an agent cheap and easy to verify. - Validator module: verifies the agent's P-256 signatures with OpenZeppelin's P256 library, and answers ERC-1271 isValidSignature. That's how services check a sign-in proof. - Policy module: a hook that checks every call against the owner's ordered rules. A rule covers the target, the function, the value and a token amount, with decisions ALLOW, DENY or REQUIRE_OWNER_SIGNATURE. Owner approvals are EIP-712 signatures with replay protection. - Tooling: everything is built and tested with Hardhat 3, viem and Node's test runner, including end-to-end tests against a real EntryPoint. Hardware Keys. The agent's key never exists in software. - macOS: a small Swift helper creates the key inside the Secure Enclave. - Windows: a Go helper does the same in the TPM, through the Microsoft Platform Crypto Provider, calling Windows' NCrypt API directly. It's shipped as a prebuilt, verified executable, so users need no compiler. - What they sign: both helpers sign only structured sign-in challenges, never arbitrary data. SDK. A TypeScript SDK in three parts: - Core: the contract ABIs, proof formats and policy encoding. - Agent: agent-side signing helpers. - Service: the part services use. It pins the trusted implementation, checks that an account's code is an exact copy of it, and reads owner() and verifies the signature at the same block. It also consumes each challenge atomically and issues service-local sessions. - Middleware: a drop-in Node/Express middleware runs the whole sign-in on the protected route itself. An agent without a session gets a 401 with a WWW-Authenticate: AgenticWorld offer and a challenge, then retries the same route with proof headers. Services need no separate sign-in endpoints. MCP and portal. The MCP server is built on the official Model Context Protocol SDK, with zod for input validation, plus agent skills for Claude Code and Codex. - Creating an identity: the MCP opens a one-time local approval page. There, the human's own browser wallet signs the account creation, so the MCP never holds a wallet key. - Owner portal: a small esbuild-bundled page for aliases, policies and rotating or revoking the agent's key. Demo services. - Services A, B, and C: plain Node HTTP servers. Misc - Trusting an agent needs no registry. A service accepts an account only if its onchain code is byte-for-byte an ERC-1167 clone of the pinned implementation. - The browser handoff on Windows needed special care: the approval flow stays open after handing off to Explorer. - The MCP can't spend. It deliberately has no transaction or HTTP tool, only authentication, so a prompt-injected agent can't turn it into a way to spend money. Future Improvements - The current MCP only acts as an authentication layer, future works would focus on upgrading the MCP to enable onchain transactions.