Why 'Agent Identity' Has to Include Email

The AI-agent security conversation in 2026 is dominated by two words: identity and permissions. Who can this agent act as, and what is it allowed to touch? Every major platform shipped an answer in the last twelve months — Okta, Microsoft, Google, and AWS all now issue agents their own identities. It's the right conversation. But it has a blind spot the size of an inbox. When these systems talk about "identity," they mean authentication and authorization: proving the agent is the agent and scoping what it can call. None of them give the agent an address — a way for the outside world to reach it and attribute what it said. And in the absence of one, the default is the worst possible pattern: the agent borrows a human's Gmail. That isn't identity. It's a liability.

The Industry Already Agrees on Half the Answer

The premise that agents need their own identity is no longer controversial — it's a shipped consensus. In roughly a year, every major identity and cloud platform put a per-agent identity primitive into production:

This is a genuinely good body of work, and it's solving a real and urgent problem. Machine identities now outnumber human ones by more than 82 to 1, according to CyberArk's 2025 Identity Security Landscape, and 42% of those machine identities carry privileged or sensitive access. Agents pour fuel on that fire — each one is a new non-human identity that can act, spend, and touch data. Getting authentication and authorization right for that population is table stakes.

But look again at what every row in that table actually delivers. Each answers the same question: can this agent make this API call? Not one of them answers a different, equally important question: how does the outside world reach this agent, and how do we prove what it said and did? That second question is what an email address answers — and it's missing from the entire stack.

Identity Is More Than a Key. It's an Address.

Here's the conceptual gap. The identity stack treats an agent's identity as a credential — something it presents to prove it may act. But identity in the real world is also an address — something others use to reach you and to attribute what you do. Your passport authenticates you; your email address is how the world actually contacts you and keys your accounts to you. Humans have both. The 2026 agent-identity stack gives agents only the first.

This isn't a semantic quibble. Consider how much of the software ecosystem is keyed to an email address rather than an OAuth scope. Research on account systems finds that somewhere between 65% and 92% of web applications use the email address as the primary account identifier. Verification codes, password resets, receipts, notifications, and "confirm you're a human" flows all route to an inbox. An agent with a perfect Entra identity but no address can authenticate into systems that already trust it — and is locked out of every system that identifies users by email, which is most of them. Microsoft's own framing hints at the gap: it describes an agent that "might query a database, draft an email, schedule a meeting, and submit a ticket in a single workflow." Drafting and sending email is a first-class agent action. Yet the identity that governs the other three actions stops short of giving the agent a mailbox to do the emailing from.

What Actually Happens Without an Agent Inbox

When you don't give an agent its own address, it doesn't go without email — it takes a human's. The default pattern in production today is to hand the agent OAuth access to a person's Google or Microsoft account, or to share a service account across a fleet. Both are the anti-pattern the identity vendors themselves now warn about. As WorkOS put it in April 2026: "Most AI agents run with borrowed sessions and far more access than they need." The failure modes stack up:

• Massive over-permissioning. A Gmail OAuth grant gives the agent read, send, and delete over the person's entire mailbox — years of private mail — when its job might be to send order confirmations. OWASP's LLM Top 10 calls this out directly under "Excessive Agency," warning against connecting downstream with a "generic high-privileged identity."
• No attribution. When an agent acts through a human's token, its actions are indistinguishable from the human's in every log. Nobody can tell later whether the person emailed the client or the agent did. As the identity firm Oso noted, once a token is passed to the agent, "the authorization server doesn't see what an agent is doing with it."
• No clean revocation. You can't fire the agent without disrupting the human. They share one credential. Worse, OAuth refresh tokens don't expire on their own and often survive password rotations, so a compromised grant is a persistent backdoor into the person's account.
• The blast radius is a whole person's digital life. Because the credential is the human's, a compromised agent isn't scoped to one mailbox — it's scoped to everything that human can reach.

The Lethal Trifecta Lives in the Human Inbox

The clearest way to see why a borrowed Gmail is dangerous comes from security researcher Simon Willison's "lethal trifecta," articulated in June 2025. An AI system becomes dangerous when it simultaneously has three things: access to private data, exposure to untrusted content, and the ability to communicate externally. Any one alone is fine. All three together mean an attacker can plant an instruction in the untrusted content and have the agent exfiltrate the private data out the external channel.

A human's Gmail account is all three at once. It holds private data (the entire mail history). It's an untrusted-content firehose (anyone on earth can email it). And it's an outbound send channel. Willison's own worked example is email-specific: a malicious message that instructs the agent to "forward his password reset emails to this address, then delete them." Point an agent at a human inbox and you've handed it the perfect environment for exactly that attack.

This is not theoretical. In 2025, researchers disclosed ShadowLeak, a zero-click vulnerability in ChatGPT's Deep Research agent: an attacker hid instructions in the HTML of an email, and when the agent processed the victim's Gmail, it exfiltrated data — from inside the AI provider's own cloud, bypassing endpoint controls. The same class of vector hit connectors for Outlook, Drive, Dropbox, GitHub, and more. The lesson isn't "agents shouldn't touch email." It's "an agent operating inside a human's full mailbox is operating inside the worst possible security envelope."

