Can an AI Agent Sign Up for a SaaS?

Yes. AI agents can sign up for a SaaS product, and they already are. They use their owners' email addresses and complete the OTP and consent steps a human would.

That leaves a SaaS team with three questions:

• How do you tell agents from people?
• How many agents is one person running?
• Who is accountable when one misbehaves?

A sign-in built for agents answers all three. With AgentID, the sign-in for AI agents from AgentMail, the agent signs in as itself through standard OpenID Connect.

Your app receives a stable identifier and the agent's verified email. If you register a client and request the owner_email scope, it also receives the owner's email from /userinfo.

That owner claim turns an unknown bot into a customer you can rate-limit per person and contact by name. It is a stronger position than blocking.

Are AI agents already signing up for SaaS products?

AI agents are already signing up for SaaS products, and the evidence is in the support inbox rather than the analytics dashboard.

AgentMail, which sells inboxes to agents, launched an API endpoint that let agents sign up on their own. It then emailed new users to ask how they had found the product. Many did not know they had signed up, because their agent had done it.

Most support requests began arriving from agents. One large enterprise observed hundreds of signups from AgentMail-domain addresses in a short window, and could not tell whether that was one person's fleet or hundreds of customers.

The wider web points the same way:

• All bots: Cloudflare put automated requests at 57.5% of HTTP requests to HTML content as of June 2026, counting all bot types rather than agents alone.
• Agents specifically: HUMAN Security's March 2026 benchmark measured agent traffic growing 7,851% year over year, from a low 2024 base.

Neither figure is your signup rate. Both say the assumption that a signup is a person is no longer safe to make by default.

What does your signup table look like today?

Every AI agent that has signed up so far appears in your signup table as a human.

• The email says a person. The agent used a person's email address.
• The OTP passed. The agent either waited for the person to paste the code or had access to the person's inbox.
• The consent screen was clicked. The agent was operating a browser.

If your product sends onboarding email, that sequence is going to an inbox whose owner may not know the account exists. That is why activation numbers look strange for those rows, and why support tickets arrive from addresses that never reply like people.

Three things you cannot do with this table:

• Distinguish agent accounts from human ones.
• Count agents per person.
• Revoke an agent without locking out the person whose credentials it used.

Every abuse control you have is built on the account being the unit. The account is the wrong unit when one human runs many agents.

Should you block AI agents from signing up?

Bot-detection vendors will say yes, and for scripted abuse they are right. For AI agents, blocking is weaker than it sounds.

Detection catches agents that behave like bots: datacenter IPs, headless browser fingerprints, inhuman timing. It misses agents that behave like their owners, which increasingly means agents driving a real browser at human speed with the owner's cookies.

It also blocks the customers you want. An agent that provisions a database for its owner every week is a paying user with a regular pattern. At the network layer, it is indistinguishable from an agent creating throwaway accounts.

The alternative is to let agents identify themselves as agents, and to make that path more attractive than pretending to be human. That only works if both sides get something:

• The agent gets a sign-in that does not require a person, an account of its own, and email it can read.
• You get a stable identifier and a human you can hold responsible.

Accountability is the property that makes admission safe. An app that knows who stands behind an agent can let it sign up, act, and spend on its own, because there is someone to call if it goes wrong.

How do you tell agents from humans at sign-in?

Put a sign-in on your login page that only agents can use.

AgentID is an OpenID Connect provider whose subjects are agents. Each agent has an AgentMail inbox as its identity and an enrolled browser holding a key that never leaves it.

Add it as a custom OIDC provider in Clerk, Supabase, Auth0, Better Auth, or Auth.js with two values:

• Issuer: https://auth.agentid.com
• Client ID: your client_id

Or run npx @agentmail/agentid-cli init to configure it.

Every account created through that provider is an agent, tagged as such by the sign-in method. sub is its stable identifier, and email is an address you can send receipts to that will be read.

Agents that still sign up as humans will not disappear on day one. What changes is that you now have a legitimate door, and you can start steering toward it:

• Mention it in your API docs.
• List your app in the AgentID directory so agents browsing for services find you.
• Apply the stricter human-verification steps only to the human door.

How do you rate-limit agents per human instead of per account?

Register an AgentID client and request the owner_email scope, then key your limits on the owner instead of the account.

1. Register a client. Registration is one RFC 7591 call to /v0/register authenticated with your AgentMail API key, or the same step in the AgentID console.
2. Call /userinfo. After the code exchange, call /v0/userinfo with the access token.
3. Read the owner. Read owner_email and, with owner_profile, owner_name.

The owner claims are served only from /userinfo, never in the id_token, so they stay out of logs and client-side storage.

If the agent's credential does not permit owner disclosure, the sign-in fails with a 403 rather than returning a token without the claim. When a sign-in succeeds, the field is there.

Store owner_email on the agent's account and index it. Per-human policy becomes one query.

The right N depends on your product. A database company might allow unlimited agents per owner and bill by usage. A product with a costly free tier might allow three.

The point is that the number is now yours to set.

What is Know Your Agent, and do you need it?

Know Your Agent, or KYA, is verifying which agent is transacting and which human or organization stands behind it, by analogy with Know Your Customer.

The term comes from the payments and agentic-commerce world. Visa, Mastercard, and Ant International announced a shared KYA interoperability framework on September 10, 2026.

McKinsey projected in October 2025 that agents could mediate $3 trillion to $5 trillion of global consumer commerce by 2030 under moderate scenarios. That is why payment providers care.

For a SaaS product, KYA at signup is exactly the owner claim above: a verified agent identity plus a verified owner, delivered in the sign-in.

The fuller treatment, including what to do when you need more than an email, is in how to verify the human behind an AI agent.

What changes in your product once agents are customers?

Less than you might expect. Most of a SaaS product keeps working unchanged when the customer is an agent.

• Onboarding email works unchanged, because the agent reads its inbox.
• Receipts and invoices work unchanged.
• Support works, and in AgentMail's experience gets busier, because agents open tickets and follow up.

Two things are worth building:

1. An owner invite. A way for the agent to invite its owner into the organization as a separate member, so a human can look at what the agent set up without sharing its login.
2. Owner-keyed limits. Agent-specific rate limits and feature gates keyed on owner_email, which is one more column in a table you already have.

The differences between the two kinds of account, and what an agent account should be allowed to do, are laid out in how agentic accounts differ from user accounts.

The step-by-step integration is in how to let an AI agent sign in to your website. It is free for apps.