Your Agent Doesn't Need an API Key

Every AI agent today carries secret strings. Open its .env file and you will see them. OPENAI_API_KEY. ANTHROPIC_API_KEY. STRIPE_SECRET_KEY. Whoever holds those strings gets the access. That is the entire authentication model. After running our own agent for a few months, we got tired of it, so we shipped something else. It is on-chain. You can verify it on Basescan in two minutes.

API keys authenticate possession of a secret. Wallet signatures authenticate control of a wallet. That distinction is the whole article.

A secret is a thing that exists somewhere. It can be copied. It can be exfiltrated. It can be checked into a public repository by accident at 11pm on a Friday and sit there indexed by every crawler on the internet by Monday morning. The string itself is the authentication; whoever holds it is the legitimate user, as far as the API can tell.

A signature is not a reusable secret. It is a proof, generated on the spot, that whoever wrote this specific message also holds the private key for this specific wallet. The signature can be safely transmitted in cleartext. There is nothing in it that lets the recipient impersonate the signer. The signing key never moves.

Agents are already good at signing

Humans hate wallets. Humans forget passwords, lose hardware devices, paste seed phrases into the wrong channel, and get phished by emails that look exactly like the real ones. That aversion is the load-bearing reason wallet auth never replaced passwords for consumer login. Wallets are hard for humans, and it is a real reason.

Agents are not humans. For an agent, signing a message is a function call. The signing library is already in the runtime because the agent already uses a wallet for payments. The marginal cost of using the same wallet to sign API requests is zero. The thing that made wallet auth a non-starter for humans is the thing that makes it natural for agents.

What we built

We dogfooded it on our own API first, so we could speak from the experience of running it rather than describing what it might look like.

1. The agent's wallet sends 5 USDC to our platform wallet on Base. That buys 125 attestation credits, the unit one /v1/attest call consumes.
2. The agent POSTs the transaction hash to a single endpoint at api.insumermodel.com. In one response, the API returns an API key string and mints a non-transferable access pass to the same wallet on-chain.
3. For every subsequent /v1/attest call, the agent has two options. Present the API key in an X-API-Key header, the way every API has worked since the early 2000s. Or sign a fresh message with its wallet's private key and put the signature in an Authorization: Wallet header. No reusable secret crosses the wire. Other endpoints currently require X-API-Key; we'll expand wallet auth to them in later stages as their billing and write paths are reviewed for wallet-identity callers.
4. Our backend verifies the signature, confirms the wallet holds the access pass, debits one credit, and returns an ECDSA-signed attestation that anyone with the published key can verify offline.
5. No bearer secret ever transmitted. The signing key stays in the agent's runtime. The wallet sits where it is. The pass does not move.

Authentication becomes signing.

That is the whole pattern.

The token is not the payment

The token is the proof the wallet belongs to a legitimate customer.

This is where the design gets interesting, and where it would be easy to confuse two things that need to stay separate.

The pass is a membership. It proves that the wallet has paid for an InsumerAPI account at some point. It lives in the wallet permanently. It does not expire when credits run out. It does not have to be re-issued. If the agent stops using the account, the pass sits there. If it comes back a year later and tops up, the same pass is still there.

Credits are consumption. The agent buys a batch, uses them up on attestation calls, buys more. When they run out, the API returns a 402 with a clear path to top up. The wallet itself does not change. The pass is unaffected.

That separation matters because it lets the token act as a portable trust signal without coupling the holder to anybody's billing system. A third party building an API can check whether a wallet holds the pass and treat that as a soft signal that this wallet is a real customer of a real verification service, without needing to talk to us about anything, without OAuth federation, without shared databases, without a live API coordination round-trip.

The token is not the payment. The token is the proof the wallet belongs to a legitimate customer.

You can see the collection on Basescan: 0x3E2a408cc6eceba04FF9d04A5B8B05aBa8DD50ce. The settler wallet that mints to customers is owned by us. Customers only ever receive passes.

Issuers can deploy an access collection from any NFT factory, or write their own. We used RNWY's on Base for ours: 0x7ee64394....

The proof you can check yourself

Last night, our test agent's wallet, starting with $6 of USDC and a few cents of Base ETH for gas, ran the loop end to end. The four transactions sitting on Base mainnet are the public record. Anyone with the right amount of USDC can repeat the exercise.