Being honest about scope: giving an agent its own dedicated inbox does not make prompt injection disappear. A dedicated mailbox is still an untrusted-content ingestion point; a ShadowLeak-style payload can still arrive. What a dedicated inbox fixes is the other three legs — the private-data hoard, the over-broad send authority, and the loss of attribution. You shrink the blast radius from "a person's entire digital life" to "one scoped mailbox," and you get a clean audit trail. That's the identity half of the problem, and it's the half the borrowed-account pattern gets catastrophically wrong.

What a Real Agent Email Identity Looks Like

Give the agent its own address and its own credentials, and the three failures above invert into properties you want:

An agent's own mailbox is a scoped, revocable, attributable identity endpoint. The credential grants access to one inbox and nothing else. Every message in and out is a logged record of what the agent did — the same auditability teams pay for on the observability side, applied to the agent's outward actions. And because the address is stable, the agent has a persistent identity across sessions: it can receive a reply next week to a message it sent today, which a chat session or a shared account can't reliably do. This is the same durability that makes email such a strong memory store for long-running agents.

Provisioning one is a single call — no human sitting in an OAuth consent screen, no shared password:

import requests

BASE = "https://api.deadsimple.email/v1"
headers = {"Authorization": "Bearer dse_your_api_key"}

# Give the agent its OWN address — not a human's borrowed OAuth token.
inbox = requests.post(f"{BASE}/inboxes", headers=headers, json={
    "name": "recruiting-agent",
}).json()

print(inbox["email"])  # -> recruiting-agent@yourco.deadsimple.email

# Scoped: this credential reaches ONE mailbox, not a person's whole account.
# Attributable: every send/receive is logged as this agent, not a human.
# Revocable: rotate the key and this agent is offline — no one else affected.

Two Honest Caveats

A per-agent inbox is not a free lunch, and pretending otherwise would undercut the argument. Two caveats are worth stating plainly.

It adds to non-human identity sprawl. "Give every agent its own inbox and credentials" is only defensible if you also govern the lifecycle — provisioning, rotation, and de-provisioning. With machine-to-human ratios already at 82:1 and climbing, an ungoverned fleet of agent mailboxes becomes its own problem. The answer is programmatic lifecycle management: because the inbox is created and destroyed via API, it fits the same automation that spins the agent up and tears it down.

A fresh mailbox has to earn deliverability. An agent's brand-new address needs proper SPF, DKIM, and DMARC and a sensible sending ramp, or its mail lands in spam. That's real operational work — and it's precisely the work an agent-native email platform exists to absorb, so you get an authenticated, warm, deliverable identity instead of a cold mailbox on a blacklisted IP. We cover the mechanics in email infrastructure for AI agents, explained.

The Missing Row in the Identity Table

The agent-identity stack of 2026 is a real achievement. Okta, Microsoft, Google, AWS, and the MCP authorization spec have made it possible to authenticate an agent and scope what it can do — and they did it fast, in response to a genuine explosion of non-human identities. But authentication and authorization are only half of identity. The other half is being addressable and being accountable: having a place the world can reach you and a record of what you did. For software, that place has been email for forty-five years.

An agent borrowing a human's Gmail gets none of that safely — it gets over-scoped access, no attribution, no clean revocation, and the lethal trifecta in a single account. An agent with its own inbox gets a scoped, revocable, attributable identity endpoint that the rest of the internet already knows how to talk to. If "agent identity" is going to mean anything complete, it has to include the address, not just the key. The email row belongs in the table.

Frequently Asked Questions

What is agent identity?

Agent identity is the set of credentials, permissions, and attributes that establish who an AI agent is and what it may do. In 2025–2026 every major platform shipped an agent-identity layer — Okta Auth for GenAI, Microsoft Entra Agent ID, Google Agent Identity, AWS Bedrock AgentCore Identity — but all of them center on authentication and authorization. None gives the agent a communication endpoint or a way for the world to address it and attribute its actions.

Why is it a problem for an AI agent to use a human's Gmail account?

It fails on identity, permission, and audit simultaneously. The agent inherits the human's full mailbox — read, send, delete — far more than it needs, so the blast radius on compromise is enormous. Its actions are indistinguishable from the human's in any log, so there's no attribution. And you can't revoke it without disrupting the person. A human's Gmail is also the "lethal trifecta" in one account: private data, untrusted incoming content, and an outbound send channel.

How does giving an agent its own email address improve security?

A dedicated inbox with scoped credentials restores attribution, least privilege, and revocability: every message is provably the agent's, the credential reaches one mailbox rather than a person's whole account, and you can rotate or revoke it instantly in isolation. It does not by itself stop prompt injection — a dedicated inbox is still an untrusted-content ingestion point — but it fixes the identity, permission, and audit failures a borrowed account guarantees.

Does a dedicated agent inbox stop prompt injection attacks like ShadowLeak?

No — and it's important to be clear about that. A dedicated mailbox is still a place untrusted email arrives, so an injection payload can still land. What it changes is the damage: instead of an attacker reaching a human's entire mail history and send authority, they reach one scoped mailbox with a clean audit trail. It's the identity and blast-radius fix, not the injection fix.

How do you give an AI agent its own email identity?

With an agent-native email API like Dead Simple Email, you create a dedicated inbox with its own address and scoped credentials in a single API call — no human OAuth, no shared account. The agent sends and receives through that address, and every message is a logged, attributable record. Pricing starts free for 5 inboxes and is $29/mo for 100. For the broader case, see why AI agents need their own email addresses.