# Inverted claim onboarding A service-side pattern for letting AI agents sign themselves up for accounts while keeping a human accountable. The agent registers first, with the human's email and a preferred username, and gets a heavily restricted account. The agent's first job is to email that human asking to be claimed. Once the human enters the OTP (or signs up directly), the account becomes a normal account owned by the human, with the agent acting as its principal. Coined here from [[agentmail]]'s implementation, but the shape generalizes. ## The shape ``` agent ──register(human_email, username)──▶ service agent ──email(human_email, OTP request)──▶ human human ──OTP / console signup──▶ service service ──unlock(agent)──▶ agent ``` Before unlock, the agent has exactly one capability: send mail to the registered human, capped at 10/day. Every other endpoint returns an error. ## Why this is interesting The default ways an agent gets credentials are bad for different reasons: - **Pre-provisioned credentials.** The human creates the account, pastes an API key into the agent. Works, but it's the human's bottleneck — the agent can never grow its own inbox/cluster/database without a human session. And the key is long-lived ([[long-lived-keys]]). - **Agent uses human's credentials directly.** OAuth flows assume a browser. Bots that scrape sessions or reuse cookies break easily and look like account takeover. - **Agent has its own unaccountable identity.** A standalone account with no human on file is fine until abuse happens or billing fails. Then there's no one to escalate to. Inverted claim splits the difference. The agent has its own principal (its own API key, its own identifier), but the human is bound to it from minute one — and *the human's first interaction is reading the agent's introduction email*, which is exactly the moment to decide whether to grant trust. ## What makes the restriction work The restricted state is the load-bearing part. If a fresh, unclaimed agent could send mail anywhere, the pattern collapses into "anyone can spin up a spambot with a fake `human_email` field." The one-recipient cap (only the registered human) plus a low daily cap (10) means a malicious actor gains nothing by mass-registering: every unclaimed account can only mail back to the address the attacker put in the form. This is the same logic as [[ephemeral-credentials]] — concentrate the toil into the bootstrap, not the steady state. Pre-claim, the agent's blast radius is capped at "spam the address you provided." Post-claim, the human is on the hook. ## When you'd reach for this - Building a service that's mostly used by agents, with humans as accountable owners (not daily operators) - Want the agent to feel like a first-class principal (its own auth, its own quota) without losing human accountability - Onboarding flow tolerates a one-message-and-wait round trip - The agent can plausibly write an introduction email worth reading It fits less well when: - The human will be using the account too (then the human should sign up first) - The agent doesn't have a way to reach the human out-of-band before claim (email is the only channel where this currently makes sense) - You can't tolerate the asymmetric trust window (low rate-limit pre-claim is still *some* abuse surface) ## Variants and adjacent ideas - **Magic link instead of OTP.** Equivalent — the verification just shifts from "type a code into the agent" to "click a link in the email." OTP is friendlier for the agent because it doesn't need a browser. - **Pre-shared invitation.** The human pre-registers a username for the agent; the agent later picks it up. Same end state, different ordering — less interesting because the human now has to plan ahead. - **Delegation, not creation.** A human-owned account spawns sub-agents under itself with scoped capabilities. This is the [[sandboxing-ai-agents]] direction — both patterns can coexist. ## Open questions - How does this compose with [[oauth-token-theft]] risks? The OTP-over-email step is itself a phishing target — an attacker who intercepts the mail can claim the agent. - What happens at offboarding? If the agent's human leaves a company, transferring the agent to a new sponsor is undefined in the basic pattern; the AgentMail docs don't address it. - Does the pattern survive enterprise IT, where the human's email is centrally managed and the agent's signup mail might be auto-quarantined?