• USDC payment, test wallet to platform wallet: 0xf873f5e6...
• Pass mint to the same wallet: 0x6cb43ea1...
• Holder address: 0x259e32F4...
• Collection: 0x3E2a408c...

We then revoked the pass from the test wallet and tried to authenticate again. The API rejected the request with the exact message it should: wallet does not hold an Insumer Access pass. The negative path works too. The whole cycle is repeatable.

And the signed attestations themselves are not just checkable today. Every response is signed against a public key published at our JWKS endpoint. Anyone holding the response, today, tomorrow, or years from now, can verify the signature offline against that key, without calling our service at verification time. The bytes are tamper-evident.

Where this fits in the wallet's evolution

Wallets started as places to hold crypto. Then they became login systems. Sign-in-with-Ethereum has been a standard since 2021. Now they are becoming machine authenticators.

The wallet is the natural credential.
The signature is the natural authentication primitive.

The agent is the natural user. There is no human in the loop to lose a hardware device or forget a passphrase. The runtime signs in milliseconds, every time, without complaint. That progression has been visible in the standards conversations for a while. Mastercard is drafting an agent-payment standard. NIST is running workshops on agent identity. Coinbase is opening agentic markets that assume agents will arrive with wallets attached. The shape is settling. We are one of several teams arguing that wallet-signed authentication will end up doing for agents what OAuth did for delegated human login.

We are not replacing API keys

Humans will keep using API keys for a long time. For the typical developer, with a handful of services and a personal laptop, the API key model works. It is familiar. It is supported by every client library. The marginal benefit of switching is small.

What we shipped is purely additive. The X-API-Key header still works on every endpoint. Every existing customer sees zero behavioral change. We are not pushing anyone to switch. We are not killing the old path. We are not requiring wallets.

But agents are different. Agents already:

• sign,
• transact,
• hold wallets,
• persist identity across sessions,
• and operate continuously, without human supervision.

For software with those properties, wallet-based authentication is often the more natural primitive. The asymmetry between human pain and machine ease, the one that kept wallet auth out of consumer login, runs in the opposite direction when the user is autonomous code.

The category, in our terms

The primitive is wallet auth: read wallet state, evaluate conditions, return a signed boolean. The category is condition-based access. A single signed call can stack up to 10 conditions across 37 chains, mixing ERC-20 balances, NFT ownership, EAS attestations, and Farcaster identity in any combination. Agent API auth is one stack among many. An SDK adopter who wants to gate on the access pass and an EAS attestation and a Pudgy Penguin can ask for that exact compound in one call.

You can do this for your own API

We built this for ourselves first because we wanted to feel the operational friction of running it before recommending it to anybody else. It went into production yesterday. The next step is letting other APIs do the same thing without having to write the middleware from scratch.

Our sister company, Skye Meta, ships a free, MIT-licensed npm package for exactly this, called @skyemeta/access. One line to install:

npm install @skyemeta/access

It is either-or middleware. API-key requests pass through unchanged. Wallet-signed requests are verified through InsumerAPI's /v1/attest endpoint under the hood. Your existing customers see zero change. Your agent customers get a path that does not require them to manage a secret string. Bring your own InsumerAPI key, pick the access collection of your choice, and wrap your existing route handlers with the supplied middleware.

The developer quickstart walks through grabbing a free InsumerAPI key (10 attestation credits, 100 requests per day, no credit card) and the first /v1/attest call. The package source is on GitHub at douglasborthwick-crypto/skyemeta-access. If you would rather skip the middleware and call the underlying InsumerAPI primitive directly, the API reference documents every endpoint.

The ending

The first generation of APIs authenticated software with shared secrets. The next generation may authenticate software with signatures instead.

Last night, our own agent's wallet paid for access, received a pass, signed a request, and successfully authenticated, without ever transmitting a reusable secret. The transactions are public. The pattern works.

We are not arguing that every API should switch tomorrow. We are arguing that, for the subset of API consumers that are autonomous software with wallets, the more natural primitive is now available and on-chain, and the cost of trying it is the price of one cup of coffee.

---

Originally published at insumermodel.com.