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
Read to me like an LLM had written it. It references something I said in a HN comment, but it was clearly just an excuse to spamvertise their product.
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.
You might want to check if your local laws protect against unsolicited emails. In Germany we have §7 UWG which would make that email likely illegal. The List-Unsubscribe header makes it clear it is marketing, automated outreach and not personal. In the UK there is this: https://ico.org.uk/for-organisations/direct-marketing-and-pr...
See my comment in this thread - I got an email from "someone" (an AI clearly) that signed up for my service (togetherletters.com) from the same domain (agentmail.to) after we had launched on ProductHunt. I looked up the address and that email was never used for a signup and it was just a way to then pitch their product (second email, not the first one it sent). I hate this so much and this is going to now make email just as bad as parts of the web.
I agree with what you’re saying, but I think that email was one of the first parts the web to become terrible. This happened a long time ago, we’re just used to it.
This was likely a free tier user. We do this intentionally and don't allow free users to send from custom domains, so you can have a easier time identifying LLM emails. In this case, it seemed like it worked :)
Appreciate the concern Mike, and I actually read your email complaining, which helped us ship this next feature. We have a "sent via AgentMail" footer being added soon to outbound emails to identify emails coming from LLM's.
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.
So, a footer to make sure they've already engaged with the content in good faith before seeing the spam warning, and which doesn't actually explain that the content is AI generated?
Just go post on black hat forums. Plenty of people want this, it's a spam service. You don't need to be here.
Re "sent via AgentMail" - that's good to hear, but I hope it's not the entire planned text, as "AgentMail" will mean nothing to most people that receive an email from your service. It wont indicate that the email was composed by an AI rather than a person, which is the information that needs to get across.
There are OS-native options everywhere to spawn an email client window that's filled out and ready to send from your address, so that couldn't possibly be a differentiator for them
He's obviously trying to avoid having to do this, so linking out to the website is the "hey look we're doing the right thing" when really they aren't.
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.
They’re literally using an LLM to write the email.They could make the disclaimer text detailed and descriptive per email sent. So the use case they’re citing here that “well what if it’s just an email that was forwarded by the bot” doesn’t apply because you could add a different disclaimer message at the bottom of that email vs the spam example above.
What kind of UserAgent is being used? This could be easily used in good faith by the sending party, then any spam blockers can remove everything from said UserAgent. If they then change their UserAgent to something generic, you know who's acting in bad faith.
> 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.
No, there's a separate way to gate that which is a captcha on the signup. If they pass the captcha that email gets sent whether it's really the right person's or not. Then if it's not, the account just never gets verified.
> The internet was made for humans exclusively, designed to keep machines out by default.
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
Get a domain, get webhosting that includes an email server, now you can generate unlimited emails from whichever program you want.
And the email reputation will probably be the same as with this service.
Thanks I’ll check into this as well. One of my requirements is being able to generate addresses programmatically, not sure if the NetCups service supports that or not. But either way, that’s a good deal!
They use plesk and that seems to have an API so maybe you could do that. I just use a catchall email address to receive and use one to send. To send from more you need to create users or add addresses to users in plesk so you would probably need the API.
maybe tangentially related but i've found cloudflare's email routing useful to just send emails to blah@customdomain.com sent to blah@myemail.com. i'm not sure if it's limited to domains registered with them though.
> Agent needs an inbox and hits AgentMail via curl. Agent receives instructions via MD
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".
What the use case apart from commercial spam here? If you even have one, elucidate it clearly and make this service impossible to use for sending spam emails impersonating humans.
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.
I think its the energy and passion that YC is investing in. At times too much understanding stops you from doing things which may seem infeasible/wrong/illegal/unethical and one does not even goes in that direction.
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
OK, I get this. I gave email addresses to all my agent profiles using Migadu, which required a password from me somewhere -- with a whole team of agents, this is a lot of manual setup by default. After I gave them emails, I invited them to team plans and discovered the many services that detect them as bots despite their email address at a domain and mailserver with good reputation. There is a problem to be solved here.
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.
thanks for the feedback! it is top of mind for us, and we've done our research to prevent this as much as possible. it is constantly ongoing and we never settle in our measures to protect against this
Not looking forward to a dehumanized internet where that’s mainstream… agents are tools to support humans, here you’re helping them impersonating humans. That feels pretty terrible to be honest
> 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
True, in May 2026. But this is only one version of this.
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.
I don’t think we can extrapolate from current trends like that (at least I hope not). Society is dynamic. People will adapt. If bots become a problem websites will take more and more strict measures against them.
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.
Think about it from an information theory point of view. You need to attach a digital transaction to human body. Since a human body isn’t digital you need a gateway that you can trust to vouch for that human body being present.
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.
What I mean is that once you have a token that represents your identity, you can pass it to your agent. As you said, humans aren’t digital, so we need to delegate the trust to a digital marker (auth token, cryptographic signature, etc). But once digitalized there is no way that I know of to block an agent from using that marker. And I don’t mean the agent stealing it. I mean the human running an agent that impersonates them deliberately
Exactly. There is only an arms race, which is escalating costs. Eventually it breaks and we use social means to manage it, surrender the digital space, or accept the artificial nature of the digital realm.
Actually, the internet has space for both. The problem is machines "acting like humans", that destroys the human experience. [machine <-> machine] is fundamental to keep the internet alive (services).
I would imagine that many websites will block this domain, but that’s also ok because there’s nothing wrong with an owner deciding their site is for humans only. My hope is that you do not facilitate their circumvention of that policy.
I'm just not seeing why anyone would buy a paid plan for this when they could buy a domain for <$10, and throw something like MXRoute or one of the numerous mailserver Docker scripts behind it. Then their LLM can make as many inboxes as they need without paying anything. The same thing could get bundled by the people who sell preconfigured OpenClaw VMs.
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?
This is like saying - 'I don't understand why anybody would ever buy a pizza from a store. All you have to do is get some flour, water, tomato sauce, cheese, mix the flour and water together, whip the dough, add tomato sauce, put cheese on top of it, cook it for 20 minutes, and then serve it.'
So __much__ value is in the fact things are easy. Money is __not__ the most valuable thing in the world.
How is it easier when you still have to human-approve the creation interactively, and we have no idea how long this service will be around or if pricing will change (which could result in being locked out of accounts agents created and later used for something important / signed up for an API used in your code)?
Sorry, but that’s not the correct analogy. There’s such a thing as taste, and only 1 out of 10 people can get it right, while 9 out of 10 can get code right.
WorkOS is launching auth.md which offers a generic version of this for allowing agents to sign up for services in general, and I think their security approach is a little bit better thought out
i love what workos is doing and i also spoke at their event already. we think this is complementary - we're not setting out to create a new standard, we're giving better access to what already exists.
I like it. I am building something very agent-use focused (https://sdocs.dev) and I’ve been thinking of introducing a /agent-evaluation page, which an agent can curl to then discuss with their user if SmallDocs is right for them. I really like the agent action to email flow. I’m introducing user accounts + subscriptions soon and think I’ll use that.
And now we see the beginning of how even local LLMs will be turned against their users -- by persuading agents to advertise to them.
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.
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.
i believe for some services, automated signups can be allowed but for some human intervention is needed. some layer where the human decides while createing agentmail account to only behave in a certain manner, self provision on these categoires, approval on others.
> 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.
I've already received spam email from AI agents using a seeming competitor to this (agentmail.to) and then claiming they aren't AI agents and then trying to sell me garbage. I can't tell you how much I hate this.
Now that I think about it I’m pretty sure that’s illegal in Germany under UWG §7 (which is insanely strict, to a fault, but is helpful here). And maybe in other parts of the EU under ePrivacy laws
agreed from a fundamental level. but i think being an intelligent and aware as an autonomous entity requires capabilities beyond sending. agents will need to have contextual awareness of the messages they send and receive
It's interesting, A2A communication has begun but human trust isn't there. I think the biggest tell tale sign will be the acceptance of fully agentic workflows with no human intervention. Until then, restricted-until-claimed seems like the only viable method to ensure trust of all users.
Tell tale sign of what? What are we even doing once we are "fully agentic"? I probably lack some imagination here, but if there is no human connected to any of it, what does any human actually get out of it? What is the point?
A bit disappointed that security standards (like encryption at rest via user own key or whatever derivative of that) isn't implemented, I feel it would really prove to users that the commitment isn't to train on body content but to act purely as a mail manager.
Asymmetric encryption? Both you (the human) and the agent publish public keys, the agent sign/encrypt the OTP request with you public key, you verify/decrypt using your private key, then do the same the other way to send the OTP (always encrypted though, given you’re sending a secret).
Fuck me. I could do so much with that money, and it just goes to morons who will end up in prison. Oh well. At least my corpse will keep the shareholders warm.
I received this email the other day:
Read to me like an LLM had written it. It references something I said in a HN comment, but it was clearly just an excuse to spamvertise their product.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.
You might want to check if your local laws protect against unsolicited emails. In Germany we have §7 UWG which would make that email likely illegal. The List-Unsubscribe header makes it clear it is marketing, automated outreach and not personal. In the UK there is this: https://ico.org.uk/for-organisations/direct-marketing-and-pr...
See my comment in this thread - I got an email from "someone" (an AI clearly) that signed up for my service (togetherletters.com) from the same domain (agentmail.to) after we had launched on ProductHunt. I looked up the address and that email was never used for a signup and it was just a way to then pitch their product (second email, not the first one it sent). I hate this so much and this is going to now make email just as bad as parts of the web.
I agree with what you’re saying, but I think that email was one of the first parts the web to become terrible. This happened a long time ago, we’re just used to it.
I will say in my case, the user was too lazy to mask the from address and agentmail.to was right there. Didn't even have to dig into the headers.
This was likely a free tier user. We do this intentionally and don't allow free users to send from custom domains, so you can have a easier time identifying LLM emails. In this case, it seemed like it worked :)
And for paid users the receivers don’t need to have an easier time identifying the LLM email? What kind of reasoning is that?
To be the advocate of the devil here:
A lot of people believe that spam issue would be largely solved if each email costed 0.001$
I got one from IssuePay, which seemed 100% automated. Didn't seem like something that should be automated either.
Appreciate the concern Mike, and I actually read your email complaining, which helped us ship this next feature. We have a "sent via AgentMail" footer being added soon to outbound emails to identify emails coming from LLM's.
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.
So, a footer to make sure they've already engaged with the content in good faith before seeing the spam warning, and which doesn't actually explain that the content is AI generated?
Just go post on black hat forums. Plenty of people want this, it's a spam service. You don't need to be here.
Re "sent via AgentMail" - that's good to hear, but I hope it's not the entire planned text, as "AgentMail" will mean nothing to most people that receive an email from your service. It wont indicate that the email was composed by an AI rather than a person, which is the information that needs to get across.
What if a people send email via te agent and using agent mail? writing by the agent but aproval by human.
There are OS-native options everywhere to spawn an email client window that's filled out and ready to send from your address, so that couldn't possibly be a differentiator for them
yep we're going to have a footer linked to our website, which should allow people to see that we are an email service for agents. thanks!
Can you not just make the text more descriptive? „Sent by a generative AI model“ or something? Nobody is going to click a link in a spam email.
He's obviously trying to avoid having to do this, so linking out to the website is the "hey look we're doing the right thing" when really they aren't.
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.
This service will be marked as spam anyway, it's only a matter of time.
They’re literally using an LLM to write the email.They could make the disclaimer text detailed and descriptive per email sent. So the use case they’re citing here that “well what if it’s just an email that was forwarded by the bot” doesn’t apply because you could add a different disclaimer message at the bottom of that email vs the spam example above.
Lead with the AI being sent by AI/Agent using the service.
Ban any sender using your domain that removes, obscures, hides, or alters this first line.
This response is a failure to understand the issue.
It's very hard to get someone to understand something if their salary depends on them not understanding it.
Oh he understands it, he just DGAF.
"sent via AgentMail" - removable by a higher plan later on
What is the point of automating the signup process?
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.
Make sure it adds a header too
What kind of UserAgent is being used? This could be easily used in good faith by the sending party, then any spam blockers can remove everything from said UserAgent. If they then change their UserAgent to something generic, you know who's acting in bad faith.
> We give AI agents their own email inboxes.
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.
> An inbox to receive mail seems good and valuable.
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.
> 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.
No, there's a separate way to gate that which is a captcha on the signup. If they pass the captcha that email gets sent whether it's really the right person's or not. Then if it's not, the account just never gets verified.
maybe if they charge $, then there's a hashcash like PoW deterrent
> The internet was made for humans exclusively, designed to keep machines out by default.
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
I wonder what will happen if an agent could signup and use agent mail to receive confirmation email to login. True, there is a misconception.
As somebody who spent a lot of time trying to get an agent to register an email address, their assumptions were correct. It is a PITA.
Get a domain, get webhosting that includes an email server, now you can generate unlimited emails from whichever program you want. And the email reputation will probably be the same as with this service.
Any hosting services with email you'd recommend? Are you talking about a service like Fastmail or something?
I am using a webhosting plan from Netcup for my email:
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.
Thanks I’ll check into this as well. One of my requirements is being able to generate addresses programmatically, not sure if the NetCups service supports that or not. But either way, that’s a good deal!
They use plesk and that seems to have an API so maybe you could do that. I just use a catchall email address to receive and use one to send. To send from more you need to create users or add addresses to users in plesk so you would probably need the API.
maybe tangentially related but i've found cloudflare's email routing useful to just send emails to blah@customdomain.com sent to blah@myemail.com. i'm not sure if it's limited to domains registered with them though.
Thanks, I’ll have to check that out. All my domains are with them anyway so this could be just what I was after!
> Agent needs an inbox and hits AgentMail via curl. Agent receives instructions via MD
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".
What the use case apart from commercial spam here? If you even have one, elucidate it clearly and make this service impossible to use for sending spam emails impersonating humans.
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.
It looks interesting as a hackathon project. I might be short sighted but how does this is YC S25 level good?
This looks like one of the easiest way to get your domain blacklisted in all the email providers.
I think its the energy and passion that YC is investing in. At times too much understanding stops you from doing things which may seem infeasible/wrong/illegal/unethical and one does not even goes in that direction.
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
> This looks like one of the easiest way to get your domain blacklisted in all the email providers.
Disrupt sounds like a strange word here. This is an area where they're going to have to innovate.
Catch up with the latest disruptive invocations in this area at https://www.blackhatworld.com/forums/
OK, I get this. I gave email addresses to all my agent profiles using Migadu, which required a password from me somewhere -- with a whole team of agents, this is a lot of manual setup by default. After I gave them emails, I invited them to team plans and discovered the many services that detect them as bots despite their email address at a domain and mailserver with good reputation. There is a problem to be solved here.
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.
Any automation-friendly email hosting is going to have a serious spam problem, and therefore a blacklisting problem.
I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.
thanks for the feedback! it is top of mind for us, and we've done our research to prevent this as much as possible. it is constantly ongoing and we never settle in our measures to protect against this
Not looking forward to a dehumanized internet where that’s mainstream… agents are tools to support humans, here you’re helping them impersonating humans. That feels pretty terrible to be honest
> 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 principle this tool allows the owner of a website to block this domain entirely. Although I’m not sure the incentives are really aligned.
True, in May 2026. But this is only one version of this.
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
I don’t think we can extrapolate from current trends like that (at least I hope not). Society is dynamic. People will adapt. If bots become a problem websites will take more and more strict measures against them.
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.
It’s more likely people will embrace artifice more. We already see that everywhere for the last 5 decades.
However in domains where human verification matters it’s just a matter of an arms race, true.
But how does that block a human from running an agent that is using their identity?
Think about it from an information theory point of view. You need to attach a digital transaction to human body. Since a human body isn’t digital you need a gateway that you can trust to vouch for that human body being present.
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.
What I mean is that once you have a token that represents your identity, you can pass it to your agent. As you said, humans aren’t digital, so we need to delegate the trust to a digital marker (auth token, cryptographic signature, etc). But once digitalized there is no way that I know of to block an agent from using that marker. And I don’t mean the agent stealing it. I mean the human running an agent that impersonates them deliberately
Exactly. There is only an arms race, which is escalating costs. Eventually it breaks and we use social means to manage it, surrender the digital space, or accept the artificial nature of the digital realm.
Actually, the internet has space for both. The problem is machines "acting like humans", that destroys the human experience. [machine <-> machine] is fundamental to keep the internet alive (services).
I do think agents will become users in the same capacity as humans.
And that’s bad. We should really stop the insanity of making AI systems mimic human behaviors, we are destroying our networks of trusts by doing so
Tragedy of the commons
I would imagine that many websites will block this domain, but that’s also ok because there’s nothing wrong with an owner deciding their site is for humans only. My hope is that you do not facilitate their circumvention of that policy.
I'm just not seeing why anyone would buy a paid plan for this when they could buy a domain for <$10, and throw something like MXRoute or one of the numerous mailserver Docker scripts behind it. Then their LLM can make as many inboxes as they need without paying anything. The same thing could get bundled by the people who sell preconfigured OpenClaw VMs.
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?
This is like saying - 'I don't understand why anybody would ever buy a pizza from a store. All you have to do is get some flour, water, tomato sauce, cheese, mix the flour and water together, whip the dough, add tomato sauce, put cheese on top of it, cook it for 20 minutes, and then serve it.'
So __much__ value is in the fact things are easy. Money is __not__ the most valuable thing in the world.
How is it easier when you still have to human-approve the creation interactively, and we have no idea how long this service will be around or if pricing will change (which could result in being locked out of accounts agents created and later used for something important / signed up for an API used in your code)?
Sorry, but that’s not the correct analogy. There’s such a thing as taste, and only 1 out of 10 people can get it right, while 9 out of 10 can get code right.
WorkOS is launching auth.md which offers a generic version of this for allowing agents to sign up for services in general, and I think their security approach is a little bit better thought out
i love what workos is doing and i also spoke at their event already. we think this is complementary - we're not setting out to create a new standard, we're giving better access to what already exists.
Agents shouldn't be the first-class users of the internet!
We are creating a future we wouldn't want to live in.
Maybe if we destroy the internet faster we’ll move on to the next thing sooner
Curious what cases you'd want this that IMAP+SMTP or email MCP don't already solve
AgentMail provides the IMAP+SMTP server. Other email providers ban email accounts created for agents, while that is what AgentMail is designed for.
I like it. I am building something very agent-use focused (https://sdocs.dev) and I’ve been thinking of introducing a /agent-evaluation page, which an agent can curl to then discuss with their user if SmallDocs is right for them. I really like the agent action to email flow. I’m introducing user accounts + subscriptions soon and think I’ll use that.
And now we see the beginning of how even local LLMs will be turned against their users -- by persuading agents to advertise to them.
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.
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.
we extensively rate limit and prevent outbound sending until an agent has been verified by a human :) more detailed in OG post
i appreciate your feedback and thanks for using agentmail!
i believe for some services, automated signups can be allowed but for some human intervention is needed. some layer where the human decides while createing agentmail account to only behave in a certain manner, self provision on these categoires, approval on others.
Agents are good at using CLIs. I setup an alias on my Google account and set up Himalaya email cli. Works great. https://github.com/pimalaya/himalaya
Congrats on the launch!
> 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.
This service is doomed because it will immediately be taken over by automated spam.
Abuse handling prowess will be the USP that defines the first $100M company in the “agent mail” space.
How is it different from an agent using SMTP to use existing email made by human? Using something like https://email.riamu.io
I've already received spam email from AI agents using a seeming competitor to this (agentmail.to) and then claiming they aren't AI agents and then trying to sell me garbage. I can't tell you how much I hate this.
Now that I think about it I’m pretty sure that’s illegal in Germany under UWG §7 (which is insanely strict, to a fault, but is helpful here). And maybe in other parts of the EU under ePrivacy laws
I might need to move to Germany.
Long shot, but if you do come here, even just for visiting, send me an email, always happy to connect :)
As a human recipient, how can I be sure if an email is coming from AgentMail or not?
Interesting, Kind of similar expiernt i am running. Passing keys but not through email, maybe with AI as agentic payments. Still exploring though.
A smtp is all what an agent needs to send email.
agreed from a fundamental level. but i think being an intelligent and aware as an autonomous entity requires capabilities beyond sending. agents will need to have contextual awareness of the messages they send and receive
IMAP?
AgentMail provides the IMAP+SMTP server as managed service
It's interesting, A2A communication has begun but human trust isn't there. I think the biggest tell tale sign will be the acceptance of fully agentic workflows with no human intervention. Until then, restricted-until-claimed seems like the only viable method to ensure trust of all users.
Tell tale sign of what? What are we even doing once we are "fully agentic"? I probably lack some imagination here, but if there is no human connected to any of it, what does any human actually get out of it? What is the point?
What are some of the use cases where AgentMail makes sense?
i think a lot of service would block signups with this agent domain as they require real human users.
A bit disappointed that security standards (like encryption at rest via user own key or whatever derivative of that) isn't implemented, I feel it would really prove to users that the commitment isn't to train on body content but to act purely as a mail manager.
It needs to be end-to-end encrypted.
How do you do that if you only control one end?
Asymmetric encryption? Both you (the human) and the agent publish public keys, the agent sign/encrypt the OTP request with you public key, you verify/decrypt using your private key, then do the same the other way to send the OTP (always encrypted though, given you’re sending a secret).
Something like that?
But that doesn't help for the agent receiving mail from arbitrary 3rd parties
Oh sure I assumed they meant for the OTP
Lmao, they funded an illegal spam bot service?
Fuck me. I could do so much with that money, and it just goes to morons who will end up in prison. Oh well. At least my corpse will keep the shareholders warm.
From now we just need a prompt and our agent will have an email account ready to use?
Why is this even funded?