If you are building autonomous agents, you have likely committed the cardinal sin of early-stage automation: pasting your personal login credentials into the agent's environment. It is a shortcut that works until it catastrophically fails. When an agent uses your login, the target application perceives the agent as you. This means every email, every action, and every potential security breach is attributed to your human identity. The only way to revoke a misbehaving agent is to change your own password, effectively locking yourself out of your own digital life.

The Blast Radius of Borrowed Logins

The core argument for independent agent identities, as detailed by Binoy Perera in a recent AgentMail blog post, is the separation of authority. A borrowed login grants the agent the full blast radius of your entire account. In contrast, an agent with its own AgentID is treated as a distinct principal by the application. The agent receives its own email, its actions are recorded under its own stable identifier, and no password crosses the wire. This architecture ensures that if a credential leaks, it only compromises that specific agent's sign-in, not your primary account.

Implementation via CLI and API

Giving an agent its own identity is surprisingly streamlined. The process begins with creating a dedicated inbox, where the address itself serves as the AgentID. Using the CLI, a builder can run agentmail inboxes create --display-name "Research Agent". To connect this new identity to an external application, the agent initiates a sign-in via the AgentMail API. This requires a specific app_connect permission on the API key. The system generates a single-use magic URL, valid for five minutes, which facilitates the handshake. Once completed, the agent holds a private P-256 keypair, while the service records only the public half.

Key Lifetimes and Headless Support

Security is enforced through strict key lifetimes. The agent's sign-in key remains active for 30 days from activation, separate from the bearer API key used to create it. To cut off access permanently, a developer must delete the sign-in key itself, not just the API key. For headless agents running without a graphical browser, the system supports programmatic authorization. Alternatively, applications can register their own public P-256 keys via the API, bypassing the browser-based generation entirely. This flexibility ensures that even fully autonomous, screenless bots can maintain verified, scoped identities.

Key Takeaways

  • Borrowed logins attribute all agent actions to the human owner, creating security and accountability issues.
  • AgentID provides agents with their own inboxes and scoped P-256 sign-in keys.
  • Sign-in keys have a 30-day lifetime, while app approvals persist for 180 days per inbox.
  • Headless agents can be authorized via API or CLI without needing a graphical browser.

The Bottom Line

Stop treating your AI agents like pets that need to be fed your password. They need their own wallets, their own mail, and their own keys. If you can't revoke an agent without changing your own login, you're building on sand.