Self-Driving Software: What OAuth Can’t Do for AI Agents | Dick Hardt, Hello

Ken sat down with Dick Hardt for the first episode of Season 3 of the MailChannels podcast. Hardt is the person behind Identity 2.0, an author of OAuth, and he is now building AAuth, an authorization protocol designed for a world where software makes its own decisions. The conversation ran long and covered a lot of ground, but underneath all of it was a single question that platform operators are going to have to answer soon: when an autonomous agent takes an action, who authorized it, and who is accountable when it goes wrong?

That question is not academic for anyone running email infrastructure. Here is what came out of the conversation, and why it matters for platforms that let downstream senders, including AI agents, send email.

Listen on Spotify

Self-driving software needs a separate brain that says no

Hardt’s framing is that we are moving from automated software to self-driving software. The analogy is a self-driving car: you give it a destination, and it figures out the route, the turns, and the construction detours along the way. In AAuth the destination is called a mission. You tell the agent what you want accomplished and it works out the steps.

The catch is that some steps are irreversible. Hardt’s recurring example is dropping a production database table. In the middle of a schema migration to support a new region, dropping the old table is the correct final step. In almost any other context it is a catastrophe. The resource itself, the database, has no way to know which situation it is in. It only sees the request.

So AAuth separates the agent trying to do the work from a governing brain that decides whether the action is authorized, with full context of the mission and everything that has happened so far. Today that governing brain is often a human clicking yes. Hardt’s argument is that if a human can sit in that loop, a piece of software can learn to sit there too, escalating to the person only when something falls outside learned policy. His blunt version: we are replacing a human with a robot, and the robot will not get tired, bored, or suffer consent fatigue. It will not be perfect, but neither was the human.

The building blocks OAuth never had

Ken pushed on why you cannot just bolt this onto OAuth. Hardt’s answer is that OAuth was designed for one server talking to another server so a user would not have to hand over their password. That was the whole problem it solved, and for its first few years it solved it well. Everything since has been tacked on.

For agent authorization, several base primitives are missing. You need to know which specific instance of an agent is acting, not just that it is “an Anthropic model” but that it is this running instance of Claude Code. You need the resource to have its own identity and to be able to describe its own context, because the resource knows its situation better than anyone. And you need a standard way to pull all of that signal back to the point where an authorization decision gets made.

Hardt also made a distinction worth holding onto: OAuth is really a framework, not a protocol. Every OAuth server is its own snowflake, and you write custom code against each one. That works when you are integrating with a handful of known services. It breaks completely when an agent needs to talk to a resource it has never seen before and have it work immediately, the way a browser talks to any web server. AAuth is being built for conformance, so interoperability is not optional.

Reputation should be portable, and email is the proof

The part of the conversation most relevant to email delivery was about reputation. Ken made the point that in email, bad reputation is nearly useless as a signal, because a bad actor can spin up a fresh identity with a clean slate in seconds. The only durable signal is good reputation built by good actors over long periods, tied to something stable like a domain that has done nothing but legitimate sending for years.

Both agreed the problem is that reputation is trapped in silos. Your standing in Uber has nothing to do with your standing in Airbnb. Your email sending reputation stays locked to your email domain. Hardt’s interest is in making reputation portable, so a strong track record in one place counts elsewhere. Ken extended it: an organization with an excellent email sending history should be able to carry that into SMS, push notifications, or an app store listing. And a signal like SOC 2 compliance should be able to travel the other way, telling an email receiver something about the sender’s security posture, which matters because many senders are not malicious, they were simply compromised.

Hardt confirmed this is more than theory. There are active discussions about attaching claims like SOC 2 status directly to the token an agent presents, so a resource being called can see that the agent works for a given organization and that the organization’s infrastructure meets a known bar.

Killing API keys and fixing webhooks

Two practical wins fell out of giving clients a real identity.

The first is getting rid of API keys. Because every AAuth call is HTTP message signed, the receiving end always knows who is calling. That means an agent can begin a relationship with a resource directly, do a few things on a free tier, and only later link a responsible human, rather than sending the human off to a console to generate a key and paste it back. It also removes the security problem of API keys sitting around waiting to be stolen, which Hardt noted is now a serious business, since stolen model keys can be resold as a service.

The second is webhooks. Today webhooks are a mess of shared secrets and bespoke implementations, and the hard part is mutual trust: the caller proving it is really you, and the receiver knowing the call is legitimate. Both sides are the same problem, a client proving who it is, which is exactly what message signing solves. Ken’s frustration with the current state was pointed: setting up a tunnel and wiring a webhook by hand just to receive an event is boutique work every single time, and polling every five minutes instead is inefficient, burns tokens, and does not scale.

What this means for platform email

Ken put the MailChannels case plainly. He would be comfortable letting Claude Code send a small amount of email if he could actually verify it was Claude Code, even without knowing the individual driving it, because he trusts the provider’s alignment enough to know it is not going to launch an uncapped phishing campaign. Up to a point. Past that point, a human or an organization has to be accountable.

That threshold is the entire problem. The utility on the other side of it is enormous: someone who knows nothing about email should be able to tell an agent to send a birthday invite or a note to thirteen people and have it handled, cleanly, from their own domain, for almost nothing. Doing that today takes an absurd number of steps. But letting it happen safely means answering the governance questions AAuth is built around. Which agent is this? Who does it work for? What is it allowed to do, at what volume, and who is responsible when a sender goes bad?

This is the operational reality behind letting AI agents send email. It is not about whether an agent can call a send endpoint. It is about giving each agent a governed identity, its own policies and limits, and a clear accountability path, so that one compromised or malicious agent cannot take the whole platform down with it. That is the problem MailChannels already solves for platforms with many downstream human senders, and agent senders are the same problem wearing new clothes.

Getting the flywheel started

Hardt is realistic that a new protocol only takes off if it removes real pain rather than being a slightly better way to do something already solved. His near-term wedges are the low-friction ones: letting an agent talk to a resource and drop API keys without any new infrastructure, and building proxies that make existing OAuth resources look like AAuth resources so there is something for early clients to talk to. He sees the people running their own agents on their own machines, the OpenClaw and Hermes communities, as the innovators who will start the flywheel, partly because connecting personal agents to real services today is genuinely painful.

The whole conversation is worth listening to if you care about where agent infrastructure is heading. For anyone building a platform where customers, workflows, or agents send email, the takeaway is simpler: the accountability question is coming, and the platforms that have already answered it for their downstream senders will be the ones able to say yes to agents safely.

Where MailChannels fits

MailChannels is the abuse-safe email infrastructure layer for platforms whose users, tenants, customers, and AI agents send email. Generic email APIs work well when one company sends its own mail. They leave the harder problem to you: downstream sender abuse, tenant isolation, rate limits, complaints, bounces, and safe suspension when one sender goes bad. That is the problem we have been solving in production for web hosting providers for years, where a single compromised customer used to mean support tickets, blocklisting, and reputation damage for everyone on the platform.

The results are concrete. One hosting provider cut email-related support tickets from around 300 a week to roughly 10. Others have seen delivery and blocklisting tickets fall by more than 90 percent. Each sender, whether a tenant, a customer, or an agent, gets its own identity, its own policies and rate limits, and its own suspension path, so one bad actor cannot take the whole platform down.

Agent senders are the same problem wearing new clothes. If you are building a platform that needs to let customers, workflows, or AI agents send email without inheriting their risk, talk to us about what governed, per-sender email looks like for your platform.

Listen to the full conversation with Dick Hardt on the MailChannels podcast.