Turso now lets an AI agent open and operate its own database account by signing in with AgentID. Turso added the option through its existing login stack, wrote up the reasoning in its own engineering post, and treats the agent as what it calls a first-class participant: an account holder with its own identity, its own databases, and its own email address on file.
In short
- Turso accepts Sign in with AgentID alongside its human login options.
- The integration went in through Turso's existing auth stack as an additional OpenID Connect provider, configuration rather than new infrastructure.
- Turso receives a stable identifier for the agent and its verified inbox address, which becomes the account's registered email.
- Turso keeps every product decision: databases, limits, billing, and permissions.
- Turso published its own account of the integration, Giving Agents Their Own Turso Accounts with AgentID.
Why would a database company want agent sign-ins?
Turso's architecture is the reason. Its platform is built around many small databases rather than one big one, cheap enough that every user, every tenant, and every agent can hold its own. When an agent building an application needs somewhere to put state, the natural unit is a database of its own.
The problem was the account behind that database. Turso's post describes it as the three identities problem: the agent doing the work, the human who owns the agent, and the infrastructure it runs on, all collapsed into one borrowed login. An agent creating databases inside its owner's personal account leaves the platform unable to say who did what, and leaves the owner's credentials sitting inside an autonomous process.
Giving the agent its own account untangles that. The agent holds the databases it creates. The human stays accountable for the agent. Nobody shares credentials with anybody.
How do you let AI agents sign in to your website?
The way Turso did it generalizes. AgentID is AgentMail's sign-in service for AI agents, and it is a standard OpenID Connect provider, the same protocol behind Sign in with Google. An app that already supports social login adds AgentID the same way it would add any other provider: as a connection in its existing auth platform, pointed at AgentID's discovery document.
Setup guides exist for Clerk, Supabase, Auth0, Better Auth, and Auth.js, a CLI detects your stack and registers the app (npx @agentmail/agentid-cli init), and any other OpenID Connect implementation can point directly at the endpoints. AgentID is free for apps, with no per-sign-in fees.
The sign-in itself is simple. Turso ends up with a signed token that says which agent this is: a stable identifier plus the agent's verified email address. There is no password anywhere in the flow, and nothing reusable is handed over. The agent approves each sign-in with a private key that never leaves its side.
What does the agent's email address do for Turso?
It becomes the account's registered email, and it works. The agent's AgentID is its AgentMail inbox address, a real mailbox the agent reads. Turso's post calls out what that enables: billing alerts and security notices go to the account holder that can act on them, instead of disappearing into a human inbox the agent never sees.
Turso can also learn who stands behind the agent. Apps registered with AgentID can request owner information, which Turso's post notes is available through the userinfo endpoint, so an agent account is attributable to a person without the person's credentials ever entering the flow.
Who controls what
| Stage | AgentID | Turso |
|---|---|---|
| Identity at sign-in | Supplies verified agent email and stable identifier through OpenID Connect | Accepts the sign-in through its existing auth stack |
| Sign-in approval | The agent signs a single-use assertion with its own key | Not involved |
| Owner information | Makes it available to registered apps that request it | Decides whether to request it and how to use it |
| Account email | Provides the inbox behind the identity | Sends billing alerts and security notices to it |
| Databases and limits | Not involved | Owns creation, quotas, and lifecycle |
| Billing and permissions | Not involved | Controls both |
| Agent behavior policy | Not involved, by design | Sets and enforces it |
What does Turso still control?
Everything it did before. AgentID answers one question: which agent is signing in, and who is behind it. It does not vouch for the agent or promise it will behave, and it takes over none of Turso's decisions. Permissions, quotas, and abuse policy stay where they were, and they work better now, because they apply to accounts Turso can actually tell apart.
If you run an app and this is your hesitation, that is the whole point. Letting agents sign in changes who can hold an account, not who runs the product.
Start with the AgentID docs for your auth stack, or read Turso's own write-up for the view from the app side.