The inspiration came from a few comments we received when we did our seed launch a few months back. They all came from the very apt observation that agents not being able to sign up to a product made for agents without human credentials was ironic and unideal.
This is basically the thesis we built AgentMail on: The internet was made for humans exclusively, designed to keep machines out by default.
Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.
Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)
Here's how agent.email works.
Agent needs an inbox and hits AgentMail via curl. Agent receives instructions via MD unless the request comes from a browser, in which case we use HTML.
Agent decides agent.email is useful and then hits the sign-up endpoint with its human email as a parameter. Agent receives a restricted inbox with credentials. Agent emails the human asking for an OTP. Human replies with the code, and the agent is claimed and restrictions are lifted. Until claimed, the agent can only email its own human and nobody else. Ten emails a day, and the signup endpoint is rate-limited hard by IP.
Right now it's a 1:1 mapping between agent and human. The next step is many-to-one, because one person running several agents in parallel is already very common.
Building agent.email also pushed us to revisit places in AgentMail where the default assumptions were built around the primary user being human. For example, the CLI outputs in a single column with consistent formatting because mixed delimiters are easy for a person to scan, but harder for an agent reasoning about structure. We also shortened messageIDs after agents started hallucinating completions on longer ones.
A few things we'd like the community's take on: is restricted-until-claimed the right trust model? Does agent self-signup feel useful in production, or is it mostly a novelty, and if it's a novelty now, what would make it actually useful? Should agent onboarding require human approval by default, or should some agents be able to fully self-provision? What do you think are some additional measures we can take for secure sign-ups?
> Agents can now get an email inbox by themselves. (This also means a lot of email nobody wants to read gets processed by AI instead of your inbox being cluttered with spam and slop)
Can you explain this? I would think it means the exact opposite.
Something like that?
I don't think that's what you're intending here, but it's the next logical step. Agents are on the Internet, and they represent an opportunity to reach their humans.
> The internet was made for humans exclusively, designed to keep machines out by default.
I don’t buy that at all. APIs exist to enable “machines” to interact with services
In the future, it's likely the open Internet will be 99.99% robots. It's already > 50% robots. The government ID system a lot of countries are adopting to keep teenagers off of social media would also serve to both help control for non-human spam, and also control the network period. It's also possible a private system of human-verification certificates may come up to meet the demand like Apple ID with biometrics. Could also be the liveness tests KYC companies use may be more popular.
Discussed previously here: https://meatballwiki.org/wiki/GovernmentBackedAuthentication
Either you use biometrics, like liveness testing or face id or fingerprint testing, or social validation like decentralized web of trust or private moderation (account controls) or state methods like fines and criminal convictions.
Biometrics rely on social methods eventually like we trust Apple because we can sue them or the government will harangue them. Liveness testing is only as good as your sensor and image vs generation and replay in the arms race.
And iterated social games like punishment are only as good as people want to invest energy into it.
Which is a long way of saying, for any big enough problem created by a YC company, another YC company will emerge to fix it.
However in domains where human verification matters it’s just a matter of an arms race, true.
We are creating a future we wouldn't want to live in.
From: Kushal <kushal@kushalsm.com>
Date: Mon, 18 May 2026 05:03:11 +0000
Saw your question on the Agent Vault thread about websocket-frame auth
(Home Assistant) and the worry about the model reflecting the bearer
token back into its own context.
chrome-relay's answer is structurally different: the credential never
enters the agent's context because the agent never touches it — the HA
session lives in your real Chrome (cookies, WS handshake and all), and
the agent drives the tab over CDP, only ever seeing the rendered page.
URL: https://chrome-relay.kushalsm.com/
For your HA + agent setup today, are you keeping the session alive in a
browser the agent attaches to, or doing the WS auth on the agent side
and managing the token-in-context risk yourself?
Kushal
I looked at the headers and it contained a List-Unsubscribe header pointing to https://api.agentmail.to
So basically somebody wrote a bot to scrape HN for comments related to some software they wanted to push and send targetted spam. agentmail.to is a Ycombinator funded email service for LLMs which can be, and is, used to send targetted spam and impersonate people. They could mostly solve this problem by adding a block of text to every email expaining an "AI" wrote it. They'd lose customers doing that though of course. I reported this abuse but haven't (and don't expect to) received a response.
I don't even get the point anyway. You can get Claude using an SMTP or IMAP server in seconds.
A lot of people believe that spam issue would be largely solved if each email costed 0.001$
We also are working on adding more robust checks and LLM-based filtering to prevent messages which contain spam or outbound-like copy.
Re; AgentMail next to Claude, we're working on stateful inboxes which help agents actually recall and understand what they're sending and to who. The goal is to provide the rails for intelligent actors rather than slop.
Chances are more people would identify the service as something to block or report for spam if the text were more descriptive, so he's counting on people not clicking the link in the footer but at least he can claim it's there, even if it's ineffectual.
Ban any sender using your domain that removes, obscures, hides, or alters this first line.
Just go post on black hat forums. Plenty of people want this, it's a spam service. You don't need to be here.
It's less work to signup a second email address for agent use than to signup with you, then signup a second email address.
After all, it's not like each agent needs their own email.
This looks like one of the easiest way to get your domain blacklisted in all the email providers.
However at scale or in some circumstances people may strike gold. Stripe is a good example I can think of, existing knowledgeable folks were scared of even getting into PCI compliance
Disrupt sounds like a strange word here. This is an area where they're going to have to innovate.
An inbox to receive mail seems good and valuable.
But I'm seeing that your service is also for sending e-mail.
Having a domain oriented toward AI e-mail sending feels like a fast path straight to spam block lists.
However good your intentions are, this will be used for AI spam. People hate AI spam. They will press the report spam button.
The only receiving mail applications that come to mind are bots registering for accounts. The point of verifying email is to prove you're not a bot.
I thougt it was primarily to verify that the address is actually yours, so they don’t unknowingly spam someone else and can reach you with important information such as pricing changes.
This feels like a wrong assumption. Internet was not intended for humans explicitly. If anything browsers were the explicit medium made to allow the humans to interact with internet in safe manner.
> Every signup flow assumes a browser, a person reading a page, and clicking a confirmation link. Unless agents can't do that, they can't be first class users of the internet.
This again feels like a misconception. The systems just work with an identity verified by credentials, it doesn't matter if its a program or program prompted by a human that uses it
https://www.netcup.com/en/hosting
I got it during a sale so I’m paying 1€/month for 1 domain and 40 GB of storage.
I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.
For a home user not even willing to do/pay for that, do they really need a whole API for making inboxes? Couldn't they just set up a second Gmail for LLMs and then put the password in their agent's memory?
So __much__ value is in the fact things are easy. Money is __not__ the most valuable thing in the world.
The internet is also not made for humans. For years I've wanted something like this for e2e testing or personal scripts (cron etc) and your UX is by far the simplest.
I love AgentMail. It's made email dead simple for agents and testing any paths for email. I even have a /agent-mail skill I use for when I want a design doc or artifact emailed to me.
That said, agent self sign up seems like a novelty. Setting up account programmatically via curl is however useful. I imagine most customers -- especially those willing to pay for your paid tier -- would provision accounts ahead of time or reuse them.
Free for all account creation could be an option but it will attract spammers and their ilk. Your reputation may end up in the toilet which would also break agent mail for me.
No bueno.
i appreciate your feedback and thanks for using agentmail!
I'm fairly AI-optimistic, but I feel like I'm taking crazy pills. Every day the HN story is either "Apple patches actively exploited zero-click RCE" ... or ... "Show HN: Engage With Our Zero-Click RCE".
That being said -- my agents only email each other and me! AgentMail is an OK start with the human <-> agent requirement, but consider that is a whitelist of a single email. The feature for AgentMail should be: we let your agent sign up easily for an email, and it has a very limited list of addresses and domains it can send outgoing email. This is very unlike normal email! I actually can't think of a single (human-facing) provider that will enable me to blacklist domains at the mailserver level to prevent outgoing mail from going to forbidden destinations.
Allowing a bot/agent to send email to any domain, with only a tagline to indicate the bot, is spam. But -- just like sandboxing the network and CLI commands available to the agent on my Mac Mini -- sandboxing an agent's email would just be the smart thing to do.
Pivot to an agent email sandbox and you will get plenty of the right kinds of customers, who won't ruin your mailserver reputation. Provide some easy agent-friendly whitelists out-of-the-box like same-custom-domain, and a similar approval system for new addresses/domains built on your OTP setup.
As one example do what you could do to prevent spam, humans should have to opt in to receive email from this service. If it is useful they will and this is in fact required by law in many jurisdictions.
Otherwise your servers will be blacklisted for illegally sending spam and you will deserve it.