Per-agent tokens for MCP servers: what operators told me, and the design that came out of it

A few weeks ago I set out to give every AI agent its own cryptographic identity. Then I asked the people who run MCP servers what they actually needed. Most of my first idea didn't survive. This is what did.

The problem

A user connects Claude, ChatGPT, Cursor and a couple of their own agents to the same account on your MCP server. One of them starts misbehaving: looping, over-reading, doing something the user didn't intend. Today, cutting off that one agent usually means signing the user out everywhere, or rotating a key every agent shares.

What I got wrong first

• "Servers want keyless agent identity." They don't. A free, self-made ID costs an abuser nothing, so it can't protect a free tier. One operator watched accounts get farmed at 70+ an hour; a stable ID wouldn't have helped.
• "Revocation is painful for everyone." It isn't. Many operators already tie keys to users and revoke the user.
• "Builders will pay for a hosted agent wallet." Three said no outright. They keep secrets in keychains or Vaultwarden and don't want to hand credentials to a startup.

What operators actually said

• Anything costly stays on their own accounts. Paid tools, writes and anything that spends money need their own sign-in, credits or billing.
• Identity they didn't issue is worth little, unless there's a contract. One security engineer said outside credentials would look like an attack in their SIEM. Federated partners are accepted only under an agreement. It's a business question first.
• Reads are where outside identity can help. Two operators said a signed, per-agent token could earn a looser limit on cheap read tools. One runs a hosted notes server and wants per-agent revocation on its search and read tools without re-authing the whole account.
• Revocation has to be fast. If revoking takes a day, you've outsourced vetting to someone slower than your own account system. A minute of caching is fine for reads. Writes need a live check.
• Scope the dangerous tools. Anything that can send, delete or spend gets its own scope. Reads can stay per server.

The design now

It's deliberately boring: a standard JWT from an issuer you verify against a public key.

{
  "iss": "https://issuer.example",
  "sub": "user_123",
  "agent_id": "cursor-laptop",
  "aud": "https://your-server.example/mcp",
  "scope": "search_notes read_document",
  "iat": 1762700000,
  "exp": 1762700900,
  "jti": "6f1c..."
}

• Verification: signature against the issuer's JWKS, then issuer, audience and expiry. Any JWT library does this.
• Revocation: a list of revoked agent IDs. Reads cache it for up to 60 seconds; writes check it live.
• Scopes: reads per server to start; send, delete and spend get their own scopes.
• Rollout: observe-only first. Tokens are checked and logged, nothing is blocked, and existing auth is untouched.

What's still open

• Writes. Operators want per-agent control most on dangerous tools, but they only trust identity they issue. For writes, the server probably has to be the issuer.
• Whether anyone pays for this. Nobody has named a price yet.
• Whether it beats what OAuth already gives you. One client registration per agent gets you part of the way.

Looking for testers

If you run an MCP server that holds people's notes, memory, documents or meeting data, I'm looking for one or two more operators to test this on read tools.

• About 30 minutes, with me helping: a small snippet and two settings.
• Observe-only. Nothing is blocked; remove the setting and it's gone.
• You get per-agent visibility in your logs, a one-agent kill switch on reads, and a short write-up of the results, including what didn't work.

Comment or reach out if you're interested. If you'd never use this, a sentence on why helps just as much.

Disclosure: I'm building an open-source library in this area, so I'm biased. Drafted with help from Claude, edited by me.