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.

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".

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

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.

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.

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.

This looks like one of the easiest way to get your domain blacklisted in all the email providers.

I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.

> 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

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?

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 are creating a future we wouldn't want to live in.

> 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.

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.