← Back to Blog

AI Agents Need a DMARC Moment

Jonah Schwartz·

In 2012, email was broken. Not the delivery part — that worked fine. The trust part. Anyone could send an email claiming to be your bank, your CEO, your vendor. There was no reliable way to verify that an email actually came from who it said it came from. Phishing was rampant. Business email compromise was a growth industry.

Then DMARC happened. Along with SPF and DKIM, it gave the email ecosystem a standard way to answer a simple question: did this message actually come from the domain it claims to come from? It wasn't perfect. Adoption took years. But it changed the trust model of email in a way nothing else had.

AI agents in 2026 are in the exact same position email was in 2012. And they need the same kind of reckoning.

The Agent Identity Crisis

Right now, when an AI agent shows up at your API, you have no reliable way to answer the most basic questions: Who built this agent? What organization does it belong to? What is it authorized to do? Who — which human — approved its access?

A CIO article this week put it perfectly: much like email before DMARC, our current AI ecosystem needs upfront authentication to establish trust. The first questions should be "who sent you?" and "what do you want to do?" — before any action is taken.

Instead, most agents authenticate with API keys. Static strings that don't expire, don't scope, and don't tell you anything about intent. It's the equivalent of pre-DMARC email: the message arrives, it says it's from someone, and you just... hope that's true.

Detection vs. Prevention

The industry is starting to notice. Okta just shipped agent discovery features to find "shadow AI" — unsanctioned agents operating inside organizations with hardcoded credentials. Cisco expanded AI Defense with an AI Bill of Materials to track agent dependencies and MCP server usage. These are real, important efforts.

But they're detection plays. They're the spam filters of the agent world — catching bad actors after the fact. What the ecosystem actually needs is a prevention layer. A way to verify agent identity and authorize agent actions before they happen, with the human in the loop.

DMARC didn't stop spam by detecting it better. It stopped spoofing by making identity verification a protocol-level concern. That's the shift AI agents need.

What an Agent DMARC Would Look Like

The analogy isn't perfect — agents are more complex than email headers. But the principles translate:

Identity verification. Every agent interaction should start with a verifiable answer to "who is this agent, and who authorized it?" Not an API key. Not a shared secret. A proper OAuth flow where a human explicitly grants scoped access.

Scope enforcement. DMARC tells receiving servers what to do with unauthenticated email (none, quarantine, reject). Similarly, agent auth should let users define exactly what an agent can do — read-only vs. write access, which resources, for how long. The human sets the policy, the agent operates within it.

Visibility and audit. DMARC generates reports. Organizations can see who's sending email on their behalf and whether it's passing authentication. Agent auth needs the same transparency — a clear record of what agents accessed, when, and under whose authorization.

Revocability. When you discover a compromised email domain, you update your DMARC policy. When an agent misbehaves, you should be able to revoke its access instantly. Not "wait for the token to expire." Not "rotate the API key and hope nothing else breaks." Instant, surgical revocation.

Why OAuth Is the Foundation (But Not the Whole Answer)

OAuth 2.0 gives us the right primitives: delegated authorization, scoped tokens, refresh flows, revocation endpoints. It's battle-tested across billions of human-facing applications. MCP is already formalizing OAuth as the standard auth mechanism for agent-to-tool connections.

But raw OAuth isn't enough for agents. The missing pieces are all about the human layer:

  • User-facing approval flows where non-technical humans can understand and approve what an agent wants to do
  • Scope selection UX that translates OAuth scopes into plain language ("This agent wants to read your repos" not "scope: repo:read")
  • Time-limited grants because no agent should have permanent access by default
  • Cross-provider consistency so connecting GitHub, Google, and Linear doesn't require three different auth implementations

This is what we're building at TapAuth. One API call to create a grant, a human-readable approval page, scoped and time-limited tokens, instant revocation, full audit trail. The trust layer between humans and AI agents.

The Window Is Now

DMARC took years to reach meaningful adoption. The AI agent ecosystem doesn't have that luxury. Research this week shows that most organizations deploying AI agents are still using API keys, shared service accounts, and patterns designed for humans — not autonomous systems. The gap between agent capability and agent security is widening every week.

Cisco recognizes it. Okta recognizes it. Every enterprise security team trying to manage agent sprawl recognizes it. The question isn't whether AI agents need a trust standard — it's who builds it and how fast.

Email got DMARC. The web got HTTPS. AI agents need their own authentication moment. The longer we wait, the more we're building on a foundation of "just trust the API key." And we all know how that ends.