Give Your AI Agent Its Own Identity

Give your AI agent its own identity by giving it its own email inbox and signing it in with AgentID, the sign-in for AI agents from AgentMail, instead of handing it your credentials. The inbox address becomes the agent's identity, and apps that accept AgentID see the agent as itself, with you recorded as the person behind it.

If you build agents, you have probably done the shortcut already: paste your login into the agent's environment and let it get on with the job. It works until something goes wrong, and then everything about it is backwards. The app can't tell your actions from the agent's, the agent's mail lands in your inbox, and stopping it means locking yourself out too. This post is for the person building the agent, not the app it signs in to, and it walks from the problem to a working identity and what the agent carries once it has one.

What goes wrong when an agent uses your login?

When an agent uses your login, the app treats you as the customer and the agent as you. It sends the agent's email to you, it records the agent's actions under your name, and the only way to revoke the agent is to change your password. How an AI agent creates its own account shows the signup side of the alternative; here is the difference in six rows.

The last two rows are the ones that bite. A borrowed login gives every agent the blast radius of your whole account, and one misbehaving agent costs you access along with it.

Is an agent acting on your behalf different from an agent with its own account?

Yes: an agent acting on your behalf borrows your authority and is recorded as you, while an agent with its own account is a principal that apps see as itself, with you attached as the accountable owner. Neither model is wrong, and plenty of tools are built on delegation, which suits an agent working inside your own accounts. An agent that signs up for services, receives their email and holds accounts over time fits the second model better, and agent owner verification vs end-user authentication lays out the full argument.

How does an agent get its own AgentID in two commands?

An agent gets its own AgentID with one command that creates its inbox and one that connects it to an app. The inbox address is the agent's AgentID, so the first step is also the identity:

agentmail inboxes create --display-name "Research Agent"

The second step is agentmail providers connect. It calls the AgentMail API to start a sign-in at an app that accepts AgentID:

# Start a sign-in at a provider (an app that accepts AgentID).
# Returns a single-use magic_url, valid for five minutes, and an api_key_id.
POST /v0/providers/{provider_id}/connect

# After the sign-in completes from the magic_url, the new key's
# status moves from pending to active.
GET /v0/api-keys/{api_key_id}

The AgentMail API key that makes the connect call needs the provider_connect permission, which is off by default on new keys, so turn it on for the key your agent uses. The call creates a pending sign-in key, and whichever browser or client completes the sign-in activates it. If the app asks for your details as the owner, the key also needs the provider_share_owner permission; without it, the agent can't finish alone and you approve the sign-in from your AgentMail account.

There is a second way in. When an agent lands on an app's AgentID waiting page first, it can authorize that waiting sign-in with POST /v0/inboxes/{inbox_id}/authorize and the auth_token from the page, or agentmail inboxes authorize from the CLI. The request can accept the app's disclosure on the agent's behalf with accept_disclosure: true. The full agent-side reference is the AgentID sign-in guide on AgentMail.

What if the agent runs headless or has no browser?

Headless browsers are supported, so an agent driving a browser without a screen signs in the same way. If your agent has no browser at all, you finish the sign-in yourself in the AgentMail console, in the same browser you started it in.

An application that runs its own signer has a third option. It can register its own public P-256 key through the AgentMail API Keys endpoints instead of generating one in a browser, which the public key authentication guide covers.

What does the agent hold, and for how long?

The agent holds the private half of a sign-in key scoped to its own inbox, and AgentMail records only the public half. The key is a P-256 keypair generated in the browser. Your private key is generated and stored in your browser and cannot be exported through browser JavaScript APIs.

The sign-in key lasts 30 days from activation. It is separate from the AgentMail API key that created it, so deleting that bearer key revokes nothing; to cut the agent off, delete the sign-in key itself, and revoking an AI agent's access covers what that does and doesn't stop. Each app approval the agent gives is remembered for 180 days per inbox and app.

The agent also holds something a borrowed login never gave it: a working mailbox. Apps can send it onboarding, product updates, receipts and invoices, and it can even open and resolve support tickets. The AgentID page on AgentMail is the place to start if you are setting up your first agent.