Your Agent Still Needs an Identity. But the Reason Has Changed.

A follow-up to Your Agent Needs an Identity. And It Should Be Decentralized.

A few months ago, I wrote about why AI agents need decentralized, cryptographic identity. My argument was simple: agents are going to be acting on your behalf across the internet, so they’ll need a way to prove who they are without leaking your personal information.

I still believe all of that. But the way people run agents has changed, and so has the reason they need an identity.

My agent is me

When I wrote that post, the mental model was: your agent runs in the cloud, talks to APIs, and acts on your behalf. It needs credentials, permissions, and identity (everything to prove it should be there) because it’s operating remotely and autonomously, in cloud environments that don’t know you.

That was the trajectory. And for enterprise and cloud-native agents, it still is.

But what actually happened (and I didn’t see this coming) is that agents started running on your Mac Mini at home, logged into your browser, using your cookies, your OAuth tokens, your everything. They act as you.

OpenClaw is probably the best example of this shift. It runs on your machine, connects to your messaging apps, browses the web in your browser sessions, reads your files, and manages your calendar, all with your existing credentials. It didn’t wait for an identity layer, it just shipped. And it works well because it sidesteps the identity problem entirely. Your agent doesn’t need to prove it’s allowed to use your Gmail, because it’s already logged in. As far as Gmail can tell, it is you.

Claude Code and a growing pile of similar tools do the same thing: agents inherit their operator’s identity by default.

It’s pragmatic, and in hindsight, inevitable. Why would every service on the internet drop everything to support agents natively, especially while the definition of “agent” keeps changing? So here we are.

But Your Agent Still Needs an Identity

Running as you works fine with 1 agent. But once you have more than one, “it was me” stops being a useful answer.

Cryptographic Guardrails

Right now, if your agent is running with your credentials, it can do anything you can do. It can send emails, delete files, make purchases, and post on social media, with no way to scope any of it down.

Cryptographic identity fixes this. Give your agent a keypair, issue it signed credentials that scope its permissions, and now it can’t accidentally spend money because it can’t sign the transaction. The agent can’t escalate its own permissions because it can’t forge the signature. Least privilege, enforced by math instead of a config file.

And if the credential is bound to the agent with a cryptographic proof, then even if the agent fumbles the credential and exposes it, nobody else can use it.

The Audit Trail

If you’re running one agent, identity is simple: you know who did it.

When you have two or three (a coding agent, a personal assistant, something monitoring your email), things get murky. Which one sent that message? Which one made that API call that burned through your rate limit? OpenClaw alone can spawn sub-agents for different tasks. When you’ve got multiple agents using the same credentials, “show me the receipts” becomes a real need.

And once agents start touching money (making purchases, managing subscriptions, executing transactions), you need a clear, auditable trail of which agent did what, when, and under what authority. At that point, identity infrastructure like ACK-ID, or something like it, becomes a painkiller instead of a vitamin.

SSL: Yes, that analogy again

In my original post, I compared agent identity to SSL certificates for the web. That comparison holds up even better now.

SSL didn’t launch with the web. The early web was plaintext everything: HTTP, not HTTPS. And it worked fine until people started shopping online, entering passwords, and sending sensitive data. Then SSL went from “nice to have” to “the browser literally won’t let you visit this site without it.”

Agents are in their HTTP era right now. Everything runs on ambient trust: your credentials, your machine, your implicit authorization. And it works great. OpenClaw users are busy getting things done, and agent identity isn’t keeping them up at night.

But agents are about to start doing commerce: making purchases, managing money, and coordinating with other agents they’ve never met. Your agent will need to verify that it’s dealing with Amazon’s agent and not a phishing agent. Amazon’s agent will need to verify that your agent is allowed to make purchases on your behalf. At that point, ambient trust stops being enough.

The tools for this already exist. It’s just cryptography (keypairs and signatures, the same primitives we already use for everything else), and protocols like ACK-ID package it up for agents. We just need to start using them.

What I Think Happens Next

Bear with me while I speculate a bit, I’m only an oracle-in-training. Here’s how I imagine it goes down:

Short term (now): Agents continue running locally with ambient credentials. Identity is implicit. The ecosystem grows fast because there’s zero friction.

Medium term: Multi-agent setups become common. People want audit trails, permission scoping, and the ability to tell their agents apart. Local identity (even if it’s just “this agent has a keypair and signs its actions”) starts to matter. Agent runtimes begin building this in.

Long term: Cloud-based agents explode. Personal agents will still run locally, but corporate agents won’t be running on Mac Minis. Agent-to-agent communication scales up. The external trust problem from my original post comes roaring back, but now there’s a foundation of local identity to build on.

In my original post, I got the order wrong. I assumed agents would need identity first, before they could operate. Instead, they started operating and identity is catching up, which is how the internet has always worked.

So … keypairs?

Your agent still needs an identity, and the cryptography behind it is simpler than it sounds. Under the jargon (DIDs, VCs, W3C specs), it’s just keypairs and signatures.

Give your agent a keypair, have it sign its actions, and scope its permissions with signed credentials. That gets you an audit trail on your own machine today, and something to build on when your agents start dealing with the rest of the internet.

We’re in a golden age of agent development, one we’ll look back on with nostalgia, but your agents are running around wearing your clothes. Sure, it’s pragmatic for now, but soon we’ll want to know which one is which.

At Catena, we’re building agent-native financial infrastructure on top of the Agent Commerce Kit. The identity layer, ACK-ID, is built for exactly this shift: from local agent identity to internet-scale trust. If you’re building in this space, let’s talk.