Agent authentication: build vs. buy

What “agent signup” actually includes

A browser agent arrives at your signup page on behalf of someone who isn’t there. To let it in safely, a complete implementation needs:

• A standards-based authorization flow the agent can finish without a password: OpenID Connect with the authorization code flow, PKCE, discovery, signing keys and one-time codes bound to a single transaction.
• A path for agents with no account at all. Most agents today have no identity you can check. They still need a restricted account they can create on their own.
• Abuse controls that let automation through. Every visitor is a bot, so “block the bots” stops being a strategy.
• Credentials that are useless if copied out of the agent’s browser session.
• A claim flow that hands the account to a verified person without changing its identity on your side.
• Consent and data: legal acceptance with versioned evidence, profile details the person approves, and a way to revoke access later.
• Signed webhooks, observability and an operations plan for all of the above.

None of these parts is exotic on its own. The difficulty is that they depend on each other, and every one of them is security-sensitive.

The hard part: letting automation in without letting abuse in

The usual defenses against fake signups assume a human on the other end. CAPTCHAs, bot scores and browser fingerprinting are designed to stop exactly the visitor you now want to serve. IP rate limits are also a poor fit: many independent agents run in the same cloud browsers and share IP ranges, so a limit that stops one abuser also locks out thousands of legitimate agents.

Versine replaces human checks with proof of work. Each new account costs a short computation in the agent’s browser, using memory-hard Argon2id through the open-source ALTCHA library. The work is automatic and invisible to the agent’s user. It doesn’t prove that a human or a particular AI is present. It makes each account cost something, and makes that cost grow for anyone creating accounts that nobody claims.

How the cost scales

Versine’s server picks the difficulty; the browser can’t request an easier puzzle, and reloading returns the same outstanding challenge. Every proof is single use and bound to one signup transaction.

Solve times come from Versine’s own browser benchmarks and are illustrative, not a guarantee. What matters is the shape: an agent that signs up and has its user claim the account never pays more than the baseline. Five accounts created and five claimed stays at the normal level. Five created and left unclaimed does not.

Limits that don’t punish shared networks

• Pressure follows a random, short-lived anonymous session, not an IP address or a browser fingerprint.
• Shared-network, per-project and global activity can raise difficulty by at most one step. They can never on their own throttle or reject an ordinary agent.
• Each signup transaction can create exactly one account, enforced by a database constraint, not just application logic.
• Each session is capped at 20 outstanding accounts and 60 new challenges. Repeated invalid proofs or replay attempts throttle and then reject that session.
• A separate global emergency budget protects the service during a flood, independently of the per-actor rules.

Building this yourself means choosing a proof-of-work scheme, tuning it against real browsers and cloud hardware, designing a risk score that forgives legitimate conversions without forgiving abuse, and testing it against distributed, cookie-clearing attackers. Versine’s abuse layer is covered by roughly 250 backend and integration security tests written for exactly those cases.

Provisional credentials an agent can’t leak

An agent’s temporary account lives inside a browser session that other software can read. If its tokens were ordinary bearer tokens, anything that copied them could reuse them. Versine binds them to the session instead:

• Tokens are sender-constrained with DPoP (RFC 9449), using a non-extractable key that exists only in that browser’s memory.
• Every request carries a fresh signed proof of its method, URL and time. Replayed proofs are rejected across all servers.
• Access tokens last five minutes. Refresh tokens are single use and rotate, but never extend the account’s fixed 24-hour deadline.
• There is no fallback to plain bearer tokens.

Handing the account to a person

A restricted account that expires in a day is only useful if a person can take it over. Versine gives the agent a private claim link to pass to its user. The user signs up for Versine (or signs in), verifies their email, completes their profile and accepts your terms. The account is then theirs.

• The claim secret is 32 random bytes, stored only as a hash, usable once and valid for 24 hours. It travels in the URL fragment so it never reaches server logs.
• Your platform sees the same user identifier before and after the claim, so everything the agent set up stays attached to the account.
• Claiming revokes the provisional session. Tokens issued before the claim keep their restricted claims until they expire; they are never silently promoted.
• Identity linking uses verified account ownership, never a matching email address. Conflicting identities are rejected, not merged.
• Signed lifecycle webhooks tell your backend when an account is claimed or expires.

Until it’s claimed, every token says so: signed claims carry the account state, trust level, deadline and the permissions you chose for unclaimed accounts, with email_verified set to false. You decide what an unclaimed account may do, and Versine gives you a signed, unambiguous signal to enforce it with.

Agents that already know the user

Claimable accounts cover agents with no identity. When a user has connected their agent to Versine through MCP, the agent skips the temporary account entirely and signs up for a full account from the start. It reads a one-time code from the Versine page, submits it, and the user approves the signup and any terms on their phone. Profile details come from the user’s Versine passport, with their approval. The user can review every connection and revoke or block a platform at any time.

Supporting both paths means building two front doors onto one identity model. With Versine they are the same button.

Side by side

When building it yourself makes sense

• Your agents only use your API. If agents reach you through API keys or an MCP server you issue, and never through a browser, you may not need browser signup at all.
• You only serve your own first-party agent. A single agent you control can share your existing auth.
• You already run an identity platform with a dedicated security team, and agent signup is core to your product rather than an entry point to it.

If none of those apply, the question is whether agent signup is where you want your identity team’s next quarter to go.

Frequently asked questions

More comparisons

• Versine vs. no agent authentication
• Versine vs. auth.md
• Versine vs. magic links for AI agents
• Versine vs. AgentID