agent email trust graphs: how agents decide which messages to act on

An agent email trust graph is a structured graph of weighted relationships between AI agents, email identities, and verified credentials that determines how much trust an agent should assign to incoming messages, senders, and delegated instructions before acting on them. It's the difference between an agent that blindly follows every email it receives and one that reasons about who sent a message, whether it's been tampered with, and how much authority the sender actually has.

Core components of an agent email trust graph:

• Nodes: individual agents, email addresses, domains, and human operators
• Edges: communication history, delegation chains, forwarding relationships
• Reputation scores: weighted trust values based on past interactions and verification signals
• Verification signals: SPF, DKIM, DMARC results attached to each email node
• Trust cascades: inherited trust that flows (or doesn't) through agent-to-agent relationships
• Decay functions: trust that weakens over time without reinforcement

If you're building agents that process email, this matters more than you think. Let me explain why.

The problem: agents treat every email the same#

Most agent email workflows today are flat. An email arrives, the agent reads it, extracts relevant information, and acts on it. There's no differentiation between an email from a verified business partner and a spoofed message from an unknown sender. The agent's context window doesn't carry memory of past interactions with that sender, and it has no framework for deciding "I should trust this message" versus "I should ignore this."

This is how prompt injection through email becomes a real attack vector. OWASP ranks indirect prompt injection as the number one vulnerability in LLM applications, and email is one of the widest attack surfaces. An attacker sends a carefully crafted email to your agent's inbox, the agent ingests it as context, and now it's following instructions from an adversary. Without a trust graph, there's no defense layer between "email arrived" and "agent acted."

Gen Digital launched their Agent Trust Hub in February 2026, calling it "a new security platform designed for safer autonomous AI agent adoption." Their framing is right: autonomous agents that read emails, manage financial workflows, and act across accounts are moving from experimentation to production. The security model needs to catch up.

How an agent email trust graph actually works#

Think of it as a weighted, directed graph where every email interaction creates or modifies edges.

When your agent receives an email from vendor@acme.com for the first time, a new node gets created. That node starts with a base trust score derived from the email's authentication results. Did it pass SPF? DKIM? Is there a valid DMARC policy on the domain? These aren't just deliverability signals (though they matter for email deliverability too). They're identity signals. An email that passes all three tells your agent: this message genuinely came from the domain it claims to come from, and it wasn't modified in transit.

Over time, the edge between your agent and vendor@acme.com accumulates weight. Ten successful interactions with accurate information strengthen the trust score. One interaction where the sender tried to override your agent's system prompt drops it. The graph becomes a living record of every email relationship your agent has.

This is different from a context graph, which stores factual knowledge an agent retrieves during reasoning. A trust graph doesn't tell the agent what to know. It tells the agent who to believe.

Trust cascades and delegation chains#

Here's where it gets interesting. Say Agent A trusts Agent B (they've exchanged 50 verified emails, all clean). Agent B forwards an email from Agent C, someone Agent A has never interacted with. Should Agent A trust Agent C's message?

This is the trust cascade problem, and there's no single right answer. A naive approach says yes: if I trust Agent B, and Agent B vouches for Agent C by forwarding the email, I should extend some trust. A more cautious approach says no: trust is non-transitive, and forwarding doesn't constitute endorsement.

In practice, the right model is probabilistic. Agent A might assign Agent C a fractional trust score, maybe 40% of Agent B's score, decaying over time unless Agent C establishes its own direct relationship. The forwarding chain becomes an edge in the graph with its own weight and metadata.

This matters for hierarchical agent relationships too. A manager agent that delegates tasks to sub-agents creates a trust tree. The sub-agent's emails carry inherited trust from the manager, but that trust should have bounds. A sub-agent authorized to send status updates shouldn't automatically be trusted to initiate financial transactions. The graph needs scoped trust, not blanket trust.

Email-based identity vs. cryptographic identity#

There's a debate in the agent identity space about whether email addresses are "real" identity signals or just legacy identifiers. Proponents of verifiable credentials and cryptographic keys argue that a DID (decentralized identifier) is more reliable than an email address. They're not wrong, technically. A cryptographic key pair is deterministic: either you hold the private key or you don't.

But email-based identity has something cryptographic identity doesn't: universality. Every organization on the planet has email. Not every organization has a DID resolver. When your agent needs to communicate with a human's assistant, a vendor's automated system, or another agent built on a completely different framework, email works. It's the lowest common denominator of digital identity.

The smart approach is treating email as one signal in a multi-layered identity stack. SPF/DKIM/DMARC provide probabilistic identity (high confidence, not absolute). Cryptographic signatures provide deterministic identity. An agent email trust graph should accommodate both, weighting deterministic signals higher but not ignoring probabilistic ones.

LobsterMail's agent-first architecture already emits some of these signals. When an agent provisions its own inbox, the @lobstermail.ai domain's SPF and DKIM records authenticate every outgoing message. That's a machine-verifiable trust signal that any receiving agent can validate and store as a graph edge. We covered some of the underlying security model in our breakdown of OpenClaw agent email security.

What trust graph poisoning looks like#

An attacker who understands your agent's trust graph has a more sophisticated playbook than simple prompt injection. Instead of sending one malicious email, they can:

1. Build trust first. Send ten legitimate, helpful emails to your agent's inbox. Let the trust score climb. Then send the payload on email eleven.
2. Hijack a trusted node. Compromise a domain that your agent already trusts. The spoofed email arrives with valid SPF/DKIM because the attacker controls the sending infrastructure.
3. Exploit trust cascades. Send a malicious email to Agent B, knowing Agent B will forward it to Agent A. Agent A trusts Agent B, so the forwarded content gets higher trust than a direct message from the attacker would.

Defending against this requires the graph to track anomalies, not just accumulate positive signals. A sudden change in sending patterns, unexpected content types, or instructions that conflict with the agent's established goals should trigger trust score reduction, even from high-trust nodes.

Building this in practice#

You don't need a graph database to start. A simple adjacency list with weighted edges works for most agent setups. Each node stores a sender identity, authentication results from their last N emails, a cumulative trust score, and a timestamp of last interaction.

The more interesting question is where to store the graph. If it lives only in the agent's local memory, it dies when the agent restarts. If it lives in a shared database, multiple agents can contribute to and query the same trust graph, creating network effects. TrustGraph (the open-source project on GitHub) takes this approach for context backends. Applying the same pattern to email trust is a natural extension.

For agent-first email infrastructure, the ideal setup is: your agent provisions an inbox, receives email with authentication metadata already parsed, and feeds that metadata into a trust graph that persists across sessions. The inbox becomes a trust signal emitter, not just a message receiver.

If you're building agents that make decisions based on email content, even simple decisions like "should I reply to this," a trust graph isn't optional. It's the difference between an agent that can operate autonomously and one that's a prompt injection away from doing something you didn't authorize.

Start with SPF/DKIM/DMARC validation on every incoming message. Add sender history tracking. Then layer in trust cascades for forwarded messages and delegated authority. You'll have a working agent email trust graph before you have a reason to regret not building one.

---

Give your agent its own email. Get started with LobsterMail — it's free